[转贴]为什么微服务更容易陷入焦油坑
中国的软件危机到来了
去年我担任赢时胜清算系统架构师，观察到了一些比较有趣的情况：大量微服务软件项目陷入焦油坑。
赢时胜新一代清算系统立项于2019年，目标是开发一个微服务架构的通用清算系统，抛弃过去那种CS架构，使用BS微服务架构，既支持基金行业，也支持银行行业。最初研发小组10个以内，到今年2025年6月为止，后端研发近30，前端4个，测试6个，需求专家7人……带上实施管理等已经60+人。其上一个市场接受的版本（CS架构）是V4，现在的版本是Y7，中间历经4个不同的研发团队，多次组织架构调整。系统还没还未上线，已经腐化，不改就崩，一改就错。去年之前签的2个客户，在UAT阶段数年而迟迟不敢上线。
有趣的事，同行恒生的新一代清算、估值、TA也是同样境况。长期停滞在客户并行阶段，，越改越不稳，越差；多次调整组织架构……时间也几乎是从2018年开始。
巧合的是2015年，阿里发起了中台项目。然而到2019年收工之年，一向的阿里低调宣布“阿里只做被集成”，黯然结束了轰轰烈烈的中台项目。
这些项目的共同特点是：意图对过去N年积累的，已经很复杂的业务系统进行可扩展、通用化的技术改造。然而都碰到了极大不可克服的困难。
对于大多数人来说，往往看不到这些项目到底发生了什么情况？碰到了什么问题？因为什么原因导致陷入这些症状。甚至对于很多身在其中的人，也往往因为身份过于单一，不理解、不明白是什么原因导致了软件研发陷于这种状态。
恰好，我作为同时参加过这些项目，作为业务架构师和部分项目主程、负责人。兼顾业务视角、技术视角、开发视角、管理视角。能比较深入的思考为何几乎同时，不同空间，不同时间，不同行业背景的软件能同时陷入同一种状态。
赢时胜清算观察到的问题
赢时胜清算系统陷入焦油坑的主要难题是业务复杂度+技术复杂度的笛卡尔积叠加。此外还有很多次要因素，但并不关键。
赢时胜老系统的业务复杂度是N。新系统是N*（N-1）。
技术复杂度老系统是1，新系统是N*（N-1）*M*N
先说业务复杂度。老系统是N个页面，数据虽然彼此关联，但要人根据经验和判断自己去一个个点的。比较吃业务经验。新系统直接在一个页面中，展现了N种数据和他们彼此的关联关系，点A联动BCDEFG，反之亦然。这意味着原来是N个增删改查，现在是N个增上改查+N*（N-1）关联关系的笛卡尔积。
除了数据联动外，新一代系统在配置方式上，流程上等等进行都进行了大量人性化的优化。比如一个券商有数万个产品、机构、交易类型。业务规则最多是他们的笛卡尔积。现在通过一定设计可以降低带数百个配置之低，做到两三个页面看到配到全部配置，这也带来更高的编程复杂度。总之，业务复杂度在各个方面都有数量级甚至指数级的提升。
景观如此，清算系统其实99%的业务都很简单，最复杂的就是一个叫做交收的模块，这个模块是导致他们陷入焦油坑的根源。因为简单的模块，即使偶尔有一两个指数级的复杂度，是可以靠硬堆人，硬加班解决的。虽然质量不好，可是做好以后变动并不是那么高，稳定性性能的要求也不是那么高。而是交收这样极少数的模块，是N种指数级复杂性耦合在一起，并且极大的数据流量，极高性能，极高的一致性要求不能有丝毫金额错误。这样极端复杂，高度可变，又高度要求的模块，任何细微的设计，都可能被无限放大造成不可控制的局面。
除了业务复杂，他们在技术上还犯了如下设计错误。
1，异常设计错误，造成复杂结构程序层层耦合，影响
2，对象结构设计错误，造成复杂结构层层耦合，影响
3，针对具体进行编程，所有业务实现向下耦合，影响下游质量
交收逻辑上是一个6层的数据处理：数据=》交收日处理=》具体日期=》交收路径（账户类型）处理=》具体账户=》交手模式处理=》具体汇总轧差。层层是逻辑依赖的。
券商业务上，数据可能包含直销，中登，TA几种大类，不同的交易类型可能还有很多细节的小类，比如退款，利息，授信……在具体的账户上，大部分是清算到到客户账户（不论是归集户，还是渠道户技术上并没有区别），还有一部分是清算到过去的清算明细，互相抵扣；或者清算到过去的充值明细，互相抵扣；或者是路由到授信行账户清单。宏观业务并不复杂，但各个环节数据变化，业务变化非常多。代码结果不做精心设计和控制，很容易一团乱麻。
赢时胜异常规范使用的是互联网公司常见的所有方法返回必须是ApiResult封装的返回码，而不是直接throw异常。前者跨语言支持会比较好。后者编码会简单。简单在异常是跨层传递的，中间层透明的。而异常码不是，如果一个程序很复杂，有N层，用异常码机制会导致N层彼此抛出的异常会形成笛卡尔积。
代码实现呢，其实都是和具体需求绑定的。需求文档写ABCD，代码就写ABCD。业务上有直销，中登，TA，代码必定有。业务上他们在一个文档中，代码也大概率在一个类中。业务上写X产品怎么怎么样，Z交易怎么怎么样，代码中也必定是这样写。上一层的不稳定一定会传递到下一层，上一层的耦合性，也往往传递到下一层。
技术上，因为数据量比较大，需要做分批并行；这很难保证一致，确保高一致性的最简单做饭是都和DB保持一致，用总批次事务表控制整体一致性。但IO高，性能查；用内存有很高的性能，但可靠性和一致性是大问题，并且很容易GC，综合需要较大的设计技巧。过去也没权衡好。
以上这几个问题产生的或指数级，或数量级的复杂度，彼此交织。极大的劣化了系统的健壮性，可靠性。
当前清算大家都没做好，是整个业务复杂度和技术的耦合产生的指数级复杂度。超出组织的线性能力。
恒生观察到的问题
其实，赢时胜虽然也是5年没有上线成功。但其实他们的问题还是比较容易解决的还
1，微服务的粒度拆分并不是很碎，才5个。
2，技术框架也很简单，就是springboot系列
3，大部分代码质量度不怎么高，可是大多数模块其实业务层次结构和要求很都简单，即使有问题，硬堆人就能解决问题。交收这种复杂度高的也只是一个孤立点，虽然卡住关键流程几年，找到合适的人和技术方案也容易解决。
所以，去年对核心代码进行了3个月的重构后就迅速突破，今年接了10来个客户，要趁恒生更不济抢占市场。
恒生的问题，就复杂多了。
1，他们的技术框架是混合了C++和Java的。大部分时候Java都是一层皮。但这层皮也很重，估值系统拆了180+个模块。分为10+研发组，数百个开发。这个架构沟通协作很重。
2，C++和Java的交互，是通过xml数据报文层，过多的io导致内存占用很大，GC频繁，可靠性低。
3，为什么当初会这么设计呢？也有极大的好处。
保留C++的设计，有利于保留原有研发团队和既有成熟业务能力，
以xml作为传输协议，可以跨语言，复用过去C++组件能力给Java微服务。
虽然微服务架构只是一层皮，可是不耽误和金融机构内部的微服务体系整合。
最初，他们基本是以我为主，没怎么利用外部的微服务人才。而是自己就搭建起了以上微服务架构体系。
后来发现越来越复杂，越来越难以掌控，才开始逐步找很多阿里外援，甚至换血。可想而知新老矛盾不轻。
但阿里空降的人工作内容围着技术、工程效能、PPT汇报、服务客户。不懂金融业务，不能深入更落地的业务架构方案。只能在外围兜圈圈。恒生的人，也一样谨慎，大家都只愿意在一些小的点做稳妥的优化。组织架构的复杂化，做任何大一点改造，都涉及手深到别人的地方去做大刀阔斧的调整。
这个局面相对复杂，难处理的多。牵涉太多的组织协调、利益、人，不是1、2个技术大牛能够解决的问题。
造成这个局面的关键在领导骨干。
我仔细比较过我接触到的部门经理级别以上的领导（有决策权），恒生的更强调客户导向，商业成功，管理成功；很多领导脱离一线技术很久，不太懂Java这套技术体系。赢时胜呢，甚至董事秘书长，几个核心部门总经理和总监，技术上都很强，有些甚至参与一线编码。在技术上，他们对微服务这套接触的更早，认识更深刻全面。
恒生原有的技术方案稍加详细一点的论证就很容易知道在大数据量下有很高IO和性能问题。可是为何这么多优秀专家都没提示到位呢，他们大部分技术专家和架构师其实也是非常专业的。很大概率是有技术基因的人在决策层没什么存在感。
很明显，在公司重大技术转型的时候。一线部门的技术主管甚至公司高管在技术上是不专业的。团队决策是带有太多天然立场的和想当然的。
恒生是组织复杂度、管理复杂度的指数级负面效应。
阿里的中台失败的原因呢？
他们俩的问题呢，90%在阿里身上都不存在。
阿里并不普遍存在技术部门负责人脱离技术太久的问题。
也不存在局部技术复杂度和业务复杂度过高导致项目某个节点卡住迟迟研发不成功的问题。
他的问题是
1，28效应导致后面越来越小的蛋糕越来越难吃
2，微服务架构对组织架构的绑架反过来绑架了架构优化
2010年左后阿里的淘宝、天猫、支付宝、余额宝、阿里云，一个接一个的成功。到2015年的时候，阿里云全向图显示他们已经涉足120+个行业了。
这个时候马云又提出了五新，国民企业……阿里成为一个能力上限似乎看不到的企业。其实这个时候马云已经肉眼可见看到了危机：工程效率显著的降低。
降低的原因是什么？而是容易吃的肉越来越少，不容易吃的肉越来越多。
电商和支付其实是很简单的业务，靠产品经理设计好几款爆款产品就往往能够形成几千亿的巨头。即使有些问题很难解决，也可以通过PUA客户习惯，或者改变设计绕过去。
但是其他业务场景，尤其B类客户业务，是专业导向的，不可能跟着供应商的解决方案走；恨不得每一个都有自己独特的方案和特性和独特竞争力。要求高、不好伺候、并且多数不可能形成独家垄断供应商。甚至可能做的越多，包袱越重，越做越不赚钱。
阿里过去也是强业务导向的，大部分系统都是拼创意，靠年轻人大干快上。虽然后面做了阿里云，其实不过是技术本身向下的深化，而并没有深入到不同行业、领域的专业化解决方案上来。
阿里后面虽然做120+行业，招聘大量的行业专家，解决方案架构师————其本质都是售前。而不是真正拥有把某些特定行业，很多差异化的东西整合成一套通用的设计方案、解决方案，并能随着不同场景而千变万化————售前不具备这样的设计能力————而具备这样设计能力的技术架构们又大多数不懂业务。
所以，阿里只能向下，向云、向技术做深。除此以外的，吃得越多，消化越不良。
阿里的问题，就是技术做到极致，但业务。
恒生、赢时胜等等细分领域的公司——他们懂行业，懂业务，过去也有很成功的技术产品。可是换个语言、框架，手足无措。
他们是不同公司，结果也略有差异。问题的核心是能力不能融合，只能被喂死招。在时代的洪流中，稍微一变，不知所措。
————微服务让技术成本消失近乎于0，技术的门槛只会越来越低。微服务极大的解放了业务，决策的自由空间。但也带来了更大的困难和问题——让软件中更容易充斥这个样、哪个样的的不同维度的复杂性，需要越来越多角色，专业的人交融其中，需要让不同的语言彼此交流、协作，才能让复杂的项目成功。才能让巴别塔成功。
软件的本质，不过是一些概念，和概念之间的关系
——《人月神话》
操持不同语言（不同领域的专业概念）的有不同专业技能的人彼此融合协作，才能建造巴别塔。
——《人月神话》
解决方向可能在哪？
必然不可能在中台。做中台的，甚至都不知道它的方法论是啥。
也必然不能是领域驱动。它搞了20年，大家还在争论概念定义问题，太模糊了。
也肯定不是领域驱动中的所谓的统一语言————过于理想，无法落地。
我认为如果有方法，这个方法一定是极致简单的，只有极致简单，才能解决极致复杂，才能驱动无数人无差错的工作。
我认为可能的方向是：数据库ER设计。
不过，新的设计方式和以前的指导理论完全不同。下次再说。