腐朽王朝的更迭：谈 SM 系统的技术升级和持续改进

易骐 | 作者

麦芽面包 | 公众号

在以旧换新、”王朝更迭”的阶段，我感触的是腐朽和净化的相互撕扯。

1. 腐朽王朝的更迭

所有的系统必然会从内部滋生腐朽，尤其是巨大的单体系统。最具腐朽必然特性的大系统，是社会系统。

我国古代封建社会的王朝更迭，其实就是社会系统腐朽带来的必然结果。系统的腐朽，系统属性、运行机制、人都是决定性的重要因素。

• i. 封建王朝的社会系统属性就不必赘述了，整个社会是围绕封建主剥削贫苦农民这个宗旨而建设。

• ii. 相应的皇权统治术，无论是法家、仁孝、佛家亦或是道家，以及对应的运行机构，自顶向下的中央朝廷、州府、地方衙门，乃至科举考试等都是为了这个社会属性服务的运行机制，这些都是造成腐朽的主要原因。

• iii. 人是具有主观能动性的，因此人是最不可控的一环。人（腐朽系统运行的助推者，如贪官污吏）能聚众催生腐朽，人（渴望推翻腐朽系统的先行者，如开国英雄）也能合力净化腐朽。

纵观中国历史上下五千年，其实是一个枯燥的腐朽循环（或许带着些微的净化前进，主要体现在生产力上）。落后的社会属性、运行机制、生产力、生产关系，加上人类的推波助澜，不断地从内部腐朽着整个社会。腐朽程度尚低时，人们尚且忍着得过且过；忍无可忍之时，净化就来临了。叛乱！起义！造反！革命！

我们知道，中国几千年间几十次净化，其实都甚为微小。

一个王朝内发生的又被镇压的叛乱、动乱、起义，一般都是发生在王朝前后期。在前期，新系统刚刚建立，新的系统运行机制开始运行，问题很多在所难免。在后期，系统的腐朽加上局部地域的天灾、饥荒、人祸，使得社会系统运行极不稳定，因此战乱频发。王朝中期，一般来说运行较为平稳。

皇帝轮流做，明年到我家。每一次推翻旧王朝、建立新帝国，只是运行机制的微妙调整，仅带来些微生产力和生产关系的改善，并未动摇社会属性和核心运行机制，这也直接导致封建后期的中国被强大的资本主义国家侵略，只因资本主义国家的社会大系统已经经过大净化，社会属性和运行机制发生了巨大变革，迅速促进了生产力的发展。

后面的故事大家都知道，发生了伟大的社会主义革命！社会主义革命从根本上变革了中国的社会属性和运行机制，极大地解放了思想和生产力。当然，社会主义，乃至共产主义，一样会产生腐朽，而净化当然如影随形。社会系统是否能运行健康良好，取决于腐朽和净化之间博弈撕扯的结果。

2. 腐朽系统的演变

和 SM 的缘分短暂而简单，只不过在双十一前，曾经配合时序老师做过一段时间 SM 系统的日常运维和问题排查。为了排查问题，难免接触到不少代码，有合理的、不合理的，优雅的、莫名其妙的。SM 系统像一枚臃肿而灵活胖子——功能全面强大的同时，充斥着诸多不和谐的肥肉。

SM 已经存在很多年了，里面我看到了不少癫总写的代码。如此庞大的单体项目，迭代、运维、优化、拆分、重构都是非常困难的事情，因此才有”下SM”、”SM用户全量迁往Xspace”之说。

最开始接触SM，时序老师说，这个项目本地是没办法编译运行的（mvn dependency:tree 可能会把整台Mac搞挂），一般有问题都是直接上预发排查问题。这种腐朽程度其实已经有点可怕，不可预知的暗坑、难以排查的BUG、无处安放的新功能，无疑让人惴惴忐忑。

如此大一统的工程像一座高楼大厦，经过一代代开发同学参与进行搭建地基、粉刷、装修、修补、添砖加瓦。来了，走了，来了新的，又走了，或是换了团队，或是直接离职。每位同学的编码水平、编码风格不一样，对整体系统的理解程度有差异，设计思路也各有千秋。有时确实可能出现时老师说的”一直兢兢业业维护的第一代开发走了，带走了原始的设计思路，约束，规约，全局观。第二代，第三代开发半路接手，在自己熟悉的一亩三分地上继续耕耘，并不知道自己在用锤子给木板打补丁时，把旁边的墙也震坏了”的情况。在这种情况下，系统的运行状态在不断地恶性变化。腐朽，自然就滋生了。

造成IT系统的必然腐朽的重要因素有很多，这里也只说三个要素，系统属性、系统机制、人，和社会系统的腐朽如出一辙。

2.1 系统属性

是什么和为什么，不仅仅是哲学问题。

系统属性：包括系统项目背景、系统领域边界、系统宏观环境等。

项目为何而立，系统缘何而建，系统应是如何？这些作为立身之本决定着系统的生死。

