我的 20 年观察：分布式架构的演进和未来发展

4 月 25 日，由 InfoQ 举办的 ArchSummit 全球架构师峰会正式开幕。在本次峰会上，阿里巴巴数字供应链资深技术专家黄浩分享了自己这些年对分布式架构发展与变迁的观察和思考。本文为整理内容。

今天分享的内容主要是三个方面：

第一，大家在架构实践中遇到的一些问题和挑战

第二，个人对分布式架构发展的一些思考

第三，给大家的一些个人建议

什么是架构

首先，我们要理解什么是架构。对架构这个词，有很多不同层面的理解。从我个人来说，架构有两个非常重要的部分：一是称之为结构，另外一个是是结构之间构成的协作模式。我们看到，架构中会用到很多一些术语，比如 DDD 等。第二是我们在实现这多种关系之间，它们怎么相互合作。我们会看到，大家经常用的 Pipe line 方式，像流水线的方式，像 SOA 的方式，甚至像现在流行的事件驱动方式，还有一些在前端的 Reactive 响应式的方式，这些是架构的结构和协作模式。

架构的定义有时很广泛。有时关于架构的谈话，你会发现大家并不在一个维度上。实际上，在整个架构定义中，还有很多不同层面的定义。技术人员常说的架构，包括基础架构，这更多描述的是 IaaS 这一层以及物理部署的架构的东西。同时，还有更大规模的一些资源调度、协作以及这方面的实践。

业务架构可能是大家在一个业务系统里最常见的。一般来说，业务架构往往和产品架构中的相互关系比较大，但技术人员可能接触比较少。

第二是运用架构。即我实现一个业务、一个系统时，如何构造应用。我们绝大部分谈论的架构师在工程层面都是应用架构的实践，SOA、CS 架构、分层架构等。同时，还有数据架构，这相对比较少见。我们知道有中心式的数据架构、分布式的数据架构，比如大规模节点的调度。我们提到的数据中台，如何去构建我们的数据架构。

最后，最常见的是作为一个技术架构师去实现我们这样的一个架构体系。

架构实践中的不足之处

在谈基础架构的实践时，我想我们单纯去看架构实践上的一些不足。

缺乏很多好模式的的沉淀

最近几年，我们看到的架构模式，准确说来自 15 年前一本叫《企业架构模式》的书籍，比如分层架构、领域建模等，但实际上，经过这么多年，我们在架构实践领域并没有多少很好的模式的沉淀。

对架构的未来实践缺乏深思

其次，经过这么多年的发展，我们看到在工程架构层面，我们不断重复过往的一些前人的东西，不管是经验也好，还是失败也好。所以，未来的工程系统，我们的 IT 应用应该发展成什么样，其实在架构的实践层面是缺少这些思考的。

很多同学来参加 ArchSummit 大会时，希望获得一些东西，但在实际应用中，我们往往变成简单的复制。其实，每一个架构在面对不同业务场景和不同的工程问题时，它的差异蛮大。

概念混为一谈

我们谈到了架构分类，但是很多时候，架构是一人多职。在讨论或解决一些问题时，我们往往把应用架构、业务架构混为一谈，把应用架构和技术架构混为一谈，把应用架构和基础架构混为一谈。我们发现，这也是我们架构模式很难沉淀的一个原因。

业务场景变化给架构带来的影响

简单说一下，我对现在业务场景的一些个人思考：

第一是全球化。个人认为，无论是《中欧全面投资协定》的签署，还是疫情，我们可以看到中国的跨境出口，以及国际之间的贸易在变大，而不是在缩小。这带来的最大一个变化是全球化。现在，有些公司在全球化上做得相当不错了。

全球化会带来包括多样的一些市场环境，包括全球每个站点之间，它区域的一个封闭和差异，同时我们跨业务的这个规模逐渐在做到。对架构影响最大的是两点：一是网络的物理约束，这个物理约束来自于距离；二是来自于大家熟悉的网关。这些导致在全球化的多站点之间，信息很难及时互通或高效响应。

