吐槽microservice architecture

donnice 发表于 2021-08-10 12:44:26
你说的这个叫micro management，不是microservice。microservice的API设计得当，doc清晰的话，理论上对人的dependency应该更小才对

micromanagement不是这个意思

我发现，这个帖子居然是一个很妙的behavior question的问题，下面的回复汇总起来就是答案。

好奇Microservice 的特征不就是 low decoupling and high cohesion吗，实际情况中不同组间需要频繁地互相调整影响对方的代码吗

marvinbai 发表于 2021-8-11 10:40
micromanagement不是这个意思

第二页解释过了，no redundancy

aunom 发表于 2021-8-11 09:43
你这么说就好理解多了

问题确实不出在microservice上，但是和api设计也没关系，我觉得问题无解，除非 ...

有关系。有些时候正是因为设计不周全，有些需求未能考虑到，导致下游用起来不顺手。也有些是因为文档太差，导致明明很好用、很有扩展性的的API也会被下游觉得不好用。如果真的是设计得较为合理的API，并且配以足够具体的文档和例子的话（如那些优秀的开源项目），那是真的可以省掉很多没有意义的沟通

举个最简单的例子，React框架写得足够好、文档和例子也详尽，社区也足够活跃，所以React使用者往往能独立在这个框架的基础上写出自己的代码，或者做出合理的扩展，而不是打电话去Facebook给React开发者开Sev2

MinshinZ 发表于 2021-8-10 19:53
好奇Microservice 的特征不就是 low decoupling and high cohesion吗，实际情况中不同组间需要频繁地互相调 ...

理论上是这样，各个service之间各自独立，只用API来交流。但是要拓展做新东西的时候，流程上的每一个service都需要加代码或者改代码，而每个service都是一个独立的team own的，导致交流成本极大。

donnice 发表于 2021-8-10 20:09
有关系。有些时候正是因为设计不周全，有些需求未能考虑到，导致下游用起来不顺手。也有些是因为文档太差 ...

React是前端开发框架，需求能有Business logic千变万化？用户提的千奇百怪的要求是一个设计能考虑全的吗？不否认有关系但在真实的开发世界里根本没有不出问题不需要改的设计或者框架。

匿名者 发表于 2021-8-11 11:22
. From 1point 3acres bbsReact是前端开发框架，需求能有Business logic千变万化？用户提的千奇百怪的要求是一个设计能考虑全的吗 ...

这当然是case by case的。比如我作为新浪的general tooling组的程序员，开发了一个从数据库调数据的API叫getUser()，然后你是微博业务的开发者，跟我说需要一个API叫getAngelaBaby()，我当然不会理你，因为我是做general tooling的，你想调天王老子我都只能给你getUser()。你想要getAngelaBaby()，只能想办法自己找workround从数据库里专门自己给自己开发一个能用的function

但如果我本身就是专门给微博业务做tooling的，别说getAngelaBaby()，只要你老大一句话，getTianWangLaoZi()我也给你开发出来

换到monolithic也会难受，code base会大到组里最资深的也没有全部看完，或者好几个组一起work on一个很大的package，每次deploy也会比较慢

MinshinZ 发表于 2021-8-10 18:53
好奇Microservice 的特征不就是 low decoupling and high cohesion吗，实际情况中不同组间需要频繁地互相调 ...

Loose Coupling
High Cohesion