畅谈云原生（下）：云原生的飞轮理论-InfoQ

接上半场的内容，继续和大家一起聊一聊云原生这个话题，内容来自蚂蚁金服中间件服务与容器团队。

前言和上半场回顾

特别指出：这次分享主要是希望起到抛砖引玉的作用，让大家更多的参与到云原生这个话题的讨论，希望后面有更多更好的分享。我们笨鸟先飞，先来开个头。

在开始下半场的内容前，快速回顾一下上半场的内容。第一个话题是如何理解云原生，然后给出了一个我们团队的理解：应用原生被设计为在云上以最佳方式运行，充分发挥云的优势。

第二个话题是：云原生应用应该是什么样子？在这里给出了我们团队的一个初步想法：云原生应用应该往轻量化方向努力。

第三个话题：云原生的中间件该如何发展？同样尝试给出了一个我们团队目前的想法：中间件应该下沉到基础设施，然后中间价对应用的赋能方式要云原生化。

这是全部内容的目录，前面三个在上半场中，今天我们将继续下半场的三个话题。

云和应用该如何衔接？

下半场的第一个话题：云和应用该如何衔接？

应用和云之间是需要密切配合的。

对于非云原生场景，由于云正提供非常有限的能力，因此应用需要自行实现各种能力，包括通过类库/框架的形式。
务实版本的云原生方案下，云可以提供大部分的能力，因此应用可以大幅减负，和非云原生相比在轻量化方面可以有明显的改观。但是依然存在部分能力云无法提供，因此应用还是需要自行实现部分能力。
比较理想的云原生，是希望云能够提供绝大部分的能力，只是在某些特定环节无法完全剥离和解耦，但是此时应用的轻量化已经达到了非常高的水准。
当然，理论上的最终目标，梦想中的云原生，应该是云提供所有能力，而且所有的环节都可以完全解耦，此时应用的轻量化可以做到极致，完全依赖云提供的能力。
整个演进过程中的哲学就是：将复杂留给云，将简单留给应用。

但是，这里需要先强调一下，云原生的演进过程，不仅仅需要云的努力，也需要应用作配合。否则，即便云已经可以提供各种能力，但是如果应用本身没有进行轻量化改造，未能使用云提供的能力，而是继续保持原有的非云原生的形态，那么效果就会大打折扣。

回顾上半场的第一个话题“如何理解云原生”：应用原生被设计为在云上以最佳方式运行，充分发挥云的优势。这里强调的是，应用需要以原生形态来设计，以充分发挥云的优势。

然后回到我们的话题，假设现在云已经准备妥当，各种能力都可以提供，而应用也按照云原生的理念设计，那当云原生应用部署在云上时，这些应用和云之间应该如何衔接？既可以让应用使用云提供的能力，又不至于侵入应用，破坏应用的云原生特性？简单说，就是要实现应用无感知。

首先涉及到的就是赋能方式：即当云（包括下沉到云中的中间件）可以为应用提供各种能力时，这些能力又如何赋予应用呢？

为了满足应用轻量化的需求，不应在编译打包等阶段引入这些能力，以保持应用的云原生特性。因此，我们的目标是：应该在运行时为应用动态赋能。这样可以让应用在开发设计阶段保持简单和专注业务，在部署运行于云上之时再通过赋予的这些能力来对外提供服务。

这个想法自然是非常理想化的，所以问题就来了：如何实现动态赋能？

流量透明劫持是我们目前比较认可的动态赋能方式之一，在上半场谈到 Service Mesh 模式的工作原理时，讲到当我们讲应用部署在 Service Mesh 中时，我们会在部署时动态的在应用所在的 pod 中插入 Sidecar 容器，然后在运行时，会以对用户透明的方式来改变应用的行为。典型如将应用发出的服务间远程调用的请求，改为转向本地部署的 Sidecar，从而引入 Service Mesh 能提供的各种能力。

这个在运行时透明的改变远程调用请求的行为，我们称之为 “流量透明劫持”。

