吐槽microservice architecture

大家都知道各个大厂各种组众多，每个组有自己专属的code和service，美其名曰microservice architecture，但是交流成本真特么高。。。做新项目要和5，6个组接触，到处求爷爷告奶奶别人还不鸟你，出了问题还得求人debug，严重拖慢进度。。。wtf心累

你说的这个叫micro management，不是microservice。microservice的API设计得当，doc清晰的话，理论上对人的dependency应该更小才对

这不就是谷歌facebook推崇的high impact跨组合作么

匿名者 发表于 2021-8-11 06:03
如果只是简单调用对方service的话那当然简单，但是我们新项目需要改对方code base，改接口，再测试，每个 ...

这是另一回事，取决于对方组的性质，如果他们组是专门为你们服务的你们的上游组，那你们应该有更好的沟通通道，让他们高效顺从你们的需求。

如果他们是一个general的tooling/SDK组，只是你们有专门的需求要人家特地为了你们改code，那需要求爷爷告奶奶是正常的，毕竟别人没有责任为你们的KPI负责。需求复杂的话，很可能需要双方manager介入去协商推进项目，而且很有可能最后人家turn down你们的需求，需要你们自己想出workaround，本来就不是你几句话人家就能解决的事情。

这不是microservice的锅

就算在一个service里也是在不同repo啊，你也得交流啊

有API文档吗？是文档不全的问题，还是你看不懂文档的问题？

换到monolithic的架构一样会有类似的吐槽的，比如infra难以兼容，更新迭代太慢，几十年的老代码当金子捧着等等。本质是一样的，沟通成本就是很高。

donnice 发表于 2021-8-10 12:44
你说的这个叫micro management，不是microservice。microservice的API设计得当，doc清晰的话，理论上对人的 ...

如果只是简单调用对方service的话那当然简单，但是我们新项目需要改对方code base，改接口，再测试，每个组都有复杂的business logic，不是读个doc就够用的。

业务划分的问题不该让架构背锅吧。感觉lz的意思是每个team内部应该适当容许造一些轮子，就不用求人了