Service Mesh · Istio · 以实践入门

Photo @ Jez Timms

文  |  三辰

前言

---

本文是笔者在学习官方文档、相关博客文章和实践过程中，整理了一些知识概念和自己的思考，主要在探索 lstio 的实际应用场景， Sidecar 原理， Service Mesh 为什么出现、要解决什么问题等，帮助我们思考微服务技术架构的升级和落地的可行性。

本文不是 Istio 的全部，但是希望入门仅此一篇就够。

概念

---

围绕云原生(CN)的概念，给人一种知识大爆炸的感觉，但假如你深入了解每一个概念的细节，你会发现它和你很近，甚至就是你手里每天做的事情。

图片来源：https://landscape.cncf.io/

关键词：Service Mesh、Istio、Sidecar、Envoy 等。

服务网格

服务网格( Service Mesh )是一个新瓶装旧酒的概念，它的发展随着微服务兴起，必然是早于 Kubernates 出现了。但 Kubernates 和 Istio 的出现，促使它成为了一种更火更标准化的概念。

Sidecar 是服务网格技术中常用的(其中)一种设计架构，在 Kubernates 中，不同的容器允许被运行在同一个 Pod 中（即多个进程运行在同一个 cgroup 下），这在很大程度上给 Sidecar 模式提供了良好的土壤。

首先看看 Sidecar 的设计：

图片来源于网络

为什么是新瓶旧酒？任何技术的发展都不是凭空地跳跃式发展的。

历史

原始的应用程序--图片来源于网络

独立的网络层--图片来源于网络

出现网络层（4层协议）控制的需求--图片来源于网络

控制逻辑下移到网络层--图片来源于网络

早期，应用程序随着功能迭代发展，尤其是一个大型项目，程序堆积了越来越多的功能，功能之间紧密耦合在一起，变得越来越难以维护（因为模块耦合度较高，没有人敢动古老的模块代码），迭代周期变长（工程复杂度成几何增长）。

于是，人们提出，将不同的功能分离到不同的程序（进程）中，减低模块的耦合度，敏捷开发迭代，这就是微服务概念的兴起。

出现新的应用层（7层协议）需求（服务发现、熔断、超时重试等）--图片来源于网络

封装成三方库（服务发现：Dubbo/HSF）--图片来源于网络

困难：

服务被拆分成众多的微服务，最困难的问题就是——调用它自己：

1、原本在进程中互相调用那么简单的事情，都要变成一次在 7 层网络上的远程调用。

2、原本公共工具类做的事情，现在需要写成二方库 SDK 等，在每一个进程中使用，版本迭代成为了灾难。

3、原本是内部透明调用的不需要做任何防护，分离后却要额外增加安全防护和隔离的工作。

4、不再是代码即文档，需要维护大量的 API 定义和版本管理。

封装到隔离的进程中代理--图片来源于网络

到这里，独立进程的方式基本成型，即为Sidecar模式。

Sidecar 解决什么问题？

这里有个服务网格里的概念：微服务之间的调用，一般在架构图中是横向的，被称为东西流量。服务暴露到外部被公网可见的外部调用，被称为南北流量。

Sidecar 的设计就是为了解决微服务互相调用（东西流量）的问题。

先来一张我们比较熟悉的图：

图片来源于网络

Consumer 与 Provider 就是微服务互相调用的一种解决方案。

毫无疑问，我们熟知的一整套中间件解决方案，解决的正是东西流量的问题，图为Dubbo 架构。

只不过， Dubbo 中间件一整套组件是基于 SPI 机制以一种较为隔离的方式侵入到运行时的代码中。并且，这只能限定 Java 这样被官方支持的语言来开发服务应用。

小结

归纳一下与东西流量有关的问题：

流量管理（服务发现、负载均衡、路由、限流、熔断、容错等）、可观测性（监控、日志聚合、计量、跟踪）、安全（认证、授权），再甚至更高级的动态配置、故障注入、镜像流量等

相比来说， Sidecar 的模式更为巧妙并更进一步。通过容器机制，在进程上是隔离的，基于 L7 代理进行通讯，允许微服务是由任何语言进行开发的。

图片来源于网络

以下是微服务集群基于Sidecar互相通讯的简化场景：

图片来源于网络

所以说，回到服务网格的概念上来，虽然概念是不同的，但是逻辑上我们可以理解成：所有使用中间件的服务组成了一个大的服务网格，这样可以帮助我们理解。服务网格基于 Kubernates 这样的容器技术，将东西流量的问题解决得更加透明无感。

一句话总结，服务网格（ Service Mesh ）是解决微服务之间的网络问题和可观测性问题的(事实)标准，并且正在走向标准化。

Service Mesh 是 Kubernetes 支撑微服务能力拼图的最后一块

Istio 和 Envoy

Istio，第一个字母是(ai)。

Istio 实现的服务网格分为数据平面和控制平面。核心能力包括4大块：

1、流量控制（Traffic Management）。

2、安全（Security）。

3、动态规则（Policy）。

4、可观测能力（Observability）。

Envoy 面向数据平面，也就是服务之间调用的代理。

Envoy 是 Istio Service Mesh 中默认的 Sidecar 方案。

Istio 在 Enovy 的基础上按照 Envoy 的 xDS 协议扩展了其控制平面。

Istio基于Envoy实现Service Mesh数据平面--图片来源于网络

Envoy角色--图片来源于网络

Envoy 是一个由 C++ 实现的高性能代理，与其等价的，还有 Nginx、Traefik ，这就不难理解了。

也就是下图中的 Proxy ：

图片来源于Istio官网

Istio 在控制平面上主要解决流量管理、安全、可观测性三个方面的问题，也就是前面提到的东西流量相关的问题。类似一个有配置中心的微服务集群架构。具体细节不在这里赘述。

Sidecar注入

前面在介绍服务网格时，只是简单地提到Sidecar设计在其中的作用和特性，这里详细展开介绍其中的原理。

首先是一些预备概念：

1、Sidecar 模式：容器应用模式之一，Service Mesh 架构的一种实现方式

2、Init 容器：Pod 中的一种专用的容器，在应用程序容器启动之前运行，用来包含一些应用镜像中不存在的实用工具或安装脚本。

3、iptables：流量劫持是通过 iptables 转发实现的。

Sidecar 模式解决微服务之间的网络通讯（远程调用），通常通讯层的实现方式，有以下选择：

1、在微服务应用程序中导入 SDK 类库。

2、节点代理（使用纵向的API网关或者是本地 Agent ），代理接口的调用路由规则，转发到特定的机器。