透明劫持的部署模式如上图所示，右边图片是应用容器与 Sidecar 容器在 k8s/Sigma 中的部署模式，左边图片是单个 pod 的放大。其中绿色方块为应用容器，蓝色方块为 Sidecar 容器，蓝色线条表示服务间通讯。

透明劫持的具体工作流程是这样，我们以 iptables 流量劫持方案为例：

Init 流程(编号为0的两条紫色虚线)：在Pod启动时，通过Init Container特权容器，开启流量劫持并设置流量劫持规则（分为 Inbound 规则和 Outbound 规则）。注意这个流程时部署时进行，因为不是真实请求流量所以用的虚线表示。
Inbound流程(左边编号为1,2,3的黄色实现)：Inbound请求，被 traffic interception 劫持，根据 Inbound规则请求被转发到Sidecar，然后Sidecar再转发给应用。这是用于劫持 Inbound流量，也就是外部访问当前应用的流量，使之在通过Sidecar再由Sidecar转发给应用。
Outbound流程(右边编号为4,5,6的黑色实现)：应用发出的 Outbound 请求会被 traffic interception 劫持，根据 Outbound 规则请求被转发给 Sidecar，然后 Sidecar 处理之后将请求发送给目的地。这是用于劫持 Outbound 流量，也就是当前应用访问外部服务的流量，使之先通过Sidecar，然后由sidecar进行转发。

通过上述三个流程，我们就实现了让应用的 Inbound 请求和 Outbound 请求在运行时改变行为方式，在应用无感知的情况下实现了将流量劫持到 Sidecar 中。然后我们在 Sidecar 中就有机会为当前请求赋予各种能力，典型如服务发现/负载均衡/实施各种路由策略/认证/加密等一系列能力，从而实现了对应用的动态赋能。

当前流量透明劫持的技术实现方案有多种，其优缺点如图所示。

透明劫持的最大优点是对代码无侵入：

业务应用在开始时无需关注各种功能的实现细节和调用方式，也不需要依赖SDK，这些能力会在运行时动态赋予
对于已有的应用，旧有代码可以无需改动就直接运行在service mesh上
从而避免修改代码，和相关的重新打包发布上线等复杂流程
另外透明劫持支持直连(不经过sidecar)/单跳(只经过一个Sidecar)/双跳(经过两个Sidecar)，方便开发调试，容易实现和现有系统的兼容

透明劫持近乎完美的实现了我们要求的目标：在运行时为应用动态赋能，应用无感知。

另外透明劫持还有一个比较隐蔽但是又非常关键的优点：不丢失重要信息。这指的是在透明劫持模式下，请求的原始目标地址和端口信息(original_dest)得以保留，让应用可以工作在特定协议应该绑定的端口上，从而更符合 12 factor 中”Port Binding”的要求，关于这一点的细节，可以见最后的花絮部分。

由于原始目标地址和端口信息(original_dest)得以保留，因此透明劫持容许服务在多个端口上绑定多个不同协议而 Sidecar 只需要一个端口就可以实现流量转发。

流量透明劫持的重要使用场景之一就是实现平滑迁移，即从现有的体系向 service mesh 体系逐渐迁移。

图中时典型的服务注册/服务发现机制：应用向注册中心注册，然后客户端在发起请求时通过服务发现获得目标服务的地址列表，再选择其中的某个地址发出请求。

当我们将其中的一个应用 (如图中的 Servcie B) 迁移到 Service Mesh 中，此时会和 Service B 一起部署 Sidecar 并设置流量劫持的规则。当 Service B 作为服务器端接收客户端请求时的，原有请求 Service B 的流量就会被劫持到 Sidecar。此时 Service A 和 Service B 都对此无感知。

当 Service B 作为客户端对外发起请求时，请求会被流量劫持到 Sidecar，然后 Sidecar 再转发请求。同样，图中的 Service B 和 Service C 对此也是没有感知。

当客户端和服务器端的应用都迁移到 service mesh 之后，此时两端都部署有 Sidecar，请求会按照 service mesh 的标准方式在客户端和服务器端都做两次透明劫持进入 Sidecar。依然，两端的服务对此无感知。

