详细教程丨如何利用Rancher和Kong实现服务网格？

服务网格（Service mesh）是当前新兴的架构模式，越来越受到人们的青睐。与Kubernetes一起，服务网格可以形成一个强大的平台，它可以解决在微服务集群或服务基础设施上发现的高度分布式环境中出现的技术需求。服务网格是一个专门的基础设施层，用于促进微服务之间的服务到服务通信。

服务网格解决了基于微服务的应用中典型的通信需求，包括加密隧道、健康检查、断路器、负载均衡以及流量许可。如果离开微服务来解决这些需求，会导致开发过程中产生高昂的费用和耗时。

在本文中，我们将对服务网格架构模式解决的最常见的微服务通信需求进行概述。

微服务动态和内在挑战

当你意识到微服务实现了相当多的与最初分配给它们的业务逻辑无关的代码时，问题就出现了。此外，有可能你有多个微服务在非标准化的流程中实现了类似的功能。换句话说，微服务开发团队应该专注于业务逻辑，并将低级通信能力留给特定的层。

继续推进我们的方案，需要考虑微服务的内在动态。在给定的时间内，你可能由于以下几个原因而拥有一个微服务的多个实例：

• 吞吐量（Throughput）：根据传入的请求，你可能拥有更多或更少的微服务实例
• 金丝雀发布
• 蓝绿部署
• A/B测试

简而言之，微服务到微服务的通信有特定的需求和问题需要解决。以下图片展示了这一方案：

该图示描述了几个技术挑战。显然，Microservice 1的主要职责是均衡所有Microservice 2实例之间的负载。因此，Microservice 1必须弄清楚我们在请求时刻有多少个Microservice 2实例。换句话说，Microservice 1必须实现服务发现和负载均衡。

另一方面，Microservice 2必须实现一些服务注册功能以告知Microservice 1何时有全新的实例。

想要拥有一个完全动态的环境，以下这些功能应该是微服务开发的一部分：

• 流量控制：负载均衡的自然演变。我们想指定应该发送到每个Microservice 2实例的请求数量。 在Microservice
  1和2之间加密通信
• 借助断路器和健康检查以解决和克服网络问题

总而言之，主要问题是开发团队花费了大量资源编写十分复杂的代码，而这些代码与微服务预期交付的业务逻辑不直接相关。

有潜力的解决方案

如何将所有微服务都可以调用的外部标准化组件中的所有非功能和操作功能外部化？例如，下图编译了所有功能，这些功能不属于给定的微服务。因此，在确定所有功能之后，我们需要决定在哪里实现它们。

Solution #1 ：将所有功能封装在一个library中

开发者将负责调用library提供的函数来解决微服务通信需求。

这个解决方案有几个缺点：

这是一个紧密耦合的解决方案，意味着微服务高度依赖于library
这个模式对于分布和升级新版本的library来说并不容易
这不符合微服务多语言的原则，因为这会将不同的编程语言应用于不同的上下文。

Solution #2：透明代理（Transparent Proxy）

这个解决方案实现了同样的功能集合。但是，采用了一种非常不同的方法：每个微服务都有一个特定的组件，扮演代理的角色，负责处理它的传入和传出流量。代理解决了我们之前描述的库的缺点，具体如下：

• 代理是透明的，这意味着微服务不会意识到它正在附近运行并实现了与其他微服务进行通信所需的所有功能。
• 由于它是一个透明的代理，开发者不需要改变代码来引用代理。因此，从微服务开发的角度来看，升级代理将是一个并不会对开发流程造成太大影响。
• 代理可以使用微服务使用的不同技术和编程语言进行开发。

服务网格架构模式

虽然透明代理的方法给微服务开发团队和微服务通信需求带来了一些好处，但仍有一些缺失的部分：

• 代理只是执行策略来实现通信需求，例如负载均衡、金丝雀发布等。
• 由什么来负责定义这样的策略，并在所有运行的代理上发布呢？

解决方案架构需要另一个组件，这些组件将被管理员用来定义策略，它将负责向代理传播策略。

以下图片展示了最终架构，也就是服务网格模式：

如你所见，该模式包含了我们所描述的两个主要组件。

• 数据平面：也被称为sidecar，它扮演着透明代理的角色。同样，每个微服务都会有自己的数据平面，拦截所有的入站和出站流量，并应用之前描述的策略。
• 控制平面：由管理员用来定义策略并发布到数据平面。

一些重要的事情需要注意：

• 这是一个 "push-based "的架构。数据平面不做 "调用 "来获取策略——那将会消耗网络。
• 数据平面通常向控制平面或特定的基础设施报告使用指标。

手把手教你使用Rancher、Kong和Kong Mesh

Kong提供了一个企业级的综合服务连接平台，其包括了API gateway、Kubernetes ingress controller以及服务网格实现。该平台允许用户部署多个环境，如本地、混合云、多区域以及多云环境。

让我们借助运行在独立于云架构（cloud-agnostic）的Kubernetes集群上的金丝雀发布来实现服务网格，该集群可能包括GKE集群或任何其他的Kubernetes发行版。服务网格将由Kong Mesh实现，并由Kong for Kubernetes作为Kubernetes Ingress Controller。一般而言，ingress controller负责定义进入你的Kubernetes集群的入口点，暴露部署在其内部的微服务，并对其实行消费策略。

首先，确保你已经安装Rancher以及正在运行一个由Rancher管理的Kubernetes集群。在登录到Rancher之后，选在我们将要使用的Kubernetes集群，在本例中为“kong-rancher”。点击Cluster Explorer。你将会重定向到以下页面：

现在，让我们从服务网格开始：

1、 Kong Mesh Helm Chart

回到Rancher Cluster Manger主页并再次选择你的集群。点击菜单栏的“Tools”选项然后点击Catalogs，以创建一个新的catalog。点击Add Catalog按钮，将Kong Mesh的Helm chart收录其中（https://kong.github.io/kong-mesh-charts/）。

选择Global作为范围，Helm v3作为Helm版本。

现在点击Apps和Launch来查看在Catalog中可用的Kong Mesh。请注意，Kong作为Rancher的合作伙伴默认提供了Kong for Kubernetes的Helm chart：