浅谈架构现状：设计越来越复杂，行业缺乏系统性思考

采访嘉宾 | 黄浩

从之前单纯的高流量到现在高流量、高并发，企业面对的业务场景越来越多，对系统的各项要求也越来越高，这意味着对系统架构的要求也越来越高。

在过去很长的时间里，集中式单体架构是主流。单体架构设计难度小、响应时间快，但系统吞吐量小、扩展性也比较差，在面对新的业务挑战时，显得力不从心。随着云计算的发展，高系统容量和高可用性的分布式架构越来越受欢迎。但越流行就越好吗？现在架构领域都面临着哪些问题？近日，InfoQ 采访了在分布式架构领域拥有二十年从业经验的阿里巴巴资深技术专家黄浩，来谈谈他所看到的架构现状和挑战。

新架构模式的技术局限

架构领域在经历了模块化编程、面向事件设计、面向接口设计等一系列发展后，1996 年，Garnter 提出了 SOA 概念，将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务将不同接口和协议联系起来。现在，SOA 已经被很少提及，大家提到最多的是往往微服务。

分布式架构系统使模块重用度更高，开发和发布速度变得更快。但新的架构模式在解决问题的同时，也会带来新的问题。分布式架构首先就面临着高复杂度的问题，这主要体现在以下三个方面：

l 协作模式。多台机器之间如何协作是非常重要的，选择主从模式、对等模式还是其他协作方式，直接决定了系统最后的运行效率。l 数据一致性。单体架构中，数据的存储、读取和计算等都在一处，处理起来很方便，但在分布式架构中，会有多处进行数据处理，那如何保证服务器间数据在同一时刻是一致的、客户端读取的都是最新结果？l 效率问题。限制效率的因素有很多，除了跨机房、跨地域的分布式架构自带的物理限制，还有节点规模越来越大而带来的沟通效率等问题。

为了解决上述问题，一开始企业采用了简单的主从结构协作模式，即设置一个中心节点来处理相应的事务，类似班级里班长的角色。但这种架构天生带有一种危险因素：中心依赖。中心节点对吞吐量要求很高，一旦挂掉系统就会处于“群龙无首”的状态。

随着进一步演化，这个“班长”不再固定，变成各节点动态“轮值”，类似企业 CEO 轮值，然后再通过层层分级的管理方式实现整体管控。

这里就要提到分布式系统中的 CAP 原理：一致性（Consisteny ）、可用性（Availability）和分区容错性（Partition Tolerance ），这三者是无法同时满足的。比如，分区容错性能够解决集群分区问题，但网络故障导致分布式系统各组件之间产生分区，便无法同时满足一致性和可用性。

在典型的区块链分布式账本技术中，虽然强调不存在中心节点，但也有分区政策。比如一笔交易并不会让所有节点记录，达到一定比例即可被加到账本中。完全的分布式账本思路很优秀，但现实适用性还不够好。拿现在分布式账本上做得最好的比特币网络来说，因为系统采用了简单的存储和计算模型，在效率等方面就做出了牺牲。

回归到分布式架构，层层分级的管理方式虽然保证了一定的分布式理念，也避免了节点数量过多而使架构整体更加复杂，但却不是真正的“去中心化”。

互联网最核心的思想是去中心化，但全部去中心化是不现实的，所以弱中心化称为当前企业普遍采取的折中策略。哪些该集中，哪些该去中心化是企业需要思考的问题，但很少有人认真思考这个问题。

传统单体架构与分布式架构的对比，来源：陈皓《左耳听风》

分布式架构带来的数据可信和一致性问题，一直是困扰各企业的问题。据黄浩介绍，目前常见的方案主要是采用双保险策略，一个链路（RPC 或消息）进行数据正常的访问，而另一个链路（RPC 或消息）进行请求的重试或者稽核对比。。另外就是选出中心节点的方式，但问题还是前面提到的的偏中心化。当然现在也有些企业也将目光放到了区块链技术上，希望从分布式账本中得到启发。

“分布式架构的初衷是通过减少彼此联动来提升效率，但我们往往在架构设计上没有把应用架构和技术架构之间进行解耦，一个纵向上下牵连因为分布式横向的扩张，其实是将原本清楚的世界变得混沌，这也使得系统变得不可预测。”黄浩说道。

据观察，分布式架构面临的问题在发展之初就已存在，但经过多年发展，技术突破并不大。很多前几年就已经在讨论的问题至今仍在困扰着架构师们。

架构变得越来越复杂

虽然技术迎来重大突破需要时间，但企业发展不等人，该做的升级还是要做。从单体架构到分布式架构演进并不太难，但难的是如何在业务快速发展变化的情况下，及时升级架构。

