cxytz01

你该不会是学材料的吧？又要被认出来了。xD.

方法一：grcp 本质也是 http，也有 header 和 url，你的方法名字就是你的 url，代理网关肯定支持 http2 的反向代理
方法二：将 B 的接口通过 grpc gateway 暴露成 http1.1

微服务的划分粒度是比较感性的话题，没有统一的标准。不能为了微服务而微服务，也不能为了单体而单体。它们之间没有明显的边界，不是泾渭分明的。

从单体到 SOA，到横向、垂直划分，到微服务，它们之所以出现都是为了提高生产力亦或者降低扩容成本，简称降本增效。以下讨论排除金融、游戏业务。(金融、游戏业务，为了更低的时延，核心模块不会使用微服务，关键模块甚至不计成本，性能至上)

先从成本角度考虑：如果你是一个 NewSQL DB，显然做成单体不适合。DB 作为整套业务系统的核心，压力最大，扩容最贵。单体 DB 扩容，意味着把整个 DB 程序整体复制 n 次，而不管热点模块是哪个，扩容成本比较大。因此，需要按模块拆分，扩容时，只需扩容热点模块。可以想象 mysql，redis 等 OLD SQL 的扩容，都是整个 DB 进行扩容，贵。

又从成本角度考虑：如果你是一个 DB，轻量级的。应用于嵌入式场景，开发者最求的是我只需要调用函数，就可以用你的 DB，不需要各种网络功能，而且占用资源少，还要快。那么此时微服务显然不适合，甚至带有网络 IO 的 server 都不适合，这就是 SQLite 的诞生原因： 我就是一个 library，不需要微服务，只需要模块化。

从技术维护角度考虑：一个单体服务，业务变更频繁，牵一发而动全身，每次上线整套系统都要有不定长的停机时间。因此需要微服务化：将不频繁变更的模块、频繁变更的模块剥离、分离出来，日后的改动只需要关注频繁变更的模块。
上线时只有频繁变更的模块会受到影响。

从技术的角度考虑：一个单体服务，需要稳定，不能重启，但又经常业务变更： 比如涉及到 TCP 长链接管理的服务。那么需要将长链接管理的模块和经常变更的业务剥离出来。

从机器资源的角度考虑：一个单体服务，既是 IO 密集型，又是 CPU 密集型的。那么需要将 IO 逻辑和 CPU 计算逻辑剥离出来，充分利用不同机器特性。

从业务、项目推进、扩容成本的角度考虑：一个电商程序，一个人可以负责全部，那么就不剥离。后续功能变多，一个人负责不过来，就模块化，依然不剥离。再再后续，某个模块上线时需要整个程序停机更新，则需要剥离。再再后续，某个模块成为热点时，需要整个程序扩容，则需要剥离。再再后续，单体服务限制了多人协作，你一个 pr，我一个 pr，他一个 pr，全都 hold 住，等着 merge 进入主干，则需要剥离。

从人员管理角度：A 和 B 天生合不来，那么需要微服务化，各自管各自的服务，谁也别管谁怎么实现的，给我接口就行。


以上讨论的是分。分了之后在合，我没遇到过，但是我可以想象也是为了降本增效： 分了的服务，给技术、技术维护、项目、业务、运维等任一项带来了层本上的上升，所以要合。

关于你的首席技术官，我不好评价他的对错，因为基于你的描述，只谈到了果，没有谈到因 -- 为什么而分。

请问，看候选人籍贯有什么用？

普通程序员请教下：什么是 Tranformer，inference，embedding 。 搜索引擎的解释看不懂。

@JerryMouse 那你得加把劲，争取不需要测试。起码你已经进步到测试觉得测你的代码没劲了。下个阶段就是：优秀的开发工程师不需要额外配一个测试工程师。😄

什么算是优秀，如何定义优秀？

非优秀 10+后端开发说下我的看法：
1.业务抽象能力，能将需求抽象成简单代码。能用抽象思维解决的问题，绝不通过黑科技代码来解决。(这句话很难理解，不展开)
2.代码精简能力，你写的代码几天、几个月，甚至几年之后自己还能一眼看懂。同事也很容易看懂你的代码，尤其是 2-3 年的同事也能看懂你的代码，然后喷你：还是工作 10 年的人呢，代码写得我也能看得懂，毫无技术含量，lowB 。
3.严谨的逻辑思维能力，能够对各种黑天鹅事件，预先在代码做上防御式编码。

三面三条是我认为优秀的工程师需要具备的能力，总结一下就是：解决问题于未然；善战者无赫赫之功。

拥有上面三条，你基本在团队里面就是毫无存在感的。整天无所事事，线上救火也无你份。 -- 然后等着被裁吧。😄

@auxox 非评论区里坛友猜测的公司，加你微信没意义。

后端开发，加班情况如何？ 平时几点上下班的啊?