先问“是不是”，再问为什么。

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

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

　　架构的挑战

　　阿里巴巴资深专家肖恩：

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

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

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

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

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

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

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

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

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

2. 无人对整体架构负责

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

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

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

　　架构设计阶段

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

在早期最重要的事情就是验证需求，验证产品是否能够满足用户的核心需求，是否能够被用户接受。这一阶段就是快速试错，通常以MVP的方式快速迭代，我们需要足够快地找到方向。

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

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

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