分布式应用的未来 — Distributionless

 

作者丨阿里云高级技术专家 至简（李云）

 

在技术变革推动社会发展这一时代背景下，大量支撑规模化分布式应用的技术创新、创造与创业应用而生，Could Native、Service Mesh、Serverless 等技术词汇在全球范围内引发了大量的解读与讨论。本文整理自阿里巴巴高级技术专家李云在 QCon 北京 2019 的分享，带你一起看清其背后的本质与驱动力，更好地把握技术趋势并建立自己的思考逻辑。

 

围绕解决大规模分布式应用技术挑战的话题总能引起广泛的关注，CNCF 所提出的云原生概念将这一话题推向了前所未有的新高度。

 

就目前的行业发展现状来看，云原生是分布式应用走向未来的关键路径。此外，出现了 CDF 从 CI/CD 的角度帮助解决未来分布式应用周边的的挑战等现象。我们不禁要问：“分布式应用的未来究竟是什么？”面对这一问题，具象化地给出所有人都能理解一致的描绘在现阶段是不现实的，但给出一个相对模糊但又抓住重点的概念或许并不困难，作者用 Distributionless（无分布式）去表达。

 

在全球范围内带来变革的技术，其背后不只是技术因素，还有商业利益的共同演绎。理解背后的驱动力能让我们更准确地抓住新技术的优势和思考未来发展的可能终局，这对于 CTO、CIO 等各类技术决策者来说至关重要。

 

解决复杂问题的终极范式

 

技术最终是服务于商业和社会的，但在“条条大路通罗马”的情形下，如何判定一个技术比另一个技术更优呢？或者说，在技术向前演进的过程中，有没有固定的范式可被我们掌握，从而将之运用于理解新技术的优势呢？这个终极范式在作者看来就是“抽象后分而治之”。

 

探索复杂规模问题的解决方法从来都是动态、渐进的，会经历不断认识问题和寻找更优解的持续迭代过程，期间伴随着部分“旧概念”被打破和“新概念”被重塑的双重行为。

 

比如，在实践微服务软件架构之初，一开始大家所关注的焦点是“如何拆”、“拆多大”以及技术与组织架构的配称（康威定律），核心思路是通过将单体应用通过分拆去变成更小的软件发布单元，以解决单体应用的软件迭代速度慢的问题（背后导致了商业价值创造慢的后果）。

 

然而，当微服务改造工作完成且微服务的个数达到一定的规模时，各服务之间的连接、排错、安全保障、监控等问题就逐渐地浮出了水面，那时行业深刻地体会并认识到微服务软件架构其实是将复杂度从单体应用内转移到了微服务之间。

 

随着分布式应用规模的进一步增大，所涉开发和运维人员增长到一定数据时，效率问题再一次变得像单体应用时代那样不可小视。不过，这一次所面临的问题域和规模比那时大了很多。

 

要解决微服务软件架构所带来的新问题，需要探索更加体系化、规范化和全局一致的解决方案，那就不可避免地会采用新的概念切分手法去构建新的解决方案，期间不可并避免地会打破旧概念并创造出新概念。

 

新旧概念相比之下，存在如下差异：

 

• 旧概念更侧重于局部最优，不同旧概念之间的衔接存在生硬的现象。对复杂问题的探索从来都渐进式的，因而对问题的理解是一个从局部走向全局的过程，出现这样的现状是非常正常的现象。对于软件系统来说，其软件设计质量可从概念是否优雅、流畅去体现。子系统之间的概念衔接生硬往往意味着软件设计缺乏全局观，以致衔接处埋藏了不少丑陋的代码，因维护成本高而影响了整个系统的演进效率和解决问题的有效性。

 

• 新概念更加抽象，塑造的目标是为了实现全局最优（体系化），并满足更多利益相关者的不同诉求。由于设计时的问题域更大、格局更高，所以子概念之间的衔接相当流畅，体现出了软件设计的整体感和一致性。

 

“抽象后分而治之”为技术人提供了一种单纯从技术视角去分析一种技术是否优于另一种技术的方法，能一定程度避免被“老酒换新瓶”那样的新概念所蛊惑。以这一范式去看待围绕云原生所出现的 Kubernetes、Istio、Knative 等技术，相信能因这些新技术的概念切分独特、更具体系化和有更高的技术视野而对其先进性加以认可。

 

云原生的驱动力及其本质

 

新技术得不到推广应用并最终消亡的例子举不胜举。云原生概念从提出到今天在全球范围的如火如荼只经历了短短的四年，背后的驱动力是什么很值我们思考。此外，云原生技术的概念目前仍相当模糊，理解其所解决的本质问题才能使技术团队在发展的道路上正视趋势，以及让技术决策者更好地规划技术发展方向。

 

