云夹生？云原生！

Posted 2021-06-04 歪鼻子

你认识的云原生是

1.Cloud Native（云原生）

云原生，这个概念其实有点年轻，云原生在2015年才提出的，我们理解云原生，本质上是在理解云原生应用，我们从一个最直接的角度解读云原生应用：

云：云端

原生：本来就长在那里

所以连起来就是：本来就长在云端的应用，看到这里你是不是更懵了，你懵了，我就可以笑了，嘿嘿，别急，往下看

传统的应用都是跑在本地服务器上，随着虚拟化技术的发展，拉开了云计算的序幕，一大批云计算厂商基于虚拟机技术，提供了IaaS，PaaS和SaaS等产品生态，极大的提高资源的利用率。企业本着降本增效的目的，逐步将应用迁移到云上的Paas平台上。而这一阶段，被称为云计算的虚拟机时代，而这个时间节点在2013年之前，运行在云端虚拟机上的应用，还不叫云原生应用。

2013年，Docker开源，正式开启了容器技术时代，重新定义了 PaaS 的全新容器化思路。在容器技术的基础上，“云”得到了极大的发展，2014年谷歌开源Kubernetes，旨在解决容器的编排问题（部署、伸缩和管理）。2017年容器编排大战尘埃落定，Kubernetes成为最大赢家，标志着K8S成为分布式资源调度和自动化运维的事实标准。Kubernetes 也逐渐体现出云原生时代底层操作系统的特征，向下封装资源、向上支撑应用。这个阶段，可以称为云计算的容器时代。也正是在这个阶段，云原生的概念被提出，其标志事件就是2015年CNCF（云原生计算基金会）的成立，云原生这个词才被大家熟知。

现在我们知道，云原生是在容器时代提出的概念。那为什么会提出云原生这个概念呢？别急我们来看下云计算发展过程中后端架构的演进。

回想起我刚接触微服务的时候，我被微服务的思想所折服，现在随着接触到的软件技术越多，从架构上看，微服务当中非业务跟业务还是服务当中耦合了，从下面的变化图概览图我们可以很明显地看出区别

CNCF对于Cloud Native的定义如下

本质上云原生是一套软件架构的设计思想，依托该思想而设计的应用：应用本身“生于云，长于云”；应用能够天然集成“云”环境，进而释放“云”的最大价值；

说了那么久概念，那么关于云原生的实现是什么呢？答案就是：Service Mesh ，翻译过来就是服务网格

2.Service Mesh

「Cloud Native 是道，Service Mesh 是术」，这句话，是我通过对于Cloud Native与Service Mesh最为准确的定义了

当非侵入式的 Service Mesh 技术终于从萌芽到走向了成熟，当 Istio/Conduit 横空出世，人们才惊觉：微服务并非只有侵入式一种玩法，更不是 Spring Cloud 的独角戏！

下面是摘自redhat对于Service Mesh的定义以及解读

什么是服务网格？

服务网格（例如开源项目 Istio）用于控制应用的不同部分之间如何共享数据。与用于管理此类通信的其他系统不同，服务网格内置于应用程序中的专用基础架构层。这个可见的基础架构层可以记录应用的不同部分是否能正常交互。因此，随着应用的不断发展，它在优化通信和避免停机方面就显得更加有用。

应用的每个部分——即“服务”，都要与其他服务相互协作，来为用户提供所需的内容。如果在线零售应用的用户想购买什么东西，他们得知道该商品是否有货。因此，负责与公司库存数据库通信的服务需要与产品网页进行通信，而产品网页本身，也需要与用户的在线购物车通信。为了增加业务价值，该零售商之后可能会推出一项新服务：在应用中为用户提供产品推荐。要推荐产品，这项新服务除了要与产品标签数据库进行通信外，还需要与产品页面所需的同一个库存数据库进行通信，因此这涉及到大量可重复使用的移动组件。