谈及项目，都有一个背景，说明：为什么要立项，为什么要建设这个系统，建设系统能带来什么样的业务价值等。如果行业背景不成立、业务/市场/数据分析偏颇甚至错误，系统建设完毕很可能无人使用，空费时间、人力、资源。如果对于为什么要立项，没有达成一致，可能会对团队造成困惑，甚至造成误解。在项目实施过程中，难以形成合力，士气低落、效率低下，质量低下。

随后需要确立此项目系统的领域边界，哪些能力是此系统必须具备的，哪些能力应该对接外部系统，哪些能力抽象成服务赋能其他系统等。若系统的领域边界定义不清晰，则系统可能会面临四不像的境遇，后期变更边界可能将给系统内部带来无穷的混乱。这些情况下，项目极有可能会迅速腐朽乃至死亡。

宏观环境影响的面就更广了，影响系统本身的定位，也同样影响运行机制的效率、人员的效率等。

2.2 系统机制

在正视事物各个部分的存在的前提下，协调各个部分之间关系以更好地发挥作用的具体运行方式。

系统机制：包括系统业务及技术架构、系统工程机制、系统间关系、系统发布及运维等。

建设一个项目，我们需要对业务和技术进行架构，使用最合适的技术能力促进业务健康发展。

• a. 不合适的业务架构，难以最好地服务用户，也难以管理。

• b. 不合适的技术架构，难以迅速满足当前系统建设需求且不具备良好的扩展性。

• c. 不合适的工程机制，难以高效地协同开发者共同完成系统开发。

• d. 不合适的系统关系，难以发挥各系统最大能力，也可能会带来系统间协同隐患。

• e. 不合适的发布运维，难以高效实现实时迭代和故障排查，亦将消耗开发者大量精力。

这里说的都是”不合适”而不是”不好”，因为在很多情况下，不论业务或者技术，只有当前最合适的，没有永远最好的。

不合适的系统机制，会迅速催生腐朽，腐朽越来越多，最终造成系统崩溃。

2.3 人

自古人心最难测。同意么？

人：系统设计/开发/测试/运维人员、系统内外部用户等利益相关者。

系统由人来建设。设计、开发、测试、运维，任何一个过程，都会滋生腐朽。就如平日所说，总会存在不合理的设计、总会用一些不好的代码、总会有BUG测不出来、总会不小心删掉文件或数据库。

设计永无止境，这无可厚非，但设计人员不是使用人员，环境不同、场景不同，考虑的因素自然大相径庭。过度设计、反人类设计等为何会成为一个话题，是因为它们真的可能会给一个系统带来毁灭性的用户流失。

每个开发人员的素质不同，对业务的理解不同，代码质量自然良莠不齐。设计模式、优雅与否、运行性能，这些尚且不论，就功能来说，或许目前没问题，但可能将来它会造成一场大事故。

大家来找茬，你总能找得到吗？不一定。我们一直都说，没有不存在BUG的系统。测试人员没有找到的BUG，如果是个不容易复现但却十分致命的BUG呢？这是一个暗雷埋在系统中，什么时候爆炸？大BUG致命，一个个累积的小BUG，同样会让系统锈迹斑斑。

运维艰难，所以我们用DevOps？并不是所有企业都能用得起DevOps的，即使用，也不一定能用得好。何况，DevOps系统本身的可靠性由谁保证，又由谁运维？在难以依赖自动化的情况下，手动操作的安全，或许无人能保证万无一失。Github删库事故，便是血的教训，遑论想不开的程序猿同学删库跑路？

系统用户的脏数据、恶意攻击、不合理请求，同样会让系统腐朽。

3. 净化——化腐朽为神奇

净化和腐朽相伴相生，有腐朽必然有净化，除非死亡。腐朽的土地里，将长出花。

3.1 立项评审

为了具备良好的系统属性，我们需要立项评审。说到立项评审，必然会有人抨击：太虚、形式。

小微公司的项目自不必说，一般是CEO等人直接决定。当然，在小微公司，具备参与立项评审能力的人可能并不多，CEO等创始团队也一向以市场需求洞察者自居，因此他们做的决定，一般被认为肯定是正确的决定，肯定是最贴近现实的决定。但当今社会，创业公司做产品立项之前，不盲目跟风，而是真正对行业、市场、经济、竞争、产品等全方位因素彻底调研分析，且有能对审慎对待技术边界的公司又有几个？浮躁的创业市场，醒者几何？

中等公司的现状或许较好，不仅是因为它们从小公司成长起来很大一部分原因得益于早期优秀的立项评审结果，也因为它们的资源更丰富了，中等公司发展较快，所立项一般是围绕高速发展的业务进行。且对各方面的分析能力相对更到位了，组织也处于一个相对高效运行的阶段。

大公司对待立项评审带着些许暧昧。一般来说，大公司深刻地知晓立项的重要性，因为它成长至今的过程中，一定有至少一次非常成功的立项，也极有可能有过相当失败的立项。以阿里巴巴集团为例，支付宝、天猫、阿里云，这些大获成功的项目，到底经受过多少次评审（说得好听是评审，说得难听是争执、吵架、撕逼，尤以博士对阿里云的坚持为甚）可能外人不得而知，但却至关重要。而阿里内部失败的项目也是比比皆是，曾记否曾经ALL IN”来往”的尴尬？