从商业的角度，AWS 是无可争议的云计算市场的领导者，但其技术影响力远不如 Google。虽说 Google 在技术实力上是全球的领导者，但在云计算市场的发展上曾带给人的傲慢感而最终没能在市场表现上与 AWS 相庭抗礼。在面对市场占有率落后的情形下，Google 发起了 CNCF 基金会，通过提出云原生技术致力于打造厂商中立（vendor-neutral）的开源软件事实标准，希望有机会以另一种路径在市场中获得突围。“厂商中立”又意味着什么？

 

输出技术产品的厂商与其客户之间一直存在一种利益博弈——技术锁定和防锁定。当厂商所输出的技术无法在短期内立竿见影地给客户创造业务价值时，这种博弈的痕迹就会更加明显，否则客户在短期内也乐于被锁定。从厂商的角度，通过技术锁定客户就会有更高的要价空间和持续的利润来源。反之，如果客户做到了技术的防锁定，则有更强的议价能力和选择自由，否则会担心成为“砧板上的鱼肉”。长远来看，如何保持这种博弈力量的平衡是打造一个繁荣技术或商业生态的关键。这样的案例在业已成熟的通信行业很早就出现了且仍在发生。

 

通信行业有一个标准化组织叫 3GPP，这个组织中有来自中国移动、中国联通、中国电信这样的各国电信运营商，也有来自华为、ZTE 这样的全球通信设备制造商。3GPP 通过制定规范并要求所有设备制造商全面遵循，使得运营商有从哪家采购通信设备的自由。回到云计算市场，在通讯行业的规范变成了大家共同构建和采纳的开源软件，准确说是事实标准的开源软件。

 

事实标准的关键不是开源，还得加上所有云厂商都采纳，这一点对于提供云基础技术的云厂商来说特别关键。具体的一个例子是，Kubernetes 是云原生中的基础设施并得到了所有云厂商的采纳而提供相应的云产品。当一个客户采购了 AWS 的 Kubernetes 产品时，可以随时方便地迁移到阿里云上而不用担心技术锁定问题。不可否认，云厂商提供云产品与用户自建是完全不同级别的可用性保障维度，这一点是很多客户乐于花钱购买云产品的关键。

 

技术防锁定的利益博弈只要与客户做交流就一定会看到，而这一力量也被 CNCF 发现并运用于推广云原生技术，且成为了云原生技术发展的核心驱动力，使得云原生技术在相当短的时间内得到了来自云厂商和云客户的大力支持。必须指出，AWS 作为云计算的行业领导者很少讲技术锁定这事，那是因为没有必要宣传这一点而让到手的客户从自己手中流失，那并非因为 AWS 没有看到客户对技术锁定的担心，从其积极跟进云原生技术也不难佐证这一点。

 

Google 能否通过云原生的推广而在未来的云计算市场获得更大的份额虽说未知，但那不是我们关心的重点。重点在于，云原生作为行业认可的技术趋势，我们如何迎合和规划未来的技术发展，以及群策群力去打造一个健康、蓬勃发展的云计算产业生态。

 

理解云原生核心驱动力的价值在于，云厂商在为客户提供云原生技术方案时，需要充分地考虑到不要给客户带去技术锁定，但可以考虑通过产品做粘性。锁定是指“用了我你就无法方便地离开我”，而粘性是指“用了我可以给你带去不一样的价值，而你也可以随时方便地离开我”。

 

只理解云原生的核心驱动力还不够，还得掌握它所解决的本质问题是什么。作者归纳为云原生所解决的本质问题是应用（或“服务”，本文这两词可以互换使用）的弹性、易用性和移植性这层层递进的“三性”。

 

应用的弹性是指即便在最严苛的业务场景下，技术仍具备给客户创造业务价值的能力。换句话说，客户使用了某个技术解决方案后，他可以持续有效地运用该产品去创造业务价值。从技术的角度，弹性包含了微服务软件架构、充分解耦、高可用、异地多活、限流、熔断、降级、不可变基础设施等内容，以及支持应用的快速扩缩容能力。

 

第二个解决的本质问题是易用性。如果只解决了应用的弹性而没有解决易用性，那么为了运用技术去支撑业务价值创造所需投入的人力和时间会是企业所面临的下一个沉重负担，最终在技术的运用和价值创造上无法体现敏捷性和经济性。易用性对于云产品的用户和客户来说，代表了良好的开发和运维效率。

 