透明劫持对于现有系统的升级非常有帮助，主要体现在为升级带来的弹性。如图所示：

当客户端和服务器端都没有进行升级时，应用是直接连接的
当客户端接入 service mesh 时，客户端会有改造，有Sidecar和透明劫持，因此客户端会有一次流量劫持，再往服务器端发送请求时，由于服务器端没有改造，因此服务器端是继续沿用原有方式直接连接。此时流量只经过一次 sidecar，我们称为“单跳”，客户端单跳。
类似的，如果客户端没有改造，而服务器端有改造，则客户端工作方式不变而服务器端会有一次流量劫持，这也是单跳，服务器端单跳。
当客户端和服务器端都改造完成时，在客户端和服务器端会有两次流量劫持，称为双跳。

由于迁移的全过程都做到了对应用透明，因此在迁移过程中可以非常有弹性的安排应用的升级工作，包括个别应用升级失败时的回退。

前面我们详细介绍流量透明劫持这种动态赋能的方式，下面我们继续介绍另外一种常见的动态赋能方式，DNS。

在上半场我们介绍 Service Mesh 的思路时，我们提到在让应用轻量化的过程中，最终在应用里面还是会有一个轻量级的客户端，里面保留有少数功能和信息。这其中就有“目标服务标识”这一项，用于标识当前请求要发送的目标服务。

而在此时，有一个很常见的方式就是用域名来做标识符，从而让客户端可以发起一次 DNS 解析请求到 DNS 服务器。而我们可以通过各种方式在 DNS 服务器中预设 DNS 信息，比如最中间的方式就是和服务注册中心拉通，通过某种方式将服务注册信息中的服务域名和 IP 地址信息（典型如 k8s 中使用 ClusterIP）导入到 DNS 服务器中。

通过这样一个方式，就可以实现通过操作 DNS 记录来控制 DNS 解析的结果，从而实现特定目的。而将数据拉到到 DNS 服务器的方式可以有多种，域名和 DNS 记录信息的使用方式也可以有很多，配合流量透明劫持，Sidecar 也是可以获知这个请求的 DNS 解析结果…… 这里就有很多的想象空间了。

具体 DNS 赋能的典型例子，在 SOFAMesh 项目中，为了兼容现有的单进程多接口的应用，而且容许客户端代码继续维持原有的用接口名而不是应用名来进行访问，我们就是利用了 DNS。

如图，我们通过打通服务注册环节，在服务注册时获取到当前应用所提供的接口，然后将这些接口和应用的 ClusterIP 添加为 DNS 记录，使得这些接口名称对应的域名都指向 cluster ip。然后在请求过程中，客户端会通过接口名进行 DNS 解析，获取 cluster ip，接着以 cluster ip 为目标地址发出请求，然后被透明流量劫持进 Sidecar，sidecar 从请求的原始目标地址中获取到 cluster ip，就可以得到请求的目标服务，从而可以开始后面的各种流程。

在这一过程中，我们组合使用了服务注册 + DNS 信息同步 + 流量透明劫持 + Sidecar 逻辑处理，比较好的实现了对旧有应用的兼容。

在介绍动态赋能方式之后，我们再来继续看应用和云衔接的另外一个话题：在应用被赋予能力之后，应用该如何控制这些能力？

控制的方式通常有两种：命令式和声明式。

对于对于我们云原生的场景而言，有些微妙：这些能力时动态赋予应用的，应用根本无法直接控制这些能力的具体实现，而且从云原生的理念上可说，应用也不应该知道这些来自云的能力的具体实现方式，因此，在动态赋能的场景下，命令式是不合适。

应用能为此做什么？应用肯定知道自己要达到的控制目标，即应用期待的目标状态。比如，应用可以要求说，当我访问某个服务时：

要用轮询的负载均衡算法
要10%的流量去v2版本，其他的去v1版本
要开启链路加密
要……

虽然这些能力会如何实现应用不清楚也无法直接控制，但是给出这些要求应用还是可以做到的。因此，声明式非常符合动态赋能场景下的控制需求。

