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

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

拆多少？7个！

拆分的好处是什么？

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

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

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

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

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

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

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

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

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

人