良好的开发效率意味着使用者（客户侧的开发者）只需关心最少的概念和写最少的代码，这就需要云产品在打造之时很好地围绕使用者的心智和能力水平去设计，通过让技术之间做尽可能的无缝连接、对技术细节做良好的抽象甚至彻底屏蔽去降低使用门槛。良好的运维效率则指，只用很少的几个人就可以运维庞大的集群，整个分布式应用的发布、故障发现和排错都很高效。

 

上图中，作者在易用性这块罗列了 DevOps、GitOps、Cloud IDE 和 CI/CD 等内容。其中的 GitOps 被认为是下一代的 DevOps，让运维工作变得与写代码的方式一样，将 Git 仓库作为运维工作的“the single source of truth”，这对于多云、混合云和多集群部署是非常有价值的。Git 所具备的版本管理能力让运维工作变得更加可溯与可控。总的说来，易用性解决的是软件开发效率、工程质量和人力成本问题。

 

第三个解决的本质问题是应用的移植性。多云（注：指同时使用多个公有云）和混合云（注：指同时使用公有云和专有云）被 Gartner 认为是未来企业 IT 的重要战略。延着该战略，终态得做到一个分布式应用的代码零改动就能方便地部署到不同的云上（当然，配置可以不同）。逻辑上，要实现应用的可移植性，则应用中不应包含任何与云平台相关的代码，那些代码需要完全下沉到云平台中，实现与应用与云平台的完全解耦。要做到那些代码在所有的云平台上都可用，则需要相关的基础技术是被所有云厂商采纳的，这是一项技术是否是“事实标准”的关键。

 

对于客户来说，实现应用移植性的价值在于，除了解决防止被云厂商锁定的问题，还让自由搭配各云厂商上的技术和成本优势成为了可能。对于那些关系到国计民生的国家级或国际化发展的应用来说，也让满足多云部署的政策合规要求变得简单。

 

整个云原生技术所关注的都是通过降本增效，以更好、更快、更经济的方式去帮助客户创造价值，这一点也是分布式应用的终极技术挑战。

 

上图的左侧，作者列出了 CNCF 对于云原生的官方中文定义，其中使用橙色和红色高亮的内容，与作者在这里所表达的核心驱动力和所解决的本质问题是同意但不同样的表达。

 

云原生的技术趋势

 

简单说来，云原生的技术趋势是围绕应用的可移植性问题，以一致性为目的，通过分层去解决。上图的左侧列出了五个层次，右侧则示例了对应的部分开源软件。最上层的 Cloud Portability 与前面讲的应用的移植性是同一回事。

 

图中存在 Service Portability 和 Network Portability 两个不同的层。前者解决的是 OSI 网络层次模型中 4 到 7 层的可移植性问题，比如 Service Mesh 的开源软件 Istio 所解决的就是这个层次的问题；后者解决的是 2 至 3 层的网格连通性问题，开源的 Network Service Mesh 就是专注于这一层。从 Network Portability 的角度，未来的网络连通性不再是用 IP 和网络掩码去描述，而将采用类似 RPC 中的服务注册与发现那样，基于被部署的应用的 YAML 文件中所描述的网络要求去构建。

 

与云原生同行

 

在云原生的技术大潮下，作者从应用开发者和云平台开发者的角度给出一些建议。

 

从应用开发者的角度来说

 

• 首先应尽量以 Kubernetes 为底座去部署应用。Kubernetes 使得应用的部署与运维较上一代的方式轻松且不易出错，相信围绕着 Kubernetes 所构建的云原生生态会有更多的技术红利可以享受到；
• 其次，尽量采用 CNCF Landscape 中的开源软件去构建自己的分布式应用体系。CNCF Landscape 中的项目大多有很好的社区活跃度，也围绕着云原生这个大图在发展，其丰富度和成熟度能避免少走很多弯路和杜绝没有必要的重复建设；
• 最后，让所开发的应用努力做到无状态、轻量化和松耦合。在云原生的时代背景下，光开发一个功能正常的应用是不够的，还得很好地思考应用的可移植性等内容，这是跟上技术发展步伐和更新自身知识体系的必经途径。

 

对于云平台开发者来说

 

• 第一个建议是应全面基于 CNCF Landscape 中的项目去打造云平台。云原生的出现对于云厂商过去自建的基础设施是一次很大的颠覆与打击，不少云原生技术的设计因为格局更高而更优，面对这一情形下应果断地放弃自建的，当开源的满足不要自己的需要时考虑参与开源去共建。当然，如果发现自建的产品可以丰富 CNCF Landscape，则可以考虑贡献给 CNCF，通过做大做强去变成事实标准而增强技术影响力。

 