使用声明式 API 的好处在于：

简单：应用不需要关心实现细节，这些能力的具体的实现方式/流程/细节都是能力提供方内部完成。而且这些能力隐藏在云下，对应用是透明的，在运行时才动态赋予，应用完全可以简单实用这些能力而无需关注其他。
自描述：声明描述的就是应用期望的目标状态

声明式 API 的哲学：把方便留给别人，把麻烦留给自己。

关于云和应用如何衔接这个话题，目前我们能给出的方案还不多，远谈不上理想，期望能够在未来会找到有更多更好的做法。对此有兴趣的同学，非常欢迎一起探讨这个话题，如果有好的想法和方式，欢迎随时指教。

如何让产品更符合云原生？

下半场的第二个话题：如何让产品更符合云原生？。

注意这里要说的是产品，而不是应用。如何让应用更符合云原生有足够多的文章和理论了，但是如何提供一个产品，让这个产品为云原生应用提供服务和支持，然后要让这个产品本身更符合云原生，能找到的资料就不多了。

我们先总结一下从前面内容中得到的一些规律：其核心在于，不仅提供功能，更强调体验：

在讨论云原生应用应该是一个什么样子时提出，云原生应用就应该是原生形态，轻量化：云应该让应用更舒服
在回顾云计算历史，探讨云的形态变化时，我们给出了中间这个图表：云应该让应用少做事
刚刚探讨的声明式API的哲学，把方便留给别人，把麻烦留给自己：云应该让应用更方便。

那么，当我们在云上开发产品，试图将产品的能力融合进云，让云上应用可以自如的使用这些能力时，应该遵循什么样的方式？

在这里，我们介绍一个云原生的飞轮理论，其创意由我们团队的典韦同学，参考了亚马逊的飞轮理论。

亚马逊的飞轮理论相信大家都很熟悉，在这里亚马逊努力打造了两个飞轮，即闭环循环，通过“选品与便利”和“更低价格”实现了更好的“客户体验”。

详细介绍一下云原生的飞轮理论。首先，在云计算和云原生出现之前，下面的这个大循环其实就已经存在了。这个循环主要关注的是功能性方面的需求，提供商的产品主要通过提供功能来满足客户需求，当然不是说没有功能性之外的其他需求，只是在早期对非功能性的需求远没有今天这么多。

进入互联网时代，尤其是移动互联网时代之后，这个大循环面临新的挑战，一方面在功能性方面要求越来越高：除了简单功能实现之外，还有对性能/安全/稳定性/高可用/可扩展性的诸多要求，而且越来越苛刻。

另一个方面，在功能性之外，更多的需求来自对效率的追求：包括开发、测试、部署、维护、变更的效率，以及对成本的要求。

对效率的追求，推动了云计算的产生和发展，以及云原生理念和架构的产生，我们熟知的容器技术，微服务架构，以及新生的 Service Mesh 架构都由此诞生，不可变基础设施和声明式 API 的理念也在实践中被总结出来，并为后续的云原生架构提供理论指导。

云计算的发展，云原生的推出，为云和云上产品带来了功能性之外的一个重要特征：易用性。体现在有了云的支撑之后，云上应用可以简单开发，开发人员容易上手，由于大部分维护工作由云承担，因此降低了客户的维护工作量（甚至 serverless 提出了无维护的理念）。这些产品使用简单，对客户心智要求低，无需客户具体相关的专业知识。

其核心在于分离关注点：客户和客户应用应该关注与业务实现，而非业务实现的内容应该由云和云上产品提供。

而易用性的飞跃，在满足各种功能性的前提下，不仅仅满足了客户需求，也极大的改善了开发体验。在开发、测试、部署、维护、变更等环节的效率提升，也帮助用户控制了成本。

这样，围绕易用性，新的闭环循环产生：对效率的追求，催生了云和云原生架构，带来了易用性的提升，改善了开发体验，从而进一步提供了效率。这个环形的过程会持续发生，云原生架构就会沿着这个飞轮循环不断的发展演进。在过去几年间，这个飞轮循环已经在运转，云原生架构中的容器/微服务等架构都是在这个循环中不断完善和普及。