因此，大公司对立项评审的态度是清晰的。比如投入大于XX人天的项目必须经过PX层次的立项评审等制度。但从宏观环境层面来说，大公司由于组织臃肿、体制庞大、人际关系复杂，必然在一定程度影响流程效率，这会间接影响评审制度的落地。有人会说”别人都觉得没问题，我觉得应该也没问题，何况他们比我经验多”，也会说”老板们提的想法，肯定没问题，我们跟着做就行了”。在很多情况下，最后便果真流于形式，务虚空泛了。这也是宏观环境催生系统腐朽的方式之一。

端正立项评审的态度，完善立项评审的制度，优化立项评审的流程，反馈立项评审的效果，是净化之意。

3.2 业务流程优化重组

重组是净化最重要的手段。在社会系统的更迭过程中，在不改变社会属性的前提下，历代皇帝一般是通过重组运行机制和人员的方式达成一次小净化。

当业务的发展遇到阻滞，分析当前业务流程中的症结所在，寻找优化或者重组业务流程的机会，或许可以带来新的发展契机。

这里大胆举不太贴切的双十一的案例。双十一在经过了多年的发展，从最开始的惊艳，到逐渐显得并无太大亮点，再到今年发展为极其复杂的优惠计算规则。反观友商，通过战线拉长、在价格大幅下降的前提下还能提前发货并保证品质等手段，取得了不错的成绩，令人眼前一亮。作为一个后端程序猿，不敢妄议双十一的未来，但作为普通消费者，确实希望明年双十一业务能有创新。

3.3 技术升级和持续改进

从技术层面，面对日渐腐朽的系统，技术升级和持续改进势在必行，这里的升级包括但不限于迭代、优化、重构、拆分，甚至推倒重来。

代码层面，优化代码实现，采用统一编码规范、封装、流式、协程、异步、多线程、优化算法、响应式编程及其他语言新特性等手段；设计层面，引入新的设计模式使系统实现更加简洁优雅、引入成熟工程框架简化开发等；架构方面，拆分功能模块、微服务化、平台化、SaaS化等。

内聚和解耦，从开始学编程就一直被反复提及，伴随面向对象编程理念的发展，更被广为传颂，它们其实在很长一段时间里都是在比较微观的代码实现层面闪耀。在系统架构层面，单体存在已久，拆分的概念却是直到SOA的概念或者微服务的概念兴起才被逐渐普及，虽然诸如阿里巴巴这种公司已经在SOA或者微服务领域实践了很多年。或许，企业规模或者项目大小是一个重要因素，在很多场景下，单体项目依然足够，但在未来可期的场景下，服务化的初始设计和实现也并非难事。

回到我们的SM系统，SM系统征战多年，功能强大。在多年的迭代过程中，除了滋生了很多腐朽点以外，同样有极多的优化点。新功能发布、旧功能优化、算法优化、结构优化、设计模式优化、性能优化等比比皆是，大小重构应该也进行过很多次，期间也有各种中间件引入和升级。

后期因为种种原因，开始逐渐拆分功能到独立的平台承载，完成系统的瘦身，直至今日，在长时间腐朽和净化的撕扯中，SM完全由Xspace取代也已经提上日程并且在紧锣密鼓开展中。

SM不是死亡，它的推倒和Xspace的崛起，其实是一次大的净化。新的平台从业务、架构、技术等方面都进行了较大的创新，在未来将更好地服务所有的小二用户。

4. 活102年

世上无永恒之物~

马老师希望阿里活至少102年，他没有说要永远活下去，因为不可能。

一个IT系统会腐朽，一个社会系统会腐朽，一个企业当然更会腐朽。

但是不管社会、企业还是一个IT系统，他们的存在，都是腐朽和净化之间不断撕扯的结果。

想要的长治久安，需要净化速度大于腐朽速度。

相关推荐：

• 《 颠覆微服务认知：深入思考微服务的七个主流观点 》

• 《 MySQL单表数据不要超过500万行： 是经验数值，还是黄金铁律？ 》

• 《 人人都是 API 设计者： 我对 RESTful API、GraphQL、RPC API 的思考 》

— 新书出版 —

— 本文结束 —

觉得对「服务端思维」有期待，请在文末点个 在看

喜欢这篇文章，欢迎 转发、分享 朋友圈

「服务端思维」是一个汇聚全国服务端技术人员的高端社群。我们希望让所有孤军奋战的研发人员都找到属于自己的圈子，一起交流、探讨。在这里，我们可以认知升级，连接顶级的技术大牛，连接优秀的思维方式，连接解决问题的最短路径，打破认知的局限。

1.技术社群「后端圈」邀请中， >>> (点击加入)<<< 

2.免费星球「服务端思维」限免中， >>> (点击加入)<<< 

在看点这里