什么是架构腐化，架构设计之初总是追求简单易行需求优先，甚至得益于优秀的框架和新技术，这个开发阶段非常愉悦高效，但随着项目周期的增长和技术人员流动，一些公共问题开始逐渐显露，例如复杂性提高、过度设计、包袱越做越大等等，最后演变为开发人员屡屡唾弃的架构腐化现象。

我们采访并整理了过去部分ArchSummit全球架构师峰会的技术专家，如果你担心会遇到同样的问题正在寻求避免，或者已经面对同样的问题并在试图解决，下面的一些回答可能可以给你启发。

架构的挑战

阿里巴巴资深专家肖恩：

记得我最初几年在做Dubbo时，参与过几个项目的服务化改造。当时的工作是通过梳理一个巨无霸应用的功能和范围边界，确定出一些核心的领域模型概念，基于这些概念，划分成子系统剥离出业务接口，然后利用Dubbo等RPC框架部署成独立的服务集群。因此这个阶段的服务治理，主要就是抽丝剥茧地分离大系统。

到了中后期，服务化被广泛使用后，我们就遇到了接口泛滥、版本控制、循环依赖等各种新的问题。

到了全民无线的时期，对服务化的新要求则是针对移动应用领域如何进行优化和支持了。

后来我在带领团队做一些重要的移动App的时候，因为多变的需求冲击，产品功能设计也不够充分，加上团队也比较稚嫩，所以那时候App的架构腐化得更快，到后来基本只能在原来代码上面堆砌功能，因为推倒重来的代价太大，因此非常痛苦。

滴滴平台产品中心技术总监杜欢：

从单一业务线发展到多业务的时候，滴滴架构的阵痛具体来说有三点：

1. 代码重复度高，耦合严重

任何一个微小功能都可能产生牵一发动全身的严重问题，滴滴是一个客户端很重的应用，一个 App里面融合了好几个独立产品线的功能。在重构前，客户端缺乏一个分层合理、依赖清晰的框架，每次对外发版前的测试都很让人崩溃，任何一个业务修改任何一个bug都可能会有全局的影响，所以所有业务得再全部重新回归一次，明显很浪费时间。

服务端则更严重，滴滴最大业务的代码有数百万行，前后有数百人经手，有些似是而非的逻辑谁都不敢动，而且代码风格还特别不好，总喜欢写长函数、大量复制粘贴、用没有约束的哈希表来传递各种参数等，这让在此之上添加新功能变得极为有风险。

2. 无人对整体架构负责

滴滴缺乏一个可靠的底层基础设施封装，低水平建造比比皆是。这点主要体现在滴滴客户端。去年重构之前，安卓平台上滴滴各个业务用了市面上几乎所有流行的网络库，因为缺少整体架构，大家都是以自己的喜好和以前经验来选择方案，在某个第三方成熟框架上二次封装了事。这种做法明显非常浪费人力，所有的网络优化都需要在所有业务的封装上实现一遍，而且业务本质上也没有精力和能力来持续优化技术点，所以需要一个整体封装。

3. 业务需求本身也缺乏抽象：

看起来类似的业务也有各式各样个性化的需求，这导致技术很难轻易找到整合的方法，最终在不断分化的路上越走越远。最典型的就是滴滴的出租车和专车，如果不加上任何限制，这两个业务每个细节都可以做出不同点，技术上显然不可能找到方法将他们硬是合在一起，但实际上它们的核心业务逻辑是基本相同的，只是运营手段不同、界面皮肤不同。需求分层做好了，要想做好技术就非常自然了。

架构设计阶段美团外卖资深技术专家曹振团：在早期最重要的事情就是验证需求，验证产品是否能够满足用户的核心需求，是否能够被用户接受。这一阶段就是快速试错，通常以MVP的方式快速迭代，我们需要足够快地找到方向。

随后美团外卖的架构经历了自由发展阶段、故障驱动架构、架构驱动改革等阶段。

自由发展阶段： 业务起步的时候，大家公用服务和数据库表，这样能够快速支持产品迭代。产品和技术人员聚焦在快速验证产品功能上。这个阶段主要的特点就是集中，所有的功能都集中在几个项目里，所有的表都集中在一个库中。

故障驱动架构： 随着业务的爆发增长，早期的架构出现了很多的问题，系统频繁地出现稳定性的问题，共享数据库表导致业务逻辑散落各地、甚至实现不一致的情况。这时系统稳定性问题倒逼架构进行优化调整，进行了服务化拆分，服务之间全部用接口的方式调用。

架构驱动改革： 随着单量的快速增长，系统故障所造成的损失是巨大的、不可接受的。需要从架构驱动技术体系的改进、甚至推进产品和业务的变革。同时增加业务的容灾能力，进行了多机房的部署。

美丽联合集团技术专家七公：

我加入蘑菇街电商团队后带领团队同学仅用一年便完成服务架构的各阶段升级，主要分以下阶段：

