架构：微服务该拆多少应用？是7个！

今天这里只谈一个字：拆！像业务领域怎么划、市面上的东西五花八门，真货假货一大堆，扯起来比较麻烦。

拆多少？7个！

拆分的好处是什么？

有个paper最早提出了模块化这个词。那时还是在造硬件，故障率特别高，为了降低功能的复杂度，把硬件拆成各种小模块，这样就可以分开测试了。它不是解决模块复用的问题，而是解决整体复杂度过大。

微服务一样的，按功能内聚、单个应用复杂度降低，维护成本也降低了。还有一些其他目的，譬如流量隔离、整齐划一、增强复用性等。

那坏处呢？有可能没啥好处，也有可能总体成本变大。像依赖关系理不清，反而导致系统变复杂了，一个需求可能改多个地方。部署的机器变多了，可能还是一笔不小的开销。本地数据库事务不能用了。等等。

好坏是没有标准的，在这件事上。（质量、安全等非功能性除外）

拆的原则是什么？​​​​​

（一）反认知局限、反自己、克制自己

单体的人想拆服务，拆服务的人想单体。就像围城。

我开始出来工作，公司就是微服务的文化，不同领域独立出来，不同层独立出来。因此，微服务在我最早的世界观里，这被认为是天经地义的。

某年公司开始做成本，我偷偷数了下部门里的应用数和机器数，我负责的团队居然应用最少、机器最少。因为那几年我一直在反着思考，开项目相对保守。再后来去北京总部一看，我还是吃了一惊，居然会有这么大的单体，居然还能跑……所以直到今天，我都很好奇，单体的极限在哪里？

人的认知太有局限性了。为啥拆开？人能为自己想做的任何事找到很多理由。如果你追求真正的真理，在服务的拆分上，一定要是一个保守主义者，克制自己。

 

（二）人数决定了多少服务

从人数来看，可能是一个硬标准。

一个团队人数大了就很难沟通协作，自组织的单元就是10来个人，再大内部就乱了。一个团队10个人，维护多少服务合适？3～7个。

服务就是这10个人工作的地方。大家各做各的、老死不相往来，也就10人。上班时候三两成群聊聊天、一起协作，也就5个。

系统的问题就是人的问题。一个团队最后多少系统，取决于这群人平时怎么合作。

 

（三）拆分是个伪命题、做好模块化

仔细去想，拆、合的技术，如果逻辑层代码模块化做得足够好，物理层部署、就应该做到：想拆的时候就拆、想合的时候就合！

这样架构，要具备啥条件呢？
（一）JAR包形式的API要大。不易变。
（二）按模块隔离代码，最小外部依赖，像硬件啥的。
（三）服务访问要有路由层，不要合集群绑死，允许部署灵活拆分、合并变更，像serverless啥。

 

---

=>更多文章请参考：《中国互联网业务研发体系架构指南》

=>更多行业权威架构案例及领域标准、技术趋势请关注微信公众号：

更多权威内容关注公众号：软件真理与光