在面对全球化时，我们的架构应该有什么样的变化？我们的基础架构和应用架构、数据架构之间应该是什么样的关联？

此外，数据还会面临一些合规问题。这不像过去，我们可以中心化的存储到一个节点。我们每个环境，消费者的数据、企业的数据都必须留在本地。这样情况下，我们的应用、企业结构之间、基础架构之间怎么样去协作？

第二是本地化。现在，像社区团购这样的业务场景在蓬勃发展，但这带来一个很大变化。过去，互联网发达时，所有用户在每一个节点访问上来，它都是一个节点，它的流量回到一个所谓的中心。我们把所有的互联网当做一个整体，互联网的架构其实是一个中心化架构。简言之，所有的流量，所有的数据都是在我们的互联网中心机房处理的。

但随着本地化的发展，一些信息、一些数据和数据处理其实可以在本地完成，比如滴滴打车、周边三公里的团购。那这种场景下，架构如何协作？我们是中心化处理，还是分布式。在分布式下，我们说局部的热点，以及分布式每个节点的数据，如何跨节点进行联动？以及在每个站点里如何做到高效及时性的反馈？

最重要的一点。我们知道在互联网有一个很重要的数据思维叫 BASE 理论，其中一点是最终的数据一致性，高可用的简单性。这两点情况下，如果整个是分布式站点情况下，如何做到数据的高保真？

比如，我们去谷歌或百度搜索一个页面，背后的内容资源可能有几十亿条，甚至上百亿条，展现出来的是几百条，这几百条一定是那么准确吗？未必，我们可能会牺牲掉很多的数据一致性和准确性。但是在局部的一个本地化场景里，我们每个局部的数据可能只有几十条、几百条。当用搜索或用各种方法展现这些数据时，如果不能做到数据高保真，就有可能出现信息的丢失。

最近 3 年，架构演进的变化

现在，我们来看看最近 3 年，架构发生了哪些变化。

第一，比特币的诞生，它带来的一个最大好处是分布式账本技术，去中心化地实现了数据的一致性和数据可信性。

所以，如何实现这样一个分布式数据的一致性，这是一个很大的课题。阿里巴巴、蚂蚁一直在做区块链，我们的区块链技术也只能做到几百个节点。而比特币相对简单，更多涉及的是币种的交易，如果放到一个更复杂的交易模型，如何做到数据一致性是很大的一个特性。

第二，我们绝大多数人是学 Java 的。Java 在诞生时提出一个观点“Write One，Run Everywhere“。但实际上每个同学可以问问自己，看看周边的系统，我们到底有多少个应用？我们多少的代码是可以做到这一点？原因是什么？

原因是我们的技术体系，我们的应用一层一层进行了强耦合。我们很难做到我们的东西被迁移、被复制。那我们知道，在整个软件领域，架构层面的复用是最高等级的复用，但实际上我们很难做到。

第三，全球化架构，整个非站点的依赖性。任何一个企业，想做多站点部署或全球化部署时，我们的应用、我们的上层、我们的业务架构、我们的东西全部是强感知的。我们很难做到，今天在一个地方，可以在另外一个地方去消掉底层基础架构的差异，去模糊掉我整个网络的一些物理约束的差异，最后面是容器化技术和网格计算能力，在最近几年得到一个非常大的发展。这得益于一是云计算服务商提供的东西，更得益于像 K8s 这样一些容器化技术的广泛应用。

最后一点是对等架构。对等架构是一个非常复杂的，即去掉了中心化，每个节点相对于其他节点都是对等的。中心化节点一个最大的好处是非常有利于信息的快速转递，比如我今天的分享，是通过中心化方式传递给每个听众。但没有这样中心化的节点，信息传递的成本就非常高。失去了中心节点的另外一个好处是，信息传播的速度以及信息传播的这个价值性的传递是非常高效的。比如，信息在一群人中间传递时，它比中心化传递更快。

如果说，思考整个架构发展背后最重要的东西是什么？我觉得其实是理念。一个架构背后理念的东西决定了我们如何去思考架构，以及如何去定义、去设计我的架构。