现代应用常以这种方式拆分，所有组件构成一个服务网络，每一个都分别执行特定的业务功能。要执行相应的功能，一项服务可能需要向其他几项服务请求数据。但如果有些服务（例如零售商的库存数据库）遇到请求超载会怎样呢？这就要靠服务网格了，它会将请求从一项服务路由到下一项，从而优化所有移动组件的协同工作方式。

微服务不是已经做到这一点了吗？

微服务架构可让开发人员更改应用的服务，而无需全部重新部署。与其他架构的应用开发不同，每个微服务都是由小型团队来构建，他们可以灵活地选择自己的工具和编码语言。总体而言，微服务是独立构建的，它们之间彼此通信，出现故障也只是单独情况，而不会升级为整个应用的中断。

服务间的通信，令微服务成为可能。在没有服务网格层时，逻辑管理的通信可以编码到每个服务中，但随着通信变得越来越复杂，服务网格的价值也就愈发显著。对于以微服务架构构建的云原生应用而言，利用服务网格，可以将大量离散服务整合为一个功能应用。

服务网格是如何运作的？

每向应用中添加一项新服务或为容器中运行的现有服务添加一个新实例，都会让通信环境变得更加复杂，并可能埋入新的故障点。在复杂的微服务架构中，如果没有服务网格，几乎不可能找到哪里出了问题。

这是因为服务网格还会以性能指标的形式，捕获服务间通信的一切信息。随着时间推移，服务网格获取的数据逐渐累积，可用来改善服务间通信的规则，从而生成更有效、更可靠的服务请求。

例如，如果某个服务失败，服务网格可以收集有关在重试成功前所花时间的数据。随着某服务故障持续时间的数据不断积累，开发人员可编写相应的规则，以确定在重试该服务前的最佳等待时间，从而确保系统不会因不必要的重试而负担过重。

在上面redhat对于Service Mesh的定时以及解读当中，我们可以得知Service Mesh当中提到了两个很重要的概念，一个是Sidercar，一个是Istio，下面我就来详细介绍一下这两个；

3.Sidercar

Sidecar:(摩托车的)跨斗，边车

Sidercar其实是一种模式，Sidercar其实就跟上图的摩托车一样，是一个边车，表示的是Sidercar其实并不是摩托车的一部分，大概的意思就是说：适用于父应用程序的任何位置，与父应用完全松耦合。Sidecar支持与主应用程序一起部署的进程或服务。这就像是如图所示的边三轮摩托车那样，将边车安装在一辆摩托车上，就变成了边三轮摩托车。每辆边三轮摩托车都有自己的边车。类似同样的方式，边车服务共享其父应用程序的主机。对于应用程序的每个实例，边车的实例被部署并与其一起托管。

下面是samirbehara对于Sidercar的解释

What is a Sidecar Pattern?

Segregating the functionalities of an application into a separate process can be viewed as a Sidecar pattern. The Sidecar design pattern allows you to add a number of capabilities to your application without the need of additional configuration code for 3rd party components.

As a sidecar is attached to a motorcycle, similarly in software architecture a sidecar is attached to a parent application and extends/enhances its functionalities. A Sidecar is loosely coupled with the main application.

Let me explain this with an example. Consider that you have 6 microservices talking with each other in order to determine the cost of a package.

Each microservice needs to have functionalities like observability, monitoring, logging, configuration, circuit breaker and more. All these functionalities are implemented inside each of these microservices using some industry standard 3rd party libraries.

But think again, is this not redundant? Does it not increase the overall complexity of your application? What happens if your applications are written in different languages – how do you incorporate the 3rd party libraries which are generally specific to a language like .Net, Java, Python etc.

Sidecar 的本质就是为了解耦，将原本我们耦合在代码当中的非业务部分分离出来，Sidecar  模式通常都是与容器一起使用的，所以一般我们都会称之为：Sidecar 容器；

采用Sidecar 模式的优势有如下几点：

• 通过将通用基础结构相关功能抽象到不同的层，降低微服务代码的复杂性。
• 减少微服务架构中的代码重复，因为不需要在每个微服务内编写配置代码。
• 在应用程序代码和基础平台之间提供松散的耦合。
• Sidecar 靠近主应用程序，因此它们之间的通信没有明显的延迟