• 第二个建议是围绕“三性”去找发力点。云原生概念的提出，让不少云平台开发者觉得困惑，因为太抽象而使得每个人的理解不同而无法聚焦讨论，进一步导致不好找发力点。今天的云原生仍围绕着核心驱动力和“三性”在动态发展，随着发展的深入将变得愈加具象。在这种情形下，云平台开发者应当围绕这几个要素去审视自己的技术路径是否是云原生的，避免出现发展偏离。

 

• 第三个建议是“借力开源，反哺开源”。借力开源是为了避免重新发明轮子所带来的劳命伤财。如果开源社区已有一个和自建的相似的产品，作者建议要好好地思考自建的与开源的两者之间的关系是什么。是完全放弃自建的，还是将自建的贡献给开源社区，这可以基于两者的差异化去做决定（当然还得看 CNCF 是否接收）。如果发现开源的功能和性能比自己所需存在差距，应当考虑对开源的进行增强，并将增强的功能反哺回开源社区。通过这样的形式参与到开源社区的建设去让“云原生”变得更加具象。真有技术实力，应当自信于放弃自己的，通过投身开源去打造技术影响力。

 

• 最后一点建议是努力不要让自己的技术对客户产生锁定。对于平台性技术，客户对于技术锁定是非常敏感的，一旦采用锁定的思路去做产品就会让用户放弃选择。当然，如果是非平台性技术，锁定问题就并不存在而无需担心。

 

Kubernetes、Service Mesh 和 Serverless

 

这张图能帮助我们理解 Kubernetes 和 Serverless 的位置关系。Kubernetes 今天仍在发展，包含了 CaaS 和 PaaS 两大块的内容，且有做厚的趋势。平台技术做厚的好处在于，会对下面的基础技术的演进有更强的掌控力，也会因为做厚而使得上面的应用变轻，让应用更加聚焦于业务逻辑本身而无需过于关心解决分布式应用连接、安全、控制和遥测等共性问题。上图还展示了 service 这个概念从 IaaS 贯穿至 PaaS 层，让层与层之间因为 service 这个概念而能流畅地衔接，从软件设计的角度体现优雅与一致性。这张图中并没有看到 Service Mesh 的影子，下图以另一种视角进行了展示。

 

 

图中示例了数据平面和控制平面。Service Mesh 的 Sidecar 形成了连接 PaaS 和 SaaS 两层服务的数据总线，能方便地完成位于这两层服务的互联互通（即服务注册与发现），结合控制平面，实现所有服务的控制（流量灰度、限流、熔断、降级等）、观测（日志、指标和调用链路跟踪），以及服务与服务之间的安全保障。控制平面则贯穿了所有层，是整个分布式生态系统的控制中枢。图中并没有示例出另外两个同样重要的开发平面和运维平面。

 

 

Kubernetes、Service Mesh 和 Serverless 三者共同演绎不同层次的封装和向上屏蔽下面的细节。Kubernetes 引入了不同的设计模式，实现对各种云资源全新、有效和优雅的抽象和管理模式，让集群的管理和应用发布变成了件相当轻松且不易出错的事。

 

被广泛采用的微服务软件架构将分布式应用的各种复杂度迁移到了服务之间，如何通过全局一致、体系化、规范化和无侵入的手段进行治理就变成了微服务软件架构下至关重要的内容。Service Mesh 通过将各服务所共用和与环境相关的内容剥离到部署于每个服务边上的 Sidecar 进程而轻松地做到了。这一剥离动作使得服务与平台能充分解耦而方便各自演进与发展，也使得服务变轻而有助于改善服务启停的及时性。

 

云原生是天然支持多语言的——各技术团队可以使用自己最善长、最高效的编程语言去创造业务价值和做业务探索。Service Mesh 因为将那些服务治理相关的逻辑剥离到了 Sidecar 中且作为独立进程，所以 Sidecar 所实现的功能天然地支持多语言，为上面的服务采用多语言开发创造了更为有利的条件。

 

通过 Service Mesh 对整个网络的服务流量进行技术收口，让异地多活这样涉及流量调度的系统工程实现起来更加优雅、简洁与有效，也能更加方便地实现服务版本升级时的灰度、回滚而改善安全生产质量。由于技术收口，给服务流量的治理和演进、排错、日志采集的经济性等疑难问题创造了新的发展空间。

 

Serverless 对客户的最大价值有两点。