架构发展最重要的几个点

第一是结构关系。分层结构是整个架构中非常重要的。但是，很多同学和一些架构师在理解分层结构时，理解错了。很多人学过，在最早 GEE 时要有分层模式，比如有服务层、DL 层、数据模型或数据域对象层，甚至还有代理层，这往往是一个非常简单的分层，它用到了分层结构的理念，但我们很多同学盲目抄袭这样一个结构。把本身可以很简洁、很好的一些代码写的非常复杂，但实际上我们很多人真正在架构分层时，就失去了这个理解。

比如现在有人谈云原生，有个重要公司叫 Cloud Foundry，它成功的原因是屏蔽了底层基础架构的差异，屏蔽了前面，它站在更高层面。它屏蔽了 IaaS，屏蔽了云公司、云基础服务商的差异，就像我们云基础服务商屏蔽了我们硬件上的差异一样。

Cloud Foundry 在 PaaS 这层屏蔽后，它其实就带来很多的可能，那我们很多时候，我们如何去看待分层架构，我们每一层东西对下一层之间的依赖和深耦合分别是什么？这个思想是一个架构师必须深刻理解的。

第二是对等结构，对等结构是非常复杂，但也是非常理想的和重要的一个这样的结构。我们过去的很多东西，比如很多流量的瓶颈，我们很多的这种处理的瓶颈，我们都会用一个中心化的方式。大家为了解决中心化的瓶颈方式的时候，会采用一种叫做中心配置的模式。大家可能听到过一个新概念叫软负载，软负载是什么意思？我们知道所有一种负载均衡过去流量达到一个节点，分发到不同的这个下枝节点上，软负载就算每一个节点自己来承担这样的一个负载，这其实是一个对等结构的一种转化。但是软负载里面有一个最大的问题，它还是会依赖于一个叫中心配置，把所有的配置的信息去管理这些节点。真正理想的对的节点，当我们的节点变成一个五千，甚至上万的节点时，这样的一个节点之间的横向调度，以及管理成本是非常高。所以说对等结构是一个非常好的，但是也是非常难的。

因此，我觉得每一个架构师在思考我们结构转化时可以考虑这个。

最后就是我们的计算模式，也是刚才达到对等结构以下，那我们的并行结算，我们的协作这个是一个非常重要可以思考的方式，如何去调度？我们之前谈到云计算、云原生，比如跨云和多云的结构，它对我们云原生的挑战，其次就是包括我们的云边一体。在谈到本地化后，边缘计算和云计算如何结合，如何做到云边一体的协作。今天我们的云边是强感知的，准确来说叫端，并不叫边，端是什么？其实是一个交互的结点，它对整个的计算，它并不参与真正的计算，它更多的是我们跟外界之间交互和信息这种传递的结果。

说实话，今天的云计算还属于初级，每一个人在云计算机房去购买一个东西的时候，他还是说他强感知，深圳的机房，上海的机房，什么时候云计算真的变成一块云，那我们的架构就会发生很大的变化，这样的关于弹性架构，那我们说整个弹性架构的东西，就包括对等的结对调度，包括我们的柔性的横向的适应，包括我们刚才说的多结点，非中心化的一个协作计算，最后面是分层依赖的能够实现我们低成本的横向迁移，这些是整个弹性架构的一个发展情况。

建议

许多用户来参加 ArchSummit，我们听到每一位讲师分享架构的一些实践、一些经验。我们如何去学习，我觉得有几点可以分享给大家。我希望大家可以了解，每个架构背后需要解决的问题是什么。我们可以讨论，去强调我谈到的协作和结构，它使用的架构模式是什么？哪些模式是可以被抽象、被沉淀、被复用，最后是每一个分享者他在实践过程中，遇到了什么样的问题，他是如何解决的，每一位分享者，他分享这些经验时，其实它背后有哪些思考的不足和处理的不足，这些东西就是我们每一位听众在听分享时可以收获的。我希望每一位架构师不仅仅是一个问题的解决者，也不仅仅是一个问题的分析者，而成为一个优秀问题的定义者。