第一阶段蘑菇街系统拆分&服务化1.0体系构建 ，是我们做PHP全面转型Java体系、初步建成电商基础服务中心的战略规划，在面临不停歇的业务需求和巨大的系统改造压力下，我们采用瀑布流工程方法，通过规划、分析、设计实现、测试、服务产品&文档交付的过程，高质量地把第一阶段的服务化建设根基像打桩一样打牢，然后通过进一步的迭代开发不断完善。

第二阶段购买链路核心服务的性能提升&服务架构1.5 和第三阶段服务SLA保障推动稳定性提升&服务架构2.0 ，实际上是业务迅猛发展、流量不断上涨、日常和大促稳定性保障的强烈需求推动我们自身服务架构的升级。我们通过引入Scrum的敏捷开发模式，项目中的每个人都是猪（敏捷开发中，猪为项目负责人，鸡只是普通参与者，寓意来自猪要牺牲才能提供食物而鸡只要下个蛋就行了），每个人都要为服务框架升级和项目进展负责。

如何评审架构

唯品会资深架构专家张广平：

对于是否做架构评审，我们通常有个筛选标准：看看项目是否对主流程产生影响，考虑到一些关键性的修改对项目的影响，我们有以下几个比较主要的关注点：

设计是否满足系统需求，包括功能、性能、兼容性、可靠性等；
涉及新技术基础组件的引入；
核心业务流程变动；
与核心业务系统交互变动；
与外部系统交互变动；
主要系统的边界划分；
是否符合公司制定的架构标准规范；
是否符合安全规范；
脱离实际情况的容量规划；
是否涉及系统重复建设问题

美团外卖资深技术专家曹振团：

架构通常是为了解决系统的高并发、高性能、高可用的问题，结合业务特点在研发资源、排期、技术方案之间做平衡。一个“坏”的架构则破坏了这种平衡，比如：由于工期紧张而引入了一个自己并不能把控的技术方案，为系统的稳定性埋下了雷。

有一个简单的判断标准是：当采用这个架构后在未来多长时间或几倍增量下需要调整架构。基本上要求至少在未来的半年到一年内或2倍增量下不需要调整架构。如果架构设计评审不符合这个标准就要及时重新设计或调整。

京东商城研发部架构师林世洪：

凡事预则立，不预则废，需要给架构设计者一个设计原则，必须遵守，即did原则：design 20倍体量，implement 3倍的体量，deploy 1.5倍的体量。这里的体量结合非功能要求来说，可以是吞吐量、存储容量等。

要贯彻这个原则，需要对业务量的发展有预判，对系统处理能力有评估，对设计方案有评审，对资源申请有审核，对线上资源利用率有监督，这些流程对应的手段很多，这里不多赘述。

除了体量之外，还是一个先进性跟踪的问题，架构设计上如果过于超前，对于技术开发人员要求较高，往往需要专业的团队，这样成本会有相应的增加。如果技术开发人员的水平跟不上的话，就会影响业务的变化。

架构团队的思考

阿里巴巴速卖通技术部总监郭东白：

构建大团队的时候不希望出现匹夫之勇来打仗，现在modern打仗不能靠匹夫之勇，你其实是希望设计一套系统能够让所有人一起创新 ，第一要创新，第二要集体创新，即democratic team，每个同学都应该赋能给他，甚至一个小兵也可以协助你打仗，而不是只有两个将军打仗。

Twitter机器学习平台组负责人郭晓江：

机器学习在业界应用的两大目标是规模化(Scalability)和灵活性(Flexibility)。规模化是系统方面的要求，强调高并发、稳定性、高可复用性等，是应用到产品中的关键；而灵活性是要求能够快速迭代，不断尝试新的算法。

组织结构上一般会有两个平行的团队，一个偏重算法研究，比如Google和Facebook都有专门做机器学习研究的团队，主要是解决灵活性的问题；另一个团队是偏重机器学习平台，和产品应用结合的比较紧密，主要解决规模化的问题。

杭州征数技术合伙人&CTO王福强：

很多时候，一个公司在技术层面表现出的种种问题，本质上引发这些问题的根源往往不在技术本身 。所以我做技术顾问不会一上来就扎进去技术细节当中去，而是从业务到团队和组织结构，再到技术这样的步骤进行梳理和诊治。

以当前朋友公司的案例来讲，他们公司做对B业务，但作为创业公司，即使是对B业务也会迫于营收目标和压力扩展好多条产品线，相应地为了支撑这么多产品线也扩充了技术团队来构建相应的支撑能力。

随着技术团队的扩张，团队的技术文化氛围、技术选型的多样性和复杂度都被稀释并扩散。可以看到：业务层面的决策导致的问题会外延式的向下游扩散，从而导致更多的问题 ，可以说所有的问题都可以归结为业务上的问题，而不是技术上的问题。

本文收藏来自互联网，用于学习研究，著作权归原作者所有，如有侵权请联系删除

markdown @tsingchan

部分引用格式为收藏注解，比如本句就是注解，非作者原文。

作为优秀的架构师如何面对架构腐化

目录