这是完整的云原生架构飞轮理论，两个飞轮分别关注功能性和易用性，两者结合来满足客户需求，改善开发体验，最终实现云原生架构的良性循环。

为了更好的理解云原生的飞轮理论，我们以云计算中至关重要的虚拟化技术为例，看看这二十年间以虚拟化技术为基础，云和云原生架构是如何一步一步演进和发展的。

首先，在物理机时代，在虚拟化技术出来之前，提供商只能提供服务器托管/服务器租用以及基于 web 服务器的虚拟主机服务，此时云还不存在。

在 2000 年前后，出于对资源利用率的追求，在虚拟机技术成熟之后，基于虚拟机技术首先诞生了 VPS，然后陆续出现了大家熟悉的 VMWare/Xen/KVM/VirtalBox 等技术和产品，云计算开始出现。

之后围绕易用性，先是 amazon 推出 s3 和 EC2，IaaS 出现；后面 HeroKu 推出了 PaaS。此时云已经走向成熟，而云原生架构也出现了早期形态，比如 HeroKu 提出的 12 factor 应用，DevOps 的流行。后面陆续出现了其他 Xaas 形态：SaaS/FaaS 等。

此时的开发体验和物理机时代相比已经有质的飞跃。

2013 年前后，以 docker 为标志的容器技术开始成熟，催生了容器编排、不可变基础设施等技术和理念。而容器这种轻量化虚拟计划的出现也极大的促进了微服务架构等的演进，2015 年前后，云原生架构被正式提出。而之前基于虚拟机技术的 XaaS 也开始向容器化方向转变。

随着 kubernetes 完成了对容器编排市场的统一，云和云原生架构进入 kubernetes 时代，虽然底层虚拟化技术依然是虚拟机和容器，但是上层的 XaaS 形态已经开始陆陆续续开始向 k8s 转型。此时 k8s 奉行的声明式 API 等理念也成为云原生架构的指导思想之一。

最近安全容器技术发展迅速，预期未来一旦技术成熟，很可能会带来新一轮的变革，未来的云和 XaaS 会可能会转为基于安全容器，也许还会有新的未知的形态出现，值得期待。

从上述演进过程可以看到，随着虚拟化技术的一步一步演进，飞轮的一次一次循环，云开始诞生，XaaS 形态开始出现，各种技术和理念相继诞生并日益完善，云原生架构出现并开始成熟，新的理念和架构出现/实践/改进，整个云原生架构就这样在一次一次的飞轮循环中走向成熟。

以云原生飞轮理论为基础和指导，分享一些我们团队在设计云原生产品的一点点心得：

首先，在关注功能/性能之外，应该更多的关注易用性，关注开发者的体验，要将应用和应用开发者当成bady来呵护，努力让产品的使用者可以更舒适更简单的使用产品
产品应该依托云原生架构，具体说，就是应该基于云，基于容器，基于kubernetes。其核心观点在于，要让产品表现的更符合云原生，产品本身就应该是云原生的。
顺势而为，要顺着飞轮的方向，迎合云原生的理念，迎合社区的发展方向。不要逆势而为，不要试图挑战整个社区。

Kubernetes 是云原生的关键所在，怎么强调都不为过。这里有一个被越来越多人认可的说法：

Kubernetes是云原生时代的Linux

对这句话，我们有两个认识，在这里分享一下：

应该以 kubernetes 为底座进行能力建设：简单说就是如果是 kubernetes 已有的能力则直接使用，如果 k8s 的能力不足，则在 kubernetes 上做改进和争强，充分利用k8s的能力，而不是选择无视。
把kubernetes当kubernetes用：即要符合 kubernetes 的理念和设计，遵循kubernetes的游戏规则

谈到遵循 kubernetes 的游戏规则，我们深入一下，核心在于遵循 kubernetes 的 CRD + Controller 模型：