下载掌阅APP，畅读海量书库
立即打开
1.1 服务网格简介 |
|
服务网格出现的大环境如下：
· 容器技术的广泛应用 。由于Docker的出现，容器技术得到更广泛的认可和应用，各种服务于容器的工具如雨后春笋般涌现，出现了众多容器部署、容器集群、容器编排等平台，例如Swarm、Mesos、Kubernetes。由于容器具备轻量级、启动速度快、性能损失小、扩容缩容快、开发与生产环境统一等特性，越来越多的公司开始尝试使用容器来部署服务，容器技术的飞速发展也大大加速了微服务的应用。
· 微服务的快速流行 。随着近几年云计算的飞速发展，公有云也越来越成熟，微服务架构模式在大公司的兴起，特别是在Netflix、亚马逊等公司的大规模实践，使得越来越多的公司开始尝试使用微服务架构来重构应用。当微服务的服务数量越来越大时，微服务间的服务通信也越来越重要，我们所看到的一个应用，有可能背后需要协调成百上千个微服务来处理用户的请求。随着服务数和服务实例数的不断增长，服务可能上线下线，服务实例也可能出现上线下线和宕机的情况，服务之间的通信变得异常复杂，每个服务都需要自己处理复杂的服务间通信。
· 目前微服务架构中的痛点 。面对复杂的服务间通信问题，一般的解决方案是为服务开发统一的服务框架，所有服务依赖于服务框架开发，所有服务间通信、服务注册、服务路由等功能都由底层服务框架来实现，这样做固然可以在某种程度上解决服务间通信的问题，但是由于底层服务框架的限制，业务人员可能无法基于实际情况选择合适的技术栈；由于所有服务都依赖于底层的服务框架代码库，当框架代码需要更新时，业务开发人员可能并不能立即更新服务框架，导致服务框架整体升级困难。后来Netflix开源了自己的微服务间通信组件，之后被Spring Cloud集成到了一起，组成了Java语言的通用微服务技术栈，而其他编程语言可能并没有如此强大功能的开源组件，只能继续饱受微服务间通信的各种痛。
基于以上服务间通信出现的问题，有人开始思考：能不能把服务间的复杂通信分层并下沉到基础设施层，让应用无感知呢？答案是肯定的。于是服务网格开始渐渐浮出水面，越来越多的人看到了服务网格的价值，尝试把服务网格应用于微服务实践中。
服务网格（service mesh）这个概念来源于Buoyant公司的CEO Willian Morgan的文章“What's a service mesh？And why do I need one？”。服务网格是一个专注于处理服务间通信的基础设施层，它负责在现代云原生应用组成的复杂服务拓扑中可靠地传递请求。在实践中，服务网格通常是一组随着应用代码部署的轻量级网络代理，而应用不用感知它的存在。
服务网格的特点如下：
·轻量级的网络代理。
·应用无感知。
·应用之间的流量由服务网格接管。
·把服务间调用可能出现的超时、重试、监控、追踪等工作下沉到服务网格层处理。
服务网格的原理大致如图1-1所示，深色部分代表应用，浅灰色部分代表服务网格中轻量级的网络代理，代理之间可以相互通信，而应用之间的通信完全由代理来进行。如果只看代理部分，可以看到一个网状结构，服务网格由此得名。
服务网格一般由数据平面（data plane）和控制平面（control plane）组成，数据平面负责在服务中部署一个称为“边车”（sidecar）的请求代理，控制平面负责请求代理之间的交互，以及用户与请求代理的交互。服务网格的基本架构如图1-2所示。
图1-1 服务网格原理（图片来源
图1-2 服务网格架构（图片来源
微服务架构流行以后，服务的数量在不断增长。在不使用服务网格的情况下，每个服务都需要自己管理复杂的服务间网络通信，开发人员不得不使用各种库和框架来更好地处理服务间的复杂网络通信问题，这导致代码中包含很多与业务逻辑完全不相关的代码，稍有不慎就有可能给业务带来额外的复杂度和bug。
当服务规模逐渐变大，复杂度增加，服务间的通信也变得越来越难理解和管理，这就要求服务治理包含很多功能，例如：服务发现、负载均衡、故障转移、服务度量指标收集和监控等。
在使用服务网格时，我们甚至完全不需要改动现有的服务代码，服务开发完全可以使用不同的语言和技术栈，框架和库再也不是限制我们的绊脚石。服务应用代码中将不再需要那些用于处理服务间复杂网络通信的底层代码，我们可以更好地控制请求的流量，对服务进行更好的路由，使服务间的通信更加安全可靠，让服务更具有弹性，还能让我们更好地观测服务，并可以提前给服务注入故障，以测试应用的健壮性和可用性。而拥有这些功能只需要我们的服务做出微小的改变，甚至不需要改变。以上提到的这些功能，在中小规模的公司中，使用服务网格技术，只需要少量的人力投入就能拥有以前大公司才具备的高级服务治理能力。
在云原生大行其道的今天，容器和Kubernetes增强了应用的伸缩能力，开发者可以基于此快速地创造出依赖关系复杂的应用；而使用服务网格，开发者不用关心应用的服务管理，只需要专注于业务逻辑的开发，这将赋予开发者更多的创造性。
既然服务网格能给我们带来如此多的好处，我们应该如何快速上手使用服务网格呢？从头开发一个服务网格平台不仅费时费力，最后的实现也很可能与开源实现的功能基本一致，不如直接选择开源的服务网格实现，或者基于开源的服务网格实现做二次开发以适应自己公司的业务。在开源的服务网格实现中，现在相对比较成熟、可以应用于生产环境的只有Istio和Linkerd2（Conduit）。因为Istio项目的功能最为完整、稳定，所以综合来看，选择使用Istio更为合理一些。