你这种 case 如果数据量持续上升，应该用 spark 这种离线作业，或者压根不应该拆分服务。

单独一个仓库，开发 proto 先行，聊需求聊技术方案都拿着 proto 来说话。
接入使用云端 buf package 专门按 commit hash/分支托管产物，或者 java 这种可以本地 submodule+build 。

所以我在等 18.1
永远忘不了刚换 15p 的时候，那天下午折腾了两个小时也没办法把旧机数据倒进来。
上网一查：首发 17 的系统，存在 bug ，会在转移数据时失败，必须先新机进系统更新 17.1 ，然后抹掉数据重新转移。

我上早八！

@lvlongxiang199
当然可以

说实话 你这个简历写的和应届生好像也没差

适合超大规模的条件下，业务和机架分离。
举个例子，DB 访问，缓存中间件访问，服务发现，trace 等等这些东西全在 sidecar 里，鸡架更新对于业务完全无感。

代理工具分两种

1. Client 主动通过代理协议（如 HTTP/Socks 等）连接，此时域名会被直接送入代理协议，代理协议会将其直接送往远端/或者根据代理规则进行解析，不走系统 DNS 。
2. 透明代理，此时 DNS 解析通过系统 DNS 配置处理，代理软件处理 DNS 的方式也有两种，一是劫持 DNS 请求并响应，代表作为：FakeDNS 。二是不管系统 DNS ，通过透明代理处理时，嗅探对应 TCP/UDP 流量中的域名，然后做 destOverride ，将被墙站点重定向至远端代理。

无论两种方式，均工作在传输层及传输层之下，即便是嗅探也只是 L7 读取部分内容，因此无需解决证书问题。

最后，不分前提条件让人设置 DoH ，大谈特谈 DNS 泄露的，一律当小鬼处理。你以为墙很在乎你 nslookup 了什么域名？真是搞笑

旱的旱死涝的涝死

@basncy
wifi6e 满配是 AX6000 双频 4T4R ，价格上没啥优势，而且 5130 这种中端 wifi7 BE5100 ，2T2R 2.4G + 3T3R 5G ，速率就差 900m ，实际使用没差，还更便宜更省电能战未来。

直接 wifi7 不好么 7dr 5130 ，200 到手

@basncy
我还纳闷 op 这是什么奇葩要求，看到你这层我算是懂了。
经典的一顿自我分析然后掩盖原始问题。。反倒把问题复杂化了

没活硬整，但应该不会和 touch bar 一样身死道消，除非苹果换屏幕技术。

感谢让我 block 名单+1

go 的风格就是没有统一风格。跟项目风格，否则你水平比项目高或者低写的都只会很憋屈。

你开心就好。我感叹下 serverless 在国内的水土不服反倒有人来教育起我来了还给我扣一顶眼界小的帽子。

@BeautifulSoap
根本不是什么眼界问题，不如说，一方水土一方人。何况日本 IT 啥水平就不用大家讲了吧。
国内大企业都在逃离公有云，那么自建的情况下为什么要自研一套非常吃基建的 serverless ？徒增运维成本，而且可维护性也比传统 CS 模式差。
降本的压力下所有东西全部向效能看齐，serverless 本质上是重前端轻后端快速迭代的路子，如今增长顶峰已去，大厂根本没有投入 serverless 的理由。
而且另一个问题，国内各种 app 都是奔着门户入口去做的，既要又要的要求下，serverless ？压根不会考虑。