• 其一，将资本支出（CAPEX）变成了运营成本（OPEX），且能很好地解决业务“估不准问题”。Serverless 采用更精确地根据业务量所消耗的资源去支付费用，无需在事先估计业务量而先采购好计算资源。传统的通过预估业务峰值采购计算资源的方式下，如果业务量估高了就会造成采购多余的资源而带来浪费，如果业务量估少了又会使得业务价值无法最大化而让营收变窄。Serverless 从技术层面做到了可以在毫秒级实现计算资源扩容而很好地应对业务流量的波动；

 

• 其二，省去了高昂的运维成本。Serverless 由于是免服务器运维的，所以不需要配置相应的人员去运维服务器。Serverless 的整个解决方案通过封装向开发者屏蔽了大量的技术细节，让开发者可以专注于业务逻辑而带去更高的开发效率和缩短业务上线时间。可以预见，Serverless 是弹性、易用性和移植性的重要落地形式。

 

有部分人对 Service Mesh 和 Serverless 存在这样的困惑：有了 Serverless 之后还需要 Service Mesh 吗？作者看来，两都并非矛盾体。Service Mesh 是解决微服务软件架构下服务与服务之间复杂度问题的，只要采纳了微服务软件架构就应当使用 Service Mesh。Serverless 解决的是免服务器运维的问题，一个运用于微服务软件架构的 Serverless 解决方案，应当包含 Service Mesh 的内容，只不过对于终端的开发者很可能感知不到而已。

 

Distributionless 的内涵及发展趋势

 

云原生是分布式应用当下重要的发展路径，其终态应当是 Distributionless。背后的含义有两点。

 

• 首先，所有与分布式相关的问题由云平台解决。换句话说，基于云平台做二次开发的开发者无需掌握底层复杂的技术与概念就能高效地开发、部署和发布应用。云平台会提供各种工具作为脚手架，帮助开发者去发现问题、诊断、排错和做资源编排等工作；

 

• 其二，分布式应用的开发会跟传统应用的开发一样方便，甚至更加便捷。信息流动的效率与充分度是很多创新的重要因素，互联网天然具有这些优势，这种优势一定会让分布式应用的开发效率持续得到巨大改善。

 

Distrubutionless 的发展趋势是：

 

• 平台变厚、变重、变标准，应用变薄、变轻。分布式应用的复杂度无论用什么技术方案都是存在的，关键在于如何解和在哪儿解。逻辑上，将复杂度下沉到平台才是正道，这就带来了平台变厚和重、应用变薄和轻的结果。沿着云原生的路径，只有平台标准化才能最终实现应用的可移植性。

 

• 数据平面网格化。分布式应用从单体走向微服务软件架构，所隐含的思路是数据平面应当网格化。服务网格作为云原生的关键技术，未来一定存在不同应用对于网格的定制需求，不同应用定制所带来的开销应当由应用所在的机器承担，而不能转嫁给其他应用，唯有网格化才能实现资源使用在应用级别的资源隔离（不同的应用加载实现不同定制逻辑的插件）。类似 RSocket 这样采用集中 Broker 的技术根本无法满足这一要求。数据平面的最大挑战在于如何隔离好业务对数据平面的定制化要求，以及如何做到路径无损。后者是指，在增加 Sidecar 的情形下，通过技术创新实现 RT 和资源占用趋于零。

 

• 控制平面集中化。数据平面与控制平面是孪生兄弟，一个“形散”的数据平面需要有一个“神不散”的控制平面去帮助实现全局治理。控制平面的技术挑战在于如何在最短的时间内，将整个集群的相关控制信息推送到数据平面。

 

• 运维平面产品化。产品化水平的高低代表了未来分布式应用运维便利性和应急响应的及时性。产品化过程中对概念的抽象和人机交互的设计，代表了云平台厂商对分布式应用开发这一专业领域的洞见和最佳实践，也表达了云厂商对使用技术的人性化的认知深度。产品化工作一定不是以图形化的人机交互方式去表达技术细节，而是为用户塑造一套让人容易理解和掌握的心智模式。

 

• 开发平面无缝整合。开发平面由分布式应用的开发者日常工作所应遵守的流程组成，包含代不限于需求与任务分解、概要设计、编码、单元测试、集成测试、代码管理、软件打包和发布等内容。开发平面如何做到以开发者为中心，使他能流畅而高效地开展自己的工作是关键挑战。此外，开发平面的设计需要对高效软件开发的方法论有很好的梳理与表达，且能践行行业的一些共识实践。比如，能方便地实现需求的可溯和软件缺陷的跟踪。

 

对于云平台厂商来说，Distributionless 的关键竞争力来自运维平面的产品化和开发平面无缝整合的能力。这两块是直接触达客户和用户体现技术以更快、更好交付客户价值的关键。相信“体验为王”在未来分布式应用领域同样适用。