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

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

我们采访并整理了过去部分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业务也会迫于营收目标和压力扩展好多条产品线，相应地为了支撑这么多产品线也扩充了技术团队来构建相应的支撑能力。

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

2017年应该怎么做？

ArchSummit全球架构师峰会将在7月7-8日深圳华侨城洲际酒店举行，我们将继续邀请海内外知名技术专家前来分享前沿的架构设计和典型的案例剖析，部分选题如下：

Facebook Engineering director,Joel Pobar:

Joel将分享 Move Fast and Break Things: Engineering at Facebook

Facebook一天几十亿的点赞，一天几亿的照片上传，上百个Perabytes的可搜索数据和数个大型数据中心，每天两次上线，平稳无误，这就是Facebook的软件工程！

Joel将深入讨论Facebook是如何"ship things"，包括Facebook的发布流程，A/B测试，Gatekeeper系统，测试系统等等。

Architect and Engineering Manager, Mike Magruder:

Mike将分享 Mobile Performance at Scale

每天在世界各地，超过10亿的手机在运行着Facebook的多个移动应用，这个演讲将分享Facebook对移动应用性能这个工程问题的理念。

Mike将解释团队遇到的一些挑战，展示移动应用性能是如何成为一个大型的工程问题，以及如何将性能第一深入到工程的各个环节。之后Mike会介绍一些性能工具，并着重深入介绍性能退化检测的工具。

阿里巴巴安全部首席架构师潘爱民：

潘爱民将分享《复杂性：架构设计中的挑战》

复杂性是一切系统设计困难的基础，对于大型的分布式系统更是如此。在架构设计中，已经有大量的经验和实践用于对抗这些复杂性。

这次从多个维度剖析了架构设计中的复杂性，包括消息传递、性能优化、数据同步、成本优化等，同时潘爱民也总结和分享了一些在实践中被广泛使用的措施来缓解这些复杂性。

腾讯运维总监聂鑫：

聂鑫将分享《腾讯监控创新术》

腾讯社交业务规模庞大，历史悠久，架构复杂。从运维的全局角度来看，无论从运维技术还是监控难度都很大。

传统的监控手段和思想已经无法应对如此海量的场景，腾讯社交网络运营部历经十年的建设，在运维监控领域经过了多个建设阶段。

近几年通过创新的方法引入了多种技术手段并实践落地，将监控技术带入一个新的运维高度，本次将主要分享四个创新技术点。

京东运营研发部系统架构师王梓晨：

王梓晨将分享《海量地址的狂欢：京东智能分单平台性能提升之路》

本次分享旨在揭秘如何基于海量数据打造低延迟、高可用、高精准度的智能分单系统。中国物流规模已居世界前列，海量的数据与复杂性给电商系统提出了较高的性能要求。如在下单环节，用户填写的地址参差不齐，如何快速有效的识别正确的地址，给行政区划错误、地址层级缺失、小区名称错别字以及不同城市道路河流差异性的地址做归类是一大痛点。

京东智能分单系统应运而生，根据用户下单地址计算配送信息的系统，在用户下单时可以通过系统计算出仓储到配送员的全链路信息，迅速计算出包裹需要“飞走”的最佳路径。

ArchSummit全球架构师峰会作为业界最受关注的技术峰会之一，届时与会的上百位的技术大牛和千余名技术同行一定让你有所收获，更多确定的演讲嘉宾欢迎各位点击「 阅读原文 」。

大会目前 限时 8 折，欢迎报名锁定席位，如果在报名过程中有遇到任何问题，都可以联络我们的售票天使豆包，QQ：2332883546，电话：18515221946，微信：497788321