Sidecar模式工作流程

Sidecar是容器应用模式的一种，也是在Service Mesh中发扬光大的一种模式，服务网格层可以存在于与应用程序一起运行的Sidecar容器中。每个应用程序旁边都附有相同Sidecar的副本。

来自单个服务的所有传入和传出网络流量都流经Sidecar代理。因此，Sidecar能够管理微服务之间的流量，收集遥测数据并实施相关策略。从某种意义上说，该服务不了解整个网络，只知道附加的Sidecar代理。这实际上就是Sidecar模式如何工作的本质——将网络依赖性抽象为 Sidecar。

4.Istio

Istio是最初由IBM，Google和Lyft开发的服务网格的开源实现。它可以透明地分层到分布式应用程序上，并提供服务网格的所有优点，例如流量管理，安全性和可观察性。

它旨在与各种部署配合使用，例如本地部署，云托管，Kubernetes容器以及虚拟机上运行的服务程序。尽管Istio与平台无关，但它经常与Kubernetes平台上部署的微服务一起使用。

从根本上讲，Istio的工作原理是以Sidcar的模式将Envoy的扩展版本作为代理布署到每个微服务中：

该代理网络构成了Istio架构的数据平面。这些代理的配置和管理是从控制平面完成的：

控制平面基本上是服务网格的大脑。它为数据平面中的Envoy代理提供发现，配置和证书管理。

当然，只有在拥有大量相互通信的微服务时，我们才能体现Istio的优势。在这里，sidecar代理在专用的基础架构层中形成一个复杂的服务网格：

总的来说，Istio就是理解数据平面跟控制平面；

• Istio的数据平面主要包括Envoy代理的扩展版本
• 在Istio架构中，控制面核心组件是istiod，Istiod负责将高级路由规则和流量控制行为转换为特定于Envoy的配置，并在运行时将其传播到Sidercar

5.扩展：Envoy 是什么？

Envoy 是为面向大型现代服务架构而设计的 L7 代理和通信总线。该项目源于以下理念：

对于应用来说网络应该是透明的。当网络和应用出现故障时，应该非常容易定位问题发生的根源。

事实上，实现上述的目标非常困难。Envoy 试图通过提供以下高级功能来实现这一目标：

**进程外架构：**Envoy 是一个独立进程，伴随每个应用服务运行。所有的 Envoy 形成一个透明的通信网格，每个应用与 localhost 收发信息，对网络的拓扑结构无感知。在服务间通信的场景下，进程外架构对比传统软件库的方式有两大优势：

Envoy 适用于任何应用编程语言。Envoy 部署可以在 Java、C++、Go、php、Python 等不同语言编写的应用之间形成一个网格。在面向服务架构中，使用多种应用框架和编程语言变得越来越普遍。Envoy 弥合了它们之间的差异。•任何与面向大型服务架构打过交道的人都知道部署和升级软件库非常的痛苦。Envoy 可以透明地在整个基础架构上快速部署和升级。

「L3/L4 filter 架构」：Envoy 的核心是一个 L3/L4 网络代理。可插拔的 filter 链机制允许开发 filter 来执行不同 TCP/UDP 代理任务并将其插入到主服务中。现已有多个支持各种任务的 filter，如原始的 TCP 代理、UDP 代理、HTTP 代理、TLS 客户端证书认证、Redis、MongoDB 和 Postgres 等。

「HTTP L7 filter 架构」：HTTP 是现代应用架构中的关键组件，Envoy 支持 额外的 HTTP L7 filter 层。可以将 HTTP filter 插入执行不同任务的 HTTP 连接管理子系统中，如 缓存、限速、路由/转发、嗅探 Amazon 的 DynamoDB 等。

「顶级 HTTP/2 支持」：当以 HTTP 模式运行时，Envoy 同时支持 HTTP/1.1 和 HTTP/2。Envoy 可以作为 HTTP/1.1 和 HTTP/2 之间的双向透明代理。这意味着任意 HTTP/1.1 和 HTTP/2 客户端和目标服务器的组合都可以桥接在一起。建议配置所有服务之间的 Envoy 使用 HTTP/2 来创建持久连接的网格，以便可以实现请求和响应的多路复用。

