vlambda博客
学习文章列表

今天分享的东西主要关于三个方面：

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

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

• 第三，给大家提供一些个人建议

首先，我们要理解什么是架构。架构这个词有很多不同层面的理解，从个人来说，架构有两个非常重要的部分：

• 一个称之为结构，另外一个是结构之间构成的协作模式。架构中会用到很多的一些术语，比如 DDD 等。

• 第二，我们在实现这多种关系之间，它们怎么相互合作。我们会看到，大家经常用的 Pipe line 方式，像流水线的方式，像 SOA 的方式，甚至像现在流行的事件驱动的方式，还有一些在前端的 Reactive 响应式的方式，这些是架构的结构和协作模式。

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

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

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

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

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

其次，经过这么多年的发展，我们看到在工程架构层面，我们不断重复过往的一些前人的东西，不管经验也好，还是失败也好。所以，未来的工程系统，我们的 IT 应用应该发展成什么样，我们在架构的实践层面缺少这些思考。我们很多的同学来参加 ArchSummit 大会时，希望获得一些东西，但在实际应用中，我们往往变成简单的复制。其实，每一个架构在面对不同业务场景时，面对不同的工程问题，它的差异蛮大。

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

简单说一下，我对现在业务场景的一些个人思考：第一是 全球化。个人认为，在中国，包括《中欧全面投资协定》一签，我们可以看到，中国的跨境出口，以及国际之间的贸易在变大，并非在缩小。这带来的最大一个变化是全球化。现在，有些公司在全球化上做得相当不错了。

全球化会带来包括多样的一些市场环境，包括全球每个站点间，区域的封闭和差异，同时我们跨业务的这个规模逐渐在做到。

对于架构影响最大的在于两点：一是网络的物理约束，这个物理约束来自于距离；二是来自于大家熟悉的网关。这些导致在全球化的多站点之间，信息很难及时互通或高效响应。

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

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

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

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

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

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

在 2018 年，我对架构的演进提出了五点思考。最近 3 年发生了哪些变化。

比特币的诞生，给我们带来的一个最大好处是它分布式账本技术，它去中心化实现了这个数据的一致性和数据可信性。所以，如何实现这样一个分布式数据的一致性，这是一个很大的课题。到目前未知，阿里巴巴、蚂蚁在做的区块链，我们的区块链技术也只能做到几百个节点。而比特币比较简单，更多是币种的交易，如果放到一个更复杂的交易模型，如何做到数据一致性是很大的一个特性。

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

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

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

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

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

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

比如现在有人谈云原生，有个重要公司叫 Cloud Foundry，它成功的原因是屏蔽了底层基础架构的差异，它屏蔽了前面，它站在更高层面，它屏蔽了 IaaS，屏蔽了我们的云公司，云基础服务商差异，就像我们云基础服务商，我们屏蔽了在我们的操作系统，或者是屏蔽了在我们的硬件上面的差异一样。Cloud Foundry 在 PaaS 这层屏蔽后，它其实就带来很多的可能，那我们很多时候，我们如何去看待分层架构，我们每一层东西对下一层之间的依赖和深耦合分别是什么？这个思想是一个架构师必须深刻理解的。

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

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

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

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

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

过去的 20 年里，大数据 & AI 系统的技术架构演进由三方面推动：海量数据分析需求、开放开源的技术进步、以云为代表的软硬件基础设施升级。7 月 9-10 日，ArchSummit 全球架构师峰会深圳站，应云而生的新一代数据架构专题试从“云原生”的视角，与参会者同行探讨新一代数据平台的架构迭代方向。

扫描下方【二维码】或点击底部【阅读原文】了解更多专题及深圳站内容。

点个在看少个 bug 👇