畅谈云原生（上）

今天和大家一起聊一聊云原生这个话题，内容来自蚂蚁金服中间件服务与容器团队。

由于内容比较多，我们分为上下两个半场。

前言

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

内容主要围绕这几个问题，上半场我们将围绕前三个问题。

如何理解云原生？

第一个话题：如何理解“云原生”？之所以将这个话题放在前面，是因为，这是对云原生概念的最基本的理解，而这会直接影响到后续的所有认知。

每个人对云原生的理解都可能不同，就如莎士比亚所说：一千个人眼中有一千个哈姆雷特。

我们来快速回顾一下云原生这个词汇在近年来定义的变化。

先看Pivotal，云原生的提出者，是如何定义云原生的。

这是2015年，云原生刚刚开始推广时，Matt Stine给出的定义。

两年之后，同样是Matt Stine。

而这是Pivotal最新官方网站的描述。可见Pivotal对云原生的定义一直在变。

再来看看目前云原生背后最大的推手，CNCF，这是2015年CNCF刚成立时对云原生的定义。

2018年CNCF更新了云原生的定义。

这是新定义中描述的代表技术，其中容器和微服务两项在不同时期的不同定义中都有出现，而服务网格这个在2017年才开始被社区接纳的新热点技术被非常醒目的列出来，和微服务并列，而不是我们通常认为的服务网格只是微服务在实施时的一种新的方式。

云原生自身的定义一直在变，这让我们该如何才能准确的理解云原生呢？

这里我们尝试，将Cloud Native这个词汇拆开来理解，先看看什么是Cloud。

快速回顾一下云计算的历史，来帮助我们对云有个更感性的认识。

云计算的出现和虚拟化技术的发展和成熟密切相关，2000年前后x86的虚拟机技术成熟后，云计算逐渐发展起来。

基于虚拟机技术，陆续出现了IaaS/PaaS/FaaS等形态，以及他们的开源版本。

2013年docker出现，容器技术成熟，然后围绕容器编排一场大战，最后在2017年底，kubernetes胜出。2015年CNCF成立，并在近年形成了cloud native生态。

这是云的形态变化，可以看到：供应商提供的功能越来越多，而客户或者说应用需要自己管理的功能越来越少。

当云发生如此之大的变化时，云上的应用要如何适应？

在回顾完云计算的历史之后，我们对Cloud有更深的认识，接着继续看一下：什么是Native？

这是从字典中摘抄下来的对Native词条的解释，注意其中标红的关键字。

Native，总是和关键字 Born 联系在一起。

那Cloud和native和在一起，又该如何理解？

这里我们抛出一个我们自己的理解：云原生代表着原生为云设计。详细的解释是：应用原生被设计为在云上以最佳方式运行，充分发挥云的优势。

这个理解有点空泛，但是考虑到云原生的定义和特征在这些年间不停的变化，以及完全可以预料到的在未来的必然变化，我觉得，对云原生的理解似乎也只能回到云原生的出发点，而不是如何具体实现。

云原生应用应该是什么样子？

那在这么一个云原生理解的背景下，我再来介绍一下我对云原生应用的设想，也就是我觉得云原生应用应该是什么样子。

在云原生之前，底层平台负责向上提供基本运行资源。而应用需要满足业务需求和非业务需求，为了更好的代码复用，通用型好的非业务需求的实现往往会以类库和开发框架的方式提供，另外在SOA/微服务时代部分功能会以后端服务的方式存在，这样在应用中就被简化为对其客户端的调用代码。

然后应用将这些功能，连同自身的业务实现代码，一起打包。

这是传统非云原生应用的一个形象表示：在业务需求的代码实现之后，包裹厚厚的一层非业务需求的实现（当然以类库和框架的形式出现时代码量没这么夸张）。

而云的出现，可以在提供各种资源之外，还提供各种能力，从而帮助应用，使得应用可以专注于业务需求的实现。

在我们设想中，理想的云原生应用应该是这个样子：业务需求的实现占主体，只有少量的非业务需求相关的功能。

非业务需求相关的功能都被移到云，或者说基础设施中去了，以及下沉到基础设施的中间件。

以服务间通讯为例：需要实现上面列举的各种功能。

SDK的思路：通过一个胖客户端，在这个客户端中实现各种功能。

Service Mesh的思路，体现在将SDK客户端的功能剥离出来，放到Sidecar中。

通过这种方式，实现应用的轻量化。此时绝大部分的功能都在剥离，应用中只留下一个轻量级的客户端。这个轻量级客户端中还保留有少数功能和信息，比如目标服务的标识（指出要调用的目标），序列化的实现。

这里特别指出，有一个功能是我们努力尝试但是始终没有找到办法的：业务动态配置的客户端。也就是如何获取和应用业务逻辑实现相关的动态配置信息。如果有哪位同学对此有研究，希望可以指教。

我们的想法，云原生应用应该超轻量化的方向努力，尽量将业务需求之外的功能剥离出来。当然要实现理想中的状态还是比较难的，但是及时是比较务实的形态，也能比非云原生下要轻量很多。

在这里举一个效果比较理想的实际案例，在service mesh中实现密文通讯。

由于客户端和服务器端两个sidecar的存在，因此我们可以通过Sidecar之间的协商与合作分别实现加密和解密，从而实现远程通讯的密文传输，而这个加密和解密的过程对于原有应用是透明的。

云原生下的中间件该如何发展？

云原生涉及到的面非常广，对开发测试运维都会有影响，我们这里将聚焦在中间件，给出我们的一些粗浅的想法，因为我们来自中间件部门。大家也可以将中间件自行替换为自己关心的领域，尝试思考一下这个问题。

前面我们讲到云原生应用的理想形态和轻量化方向，这里隐含了一个前提：不管云原生应用的形态如何变化，云原生应用最终对外提供的功能应该是保持一致的。

而要实现这一点，应用需要依赖于云提供的能力，来替换因应用轻量化而剥离的原有能力，云提供的能力是应用形态演变的基础和前提。

理想状态下，我们期望云能够提供应用需要的所有能力，这样应用就可以以最原生化的形态出现。但是现实是这一点远还没有做到，我们依然需要在云之外额外提供一些功能，比如原有中间件的功能。

在云原生之前，中间件的做法通常是以类库和框架的形式出现，近年来也有服务形式。而在云原生时代，我们的想法是让中间件下沉到基础设施，成为云的一部分。

在这里解释一下，在前面就提到了“下沉”，什么是下沉？

我们的想法是：云原生下的中间件，功能应该继续提供，但是中间件给应用的赋能方式，应该云原生化：

• 在云原生之前，应用需要实现非常多的能力，即使是以通过类库和框架的方式简化，其思路是加强应用能力，方式如左图所示，通过提供更大更厚的衣物来实现御寒御寒能力。
• 云原生则是另外的思路，主张加强和改善应用运行环境（即云）来帮助应用，如右图所示，通过提供温暖的阳光，来让轻量化成为可能。

我们以Service Mesh模式为例来详细讲解，首先我们以白盒的视角来看Service Mesh的工作原理：

1. 以原生模式开发应用：应用只需具备最基本的能力，如客户端简单发一个请求给服务器端
2. 部署时动态插入Sidecar：当我们将开发的云原生应用部署到云上，具体说是部署在k8s的pod中时，我们会自动在pod中再部署一个Sidecar，用于实现为应用赋能
3. 在运行时，我们会改变云原生应用的行为：如前面所说客户端简单发一个请求给服务器端，在这里会被改变为将请求劫持到Sidecar，注意这个改变对应用而言是透明无感知的
4. 在Sidecar中实现各种功能：Sidecar里面就可以实现原有SDK客户端实现的各种功能，如服务发现，负载均衡，路由等等
5. Sidecar在实现这些功能时，可以对接更多的基础设施，也可以对接其他的中间件产品，这种情况下，Service Mesh产品会成为应用和基础设施/中间件之间的桥梁
6. 可以通过控制平面来控制Sidecar的行为，而这些控制可以独立于应用之外

我们再以应用的视角，将云和下沉到云中的Service Mesh产品视为黑盒，来看Service Mesh模式：

1. 以原生模式开发应用
2. 以标准模式部署应用：底下发生了什么不关心
3. 客户端简单发一个请求给服务器端：底下是如何实现的同样不关心，应用只知道请求最终顺利发送完成

Service Mesh产品的存在和具体工作模式，对于运行于其上的云原生应用来说是透明无感知的，但是在运行时这些能力都动态赋能给了应用，从而帮助应用在轻量化的同时依然可以继续提供原有的功能。

Mesh模式不仅仅可以用于服务间通讯，也可以应用于更多的场景：

• Database mesh：用于数据库访问
• Message mesh：用于消息系统

中间件下沉到基础设施的方式，不只是有Mesh模式一种，而且也不是每个中间件都需要改造为Mesh模式，比如前面我们提到有些中间件是可以通过与Mesh集成的方式来间接为应用提供能力，典型如监控，日志，追踪等。

我们也在探索mesh模式之外的更多模式，比如DNS模式，目前还在探索中。

简单归纳一下我们目前总结的云原生赋能（Cloud Empower）的基本工作原理：

• 首先要将功能实现从应用中剥离出来：这是应用轻量化的前提和基础
• 然后在运行时为应用 动态赋能：给应用的赋能方式也要云原生化，要求在运行时动态提供能力，而应用无感知

本次畅谈云原生分享的上半场内容就到这里结果了，欢迎继续观看下半场内容。

如开头所说，这次分享是希望起到一个抛砖引玉的作用，期待后面会有更多同学出来就云原生这个话题进行更多的分享和讨论。也希望能有同学介绍更多云原生的实现模式，更多云原生的发展思路，拭目以待。