今天这里只谈一个字:拆!像业务领域怎么划、市面上的东西五花八门,真货假货一大堆,扯起来比较麻烦。
拆多少?7个!
拆分的好处是什么?
有个paper最早提出了模块化这个词。那时还是在造硬件,故障率特别高,为了降低功能的复杂度,把硬件拆成各种小模块,这样就可以分开测试了。它不是解决模块复用的问题,而是解决整体复杂度过大。
微服务一样的,按功能内聚、单个应用复杂度降低,维护成本也降低了。还有一些其他目的,譬如流量隔离、整齐划一、增强复用性等。
那坏处呢?有可能没啥好处,也有可能总体成本变大。像依赖关系理不清,反而导致系统变复杂了,一个需求可能改多个地方。部署的机器变多了,可能还是一笔不小的开销。本地数据库事务不能用了。等等。
好坏是没有标准的,在这件事上。(质量、安全等非功能性除外)
拆的原则是什么?
(一)反认知局限、反自己、克制自己
单体的人想拆服务,拆服务的人想单体。就像围城。
我开始出来工作,公司就是微服务的文化,不同领域独立出来,不同层独立出来。因此,微服务在我最早的世界观里,这被认为是天经地义的。
某年公司开始做成本,我偷偷数了下部门里的应用数和机器数,我负责的团队居然应用最少、机器最少。因为那几年我一直在反着思考,开项目相对保守。再后来去北京总部一看,我还是吃了一惊,居然会有这么大的单体,居然还能跑……所以直到今天,我都很好奇,单体的极限在哪里?
人