云原生与服务网格—简介

Posted 2021-06-16 汤师爷的惊喜

“当我们谈论架构的时候，都在谈论什么？”“微服务！”，现在好像不论是多大规模的研发团队，不是已经在使用微服务了，就是在微服务化的路上。不知道对于两三个人的团队，微服务是给他们好处多点儿还是麻烦更多一点儿。本文暂且不谈论微服务，只简单谈论一下号称“下一代微服务”的服务网格（Service Mesh）和“云原生”。

云原生

“云原生”是什么？它本质上是一种设计模式，要求云原生的应用具备可用性和伸缩性、自动化部署和管理的能力，并且能够利用云平台提供的一些特性。云平台环境是在不断变化的，例如有可能遇到宕机，资源不够的情况，要保证部署在云上的这些应用能够正常的运行，就要求支持高度分布式，有自适应和极强的恢复能力。其中代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API等。

服务网格

微服务也不是“银弹”，在解决问题的同时也带来了不小的复杂度，为了实现微服务，每个服务都需要处理很多与业务无关的通用功能，例如服务发现、负载均衡、限流熔断。本来引入微服务是为了解决问题，能支撑业务的快速发展，结果实现的时候发现还有如此多的非功能性需求，甚至拖慢了研发进度，大不如前。于是市面上出现了类似 Spring Cloud 的框架来避免代码的重复，以类库的形式集成到每个服务。目前这种主流的做法属于一种侵入式的方案，虽然在一定程度上屏蔽了复杂度，但是仍然有很多自己的痛点，比如学习门槛高--每个组件都需要投入时间精力来学习、功能不全、无法跨语言和升级困难。以上每个痛点都削弱了微服务所带来的好处。

在解决以上痛点的过程中，出现过很多方案。

•proxy 方案（如 nginx 代理等）。•sidecar 模式。•第一代 Service Mesh（只有数据面，无控制面）。•第二代 Service Mesh（数据面、控制面）。

截止目前，比较成熟的方案就是第二代 Service Mesh，以 Istio 为代表。

那么服务网格又是什么？可以认为它是一种基础设施，解决微服务间通信相关的问题，屏蔽通信复杂度，解决微服务治理问题，能够让我们向本地调用一样使用微服务。它将微服务过程中引入的服务治理相关的能力从业务实现中解耦，下沉到基础设施层面，同时屏蔽语言多样性带来的问题。这是一种和 Spring Cloud 等主流框架不同，它是无侵入式的，对现有的实现而言是透明了。这样就大大降低了将传统服务改造成云原生应用的门槛。

它通过 sidecar 模式，将调用关系关联起来，形成了一个网络，形成了如下图所示的“服务网格”。

架构上采用数据平面和控制平面分离的思想。数据平面负责代理微服务之间的通信和相关功能，比如 RPC、服务发现、负载均衡、降级熔断、限流容错等。而控制平面则对数据平面进行管理，定义服务发现、路由、流量控制、统计监控等策略。以 Istio 为例子，它以 envoy 作为数据面，全面接管微服务通信的流量，完全屏蔽了网络和通信的复杂性。

采用服务网格后，降低了微服务的复杂性，但也不是没有代价的，因为它要接管所有的流量，因此带来一定的性能损耗。当然在高内核版本中，我们可以采用 cilium、ebpf 等相关技术来对其进行加速，相信未来不是什么问题。

中国的发展

服务网格在中国也有一定的发展，各大公司都开始推出自己的服务网格，有兴趣可以了解一下。

•蚂蚁金服的 Sofa Mesh 控制平台基于 Istio，数据平台自研。•微博的 motan-go。•华为的 Mesher。