去年，新泽西州政府急聘能够使用 COBOL 语言的程序员，帮助修复已经使用了 40 多年的失业保险系统，时薪 55 美元至 85 美元。COBOL 的鼎盛时期是在上世纪 70 年代，这意味着美国大部分 COBOL 程序员可能已超过 60 岁。同样在很多成熟科技企业内部，也还在使用很久之前的语言版本。这些遗留问题都会是架构升级中的障碍。

另外，固化的企业架构注定是难以改变的。以同样是电商的淘宝和拼多多来说，淘宝是面向商家，基于店铺体系，而拼多多更加面向商品，弱化了店铺、购物车等，这些都决定了两者的底层架构是完全不同的。定型的底层架构已经形成了自己的理念体系，牵一发而动全身，架构师要跨出这个体系做改变会很难。

黄浩建议，任何企业如果要做持续演进就需要事先做好架构强管控。越成熟的企业到后期越难进行架构升级，适当提前考虑未来几年的企业变化并为此做好准备是很有必要的。“比如现在蚂蚁的架构从 1.0 演进到 3.0，虽然现在并不知道 4.0 的架构会是怎样，但通过强管控，未来任何升级都有很强的可操作性。”

与此同时，很多架构的理念正在被误解和滥用。以分布式架构中常见的的分层架构模式，在很多应用的服务端开发时，会人为创建好几层的所谓接口和服务定义隔离层，然后每层都进行重复的对象复制，把一个应该内聚的问题变成松耦合。这样反而将原本简单的问题复杂化，开发实现实际上是非常低效的。

在黄浩看来，“这是一个很重要的问题，也是一个很普遍的现象。”

虽然整个行业并没有统一的标准，但每个架构应该有自己的标准。“加什么、不加什么应该有相应的规范，开发者不能随心所欲，架构师也需要被约束。”黄浩表示，现在互联网已经越做越复杂，企业在架构设计上更应该做的是减法。

黄浩根据自己的观察得出了一个观点，互联网的工程应用方式在未来的场景里会有越来越强的冲突感。比如现在微服务很受欢迎，但它在一定程度上其实是在破坏架构，碎片化的东西是没有架构可言的。

需要更多系统性思考

目前，国内企业在架构设计上存在一个很普遍的现象：一个业务一个架构，业务一换架构就要从零重新开始。

这主要是由于国内企业大多都是业务驱动型，包括现在头部的互联网企业，基本都是围绕业务来做技术应用输出。这种业务垂直的技术一旦环境改变就无法继续使用，企业有新业务时只能再花费人力、物力开发新架构。内部如此，对外更难将自己的技术沉淀形成技术模型输出，并被其他企业复用。

反观国外的一些企业，比如 IBM、Google、微软和 Oracle 就是典型的产品型企业，这些企业在一开始的定位就不是服务自己的业务，而是其他企业。他们的架构设计思路更偏向工程思维，不只考虑当下的业务场景，还会将整个行业面临的问题也囊括其中。

国外更擅长生产“一类产品”而非“一个产品”，虽然简单但可以被快速复用，天然具备了基础设施特质。

Amazon 的前员工 Steve Yegge 在早年间发文透露，2000 年初，亚马逊的目标就已经是要做一个可以输出基础能力的平台。在贝佐斯看来，产品并不能受每个人欢迎，但基础平台却可以被广泛应用。

这种思维差距导致了现在很多架构模式都是国外先创建然后国内再引进使用的现象，虽然国内有更丰富的应用场景。

在黄浩看来，根据实践总结出自己的业务模型和设计理念，这才是架构师应该具备的最核心的能力。但可惜的是，现在很多架构师都是在重复前人的经验，并没有对未来进行思考。

“分布式架构有很多问题需要时间来解决，但这个过程中，我们能否提出自己的创新思路和解决方案呢？”

黄浩指出，现在架构师普遍存在三个问题。首先是职责不清，业务架构、应用架构和技术架构三者其实并不相同，但很多架构师并不清楚自己在其中究竟扮演着什么角色；其次是一致性匹配问题，现在 PPT 上的架构图和现实应用的架构之间有很大的差异，架构师很难在两者之间建立联系。但最重要的还是缺乏系统性思考。

“国内很多分布式架构直接照搬国外，这样是不行的。架构师应该多观察、多思考、多分析和多探讨，从问题的解决者变成问题的分析者，最终成为问题的定义者。”黄浩表示。

架构领域有很多技术问题需要解决，需要更多的创新思维打破现状。架构师不是简单的执行者，更是企业蓝图的规划者，其实任重道远。

采访嘉宾：

黄浩，阿里巴巴资深技术专家，TOGAF 认证架构师，现任阿里巴巴数字供应链平台供应链技术负责人。