「HTTP L7 路由」：当以 HTTP 模式运行时，Envoy 支持一种 路由 子系统，能够根据路径、权限、内容类型、运行时 参数值等对请求进行路由和重定向。这项功能在将 Envoy 用作前端/边缘代理时非常有用，同时在构建服务网格时也会使用此功能。

「gRPC 支持」：gRPC 是一个来自 Google 的 RPC 框架，它使用 HTTP/2 作为底层多路复用传输协议。Envoy 支持 被 gRPC 请求和响应的作为路由和负载均衡底层的所有 HTTP/2 功能。这两个系统是非常互补的。

「服务发现和动态配置」：Envoy 可以选择使用一组分层的 动态配置 API 来实现集中化管理。这些层为 Envoy 提供了以下内容的动态更新：后端集群内的主机、后端集群本身、HTTP 路由、监听套接字和加密材料。对于更简单的部署，可以 通过 DNS 解析（甚至完全 跳过）发现后端主机，使用静态配置文件将替代深层配置。

「健康检查」：推荐使用将服务发现视为最终一致的过程的方式来建立 Envoy 网格。Envoy 包含了一个 健康检查，可以选择对上游服务集群执行主动健康检查。然后， Envoy 联合使用服务发现和健康检查信息来确定健康的负载均衡目标。Envoy 还通过 异常检查 子系统支持被动健康检查。

「高级负载均衡」：负载均衡是分布式系统中不同组件之间的一个复杂问题。由于 Envoy 是一个独立代理而不是软件库，因此可以独立实现高级负载均衡以供任何应用程序访问。目前，Envoy 支持 自动重试、熔断、通过外部速率限制服务的 全局限速、请求映射 和 异常检测。未来还计划支持请求竞争。

「前端/边缘代理支持」：在边缘使用相同的软件大有好处（可观察性、管理、相同的服务发现和负载均衡算法等）。Envoy 包含足够多的功能，可作为大多数现代 Web 应用程序的边缘代理。包括 TLS 终止、HTTP/1.1 和 HTTP/2 支持，以及 HTTP L7 路由。

「最佳的可观察性」：如上所述，Envoy 的主要目标是让网络透明化。然而，在网络层面和应用层面都有可能出现问题。Envoy 包含对所有子系统的强大 统计 支持。目前支持 statsd（和兼容程序）作为统计信息接收器，但是插入不同的接收器并不困难。统计信息也可以通过 管理 端口查看。通过第三方提供商，Envoy 还支持分布式 追踪。

6.扩展：四层负载均衡(Layer 4 Proxy)和七层负载均衡(Layer 7 Proxy)的区别

「四层负载均衡( L4 load balancing ):」

主要工作于处于OSI模型中间位置的传输层( transport layer )，它主要处理消息的传递，而不管消息的内容。在互联网上，TCP就是HTTP传输方式的四层协议( Layer 4 Protocol )。「四层负载均衡只针对由上游服务发送和接收的网络包，而并不检查包内的具体内容是什么」。四层负载均衡可以通过检查TCP流中的前几个包，从而决定是否限制路由。

「七层负载均衡( L7 load balancing ):」

主要工作于处于OSI模型顶层位置的应用层( application layer )，它主要处理每条消息中的真正内容。在互联网上，HTTP是网络通讯中占据主导地位的七层协议( Layer 7 Protocol )。七层负载均衡在路由网络传输时比四层负载均衡更加复杂和巧妙，特别适合像HTTP这种基于TCP传输的方式。「一个七层负载均衡器终止网络传输并读取消息中的内容。它可以基于消息中内容( 比如URL或者cookie中的信息 )来做出负载均衡的决定」。之后，七层负载均衡器建立一个新的TCP连接来选择上游服务( 或者再利用一个已经存在的TCP连接，通过 HTTP keepalives 的方式，向这个服务发出请求。