吐槽microservice architecture

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

这种时候要么你们自己上去改，要么求爷爷告奶奶，别无他法。

我觉得求别人service debug的问题， 可以试试公事公办， 假如别的组的service的behavior不符合他们的 SLA， 那就直接一个ticket甩他们组脸上， PM或者老板来催project， 就说责任是别人组的

Micro service 好处远远大于坏处。软件开发最怕complexity，complexity里面有一个重要的部分是coupling。Micro service 通过定义交互协议很自然的解决了coupling的问题，于是就可以对不同bussiness logic设置boundary。设置好了boundary 就可以让每一个独立的小service是完备的，进而更好的在公司层面划分organization。Test 和Debug在 Micro service里面要远比所有team在同一个binary上工作要好。即使是Nginx/Linux这种没办法分成micro service的架构，他们也想办法设置不同的module，module和module之间也不是混杂在一起的，通过协议沟通，不止是直接调用别的module的function。

Micro service 唯一的缺点就是dependency management。但这个问题不只是micro service有，java/python/nodejs 等几乎所有语言都有dependency hell的问题。如果要是有人能解决这个问题，那软件工程可以进行更大规模开发。

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

in a perfect world...

要是现实世界这么简单，三分之二的程序员都可以下岗回家了

另外 micro management 并不是这个意思

aunom 发表于 2021-8-11 08:43
in a perfect world...

要是现实世界这么简单，三分之二的程序员都可以下岗回家了

我的point是，楼主提出的这些并不是microservice的问题，是文档和API设计的问题。

以及我当然知道micro management本来的意思，而这是micro management的衍生意，就是组里的人缺乏big scope，每个人管的东西太细，导致组和组之间明明在支持同一些service却不能有效沟通

https://eng.uber.com/microservice-architecture/
这篇有用么...

donnice 发表于 2021-8-10 17:57
我的point是，楼主提出的这些并不是microservice的问题，是文档和API设计的问题。

以及我当然知道micr ...

你这么说就好理解多了

问题确实不出在microservice上，但是和api设计也没关系，我觉得问题无解，除非大家吃大锅饭。

比如说组A要开一个新项目，需要upstream dependency B的支持。因为是新的东西，API和文档设计的再牛逼也没法空手接白刃，肯定会占用组B的bandwidth，然而组B也有自己要忙的项目，管这个就管不了那个，两者的利益肯定是冲突的。

microservice 架构厉害就厉害在他契合了康威定律。"设计系统的架构受制于产生这些设计的组织的沟通结构。"

公司有自己的基因，这些都刻在组织架构和你的每一段代码里。沟通的困难一开始可能并不是因为 microservice 导致的，而是困难本身导致公司选择了 microservice 走下去。

donnice 发表于 2021-8-11 06:31
这是另一回事，取决于对方组的性质，如果他们组是专门为你们服务的你们的上游组，那你们应该有更好的沟通 ...

赞
clarify的很清楚 果然有经验
还有上面一楼说的 也agree

所以只有自己吃够所有源码，并请求依赖组的所有permission, 就可以做到：一切尽在不言中。