云原生时代——撬动地心引力的技术变革

Posted 2021-05-15 你说了想了你做了吗

什么是云原生？我想没接触过的小伙伴，脑海里的第一个问号来了。 首先我搬一下云原生计算基金会（CNCF）的定义：

云原生技术有利于各组织，在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。

不愧是足够官方的定义，如果不是我的标题写的足够大，估计你都不想往下看了，那我们就字面意思来理解一下，将云（Cloud）和原生（Native）拆分：

那什么是云(Cloud)呢？云也就是云计算，“云”实质上就是一个网络，狭义上讲，云计算就是一种提供资源的网络，使用者可以随时获取“云”上的资源，按需求量使用，并且可以看成是无限扩展的，只要按使用量付费就可以。从广义上说，云计算是与信息技术、软件、互联网相关的一种服务，这种计算资源共享池叫做“云”。

而云计算的由来，是根据虚拟化技术的发展和成熟度密切相关的。基于虚拟机技术，陆续出现了IaaS/PaaS/FaaS等形态，机器由物理机到虚拟机再到容器，部署方式又分为了公有云、私有云、混合云部署。

随着docker容器化技术愈发成熟后，完美解决了在分布式集群中，随着业务爆发或减少，对集群进行稳定运行的弹性扩缩容。而为了实现更好的容器编排，业内还掀起了一场技术战争，最终Kubernetes(K8S)拔得头筹，成为了云原生的标准，后续会持续推出这方面的文章，现在只需要知道K8S是承载了云原生的航空母舰，像虚拟机中的Linux操作系统一样重要就行了。

原生（Native）就很好理解了，“与生俱来，生而知之”，就是事物产生时原来是怎样的，就应该干什么事情。

那云（Cloud）和原生（Native）结合在一起，是怎样理解的？抛出一个定义：云原生代表着原生为云设计。详细的解释是：应用原生被设计为在云上，以最佳方式运行，充分发挥云的优势。

这里既然提出了应用概念，那应用在云上应该是个什么样子呢？或者说应该以什么样的最佳方式去运行？

在思考这个问题前，先看一下云原生之前，应用是以什么样的方式运行的：

在云原生之前，底层平台负责向上提供基本运行资源。而应用需要满足业务需求和非业务需求，为了更好的代码复用，通用型好的非业务需求的实现，往往会以类库和开发框架的方式提供。

这里非业务需求指的是：比如服务间通信，需要做的服务注册和发现；业务之间为了减轻耦合度，使用的消息中间件；为做到服务的可观测性，引入的调用链路追踪、日志监控等等。

另外在SOA/微服务时代，部分非业务需求的功能，也会以后端服务的方式存在，在应用中，这些就简化为对其客户端调用的代码。然后应用将这些非业务功能，连同自身的业务实现代码，一起打包，形成了一个不断壮大的应用。

        

咱们回到云原生的设计中，云的支持应该让应用更多关注于业务。

这里非业务需求相关的功能都被移到云，也就是云的基础设施中去了，包括为业务需求赋能的中间件，也被下沉到基础设施中。还是以服务间的通讯为例，中间件需要做的事情，有以下这些：

看起来有这么多，与应用贴合非常紧密，实现以上的这些功能，有没有更优的衔接方式呢，如用SDK的方式引入，看起来可能会更简洁：

SDK的思路，其实是想用一个健壮的客户端，做掉所有服务间通信所需的中间件功能，但说到底，对应用还是有侵入性的。

而在云原生中，采用服务网格Service Mesh模式的思路，将SDK的客户端剥离出来，放入SideCar中，让应用更轻量化。

这样看来，让应用只专注于业务需求，云中的基础设施（包含中间件）向上提供所需的资源和能力，确实比较贴合云原生这样的设计思路，而云原生应用应该往这个方向去努力。

当理清这些概念之后，可以推断，云原生对整个行业的影响是一次变革，因为云原生涉及的面很广，对开发、测试、运维都会有影响，有可能会出现业务开发和基础设施开发、业务测试和基础设施测试等等。

或许到现在你还不太清楚，为什么会出现这样的一种技术模式，云原生为什么会出现呢？用几个为了说明一下由来：

1.为了解决单体应用的复杂度问题，出现了微服务架构；

2.为了解决微服务架构下，大量应用部署的问题，出现了容器技术；

3.为了解决容器的管理和调度问题，诞生了Kubernetes(K8S)；

4.为了解决微服务框架对应用的侵入性问题，引入了Service Mesh服务网格技术；

5.为了让 Service Mesh 有更好的底层支撑，将Service Mesh运用在K8S上运行

说到这里，没接触过的人，也许有点懵...

什么是Service Mesh模式? 服务间的通信，用SideCar模式工作原理是什么？为什么说应用就只做业务了，那中间件是怎么动态赋能的？搞这么多花里胡哨的....

先回到刚才说在云原生之前，以服务间通信举例，用SDK包装中间件进行服务之间通信调用，模式如下：

而采用Service Mesh模式之后，将服务注册发现、负载均衡、路由、熔断限流等等这些复杂的操作，全部交给SideCar来实现，并和基础设施或其他中间件产品对接，而应用里留下的只是一个轻量级的SideCar-SDK（为表明含义这样举例）。

（SideCar翻译成中文，就是摩托车的边车，就是战争片里日本小三轮儿，左边骑摩托的士兵，右边独座挥刀指挥的大佐，是不是很形象）。

   

了解了是个啥东西之后，来仔细拆分一下Service Mesh的工作原理：

1. 以云原生模式开发业务应用：应用只需具备最基本的能力，如生产一个服务，调用一个服务

2. 部署时动态插入Sidecar：当我们将开发的云原生应用部署到云上，具体说是部署在k8s的pod中时，我们会自动在pod中再部署一个Sidecar，用于实现为应用赋能

3. 在运行时，改变云原生应用的行为：如前面所说服务提供方生产一个服务给调用方服务调用，在这里会被改变为将这次调用请求劫持到Sidecar，注意这个改变对应用而言是透明无感知的

4. 在Sidecar中实现各种功能：Sidecar里面就可以实现原有SDK客户端实现的各种功能，如服务发现，负载均衡，路由等等

5. Sidecar在实现这些功能时，可以对接更多的基础设施，也可以对接其他的中间件产品，这种情况下，Service Mesh产品会成为应用和基础设施/中间件之间的桥梁

6. 可以通过控制平面来控制Sidecar的行为，而这些控制可以独立于应用之外

思考一下，在了解了ServiceMesh的工作原理之后，是不是对动态赋能这个名词感觉熟悉了一些？

在对Service Mesh工作原理进行拆分时，第2步，是在部署时动态的在应用所在的 pod 中插入 Sidecar 容器，第3步提到，SideCar在应用透明无感知的情况下，对应用原本请求注册中心的流量进行了劫持，并改为转向本地部署的 Sidecar，彻底改变了这次调用行为。

而这种在运行中动态插入SideCar,并对流量进行透明劫持的行为，其实就是在动态赋能。

想知道这次动态赋能的更详细流程是怎样走的吗？其实就是在Pod启动时，设定并开启流量劫持的规则，然后在SideCar中按规则进行处理和转发，控制面板会连接其他的SideCar,根据出入规则识别这次服务调用，最后转给目标应用。

这里会涉及到K8S容器相关的知识点和机制，就先不做详述，放一张图作为思考，留到后面的章节再做详细剖析,图为Istio的Iptables透明劫持流程。

透明劫持的最大优点是对代码无侵入，其他优点如下：

1.业务应用在开始时无需关注各种功能的实现细节和调用方式，也不需要依赖SDK，这些能力会在运行时动态赋予。

2.对于已有的应用，旧有代码可以无需改动就直接运行在service mesh上，从而避免修改代码，和相关的重新打包发布上线等复杂流程。

3.透明劫持支持直连(不经过sidecar)/单跳(只经过一个Sidecar)/双跳(经过两个Sidecar)，方便开发调试，容易实现和现有系统的兼容。

其实Service Mesh的定义就是服务网格，可是一开始提服务网格，我自己都懵，自从知道它的工作原理之后，我们再由点到面的想一遍，就很好理解了。

先看一下，多个应用服务，多个Pod的透明劫持，在K8S上部署之后的样子：

是不是像一张网， 左边图片是单个 pod 的放大。其中绿色方块为应用容器，蓝色方块为Sidecar容器，蓝色线条表示服务间通讯。

云原生的介绍，到这里就完了，主要还是介绍了云原生的样子，它以Service Mesh模式运行的工作原理，当然还有很多的优点没有做仔细的诠释，我想了解到这里，脑海里已经有一个基本的轮廓了。

云原生有一个庞大的知识体系，需要长时间的积累和运用才能熟悉，后续还有Kubernetes的探索，Service Mesh的具体落地模式，怎么配合现状进行平滑迁移，都是留给我们的题目，路途还很长，现在还只是个开始。

写到这里，已经是深夜了，排版和整体文章的逻辑考量确实很花时间，但是感觉还不错，没觉得枯燥和乏味，看到自己起的标题有点想笑，但不打算改了......