《实战 Istio入门与实战》—1.1.2　服务网格的优势

1.1.2　服务网格的优势

       微服务架构流行以后，服务的数量在不断增长。在不使用服务网格的情况下，每个服务都需要自己管理复杂的服务间网络通信，开发人员不得不使用各种库和框架来更好地处理服务间的复杂网络通信问题，这导致代码中包含很多与业务逻辑完全不相关的代码，稍有不慎就有可能给业务带来额外的复杂度和bug。

       当服务规模逐渐变大，复杂度增加，服务间的通信也变得越来越难理解和管理，这就要求服务治理包含很多功能，例如：服务发现、负载均衡、故障转移、服务度量指标收集和监控等。

       在使用服务网格时，我们甚至完全不需要改动现有的服务代码，服务开发完全可以使用不同的语言和技术栈，框架和库再也不是限制我们的绊脚石。服务应用代码中将不再需要那些用于处理服务间复杂网络通信的底层代码，我们可以更好地控制请求的流量，对服务进行更好的路由，使服务间的通信更加安全可靠，让服务更具有弹性，还能让我们更好地观测服务，并可以提前给服务注入故障，以测试应用的健壮性和可用性。而拥有这些功能只需要我们的服务做出微小的改变，甚至不需要改变。以上提到的这些功能，在中小规模的公司中，使用服务网格技术，只需要少量的人力投入就能拥有以前大公司才具备的高级服务治理能力。

       在云原生大行其道的今天，容器和Kubernetes增强了应用的伸缩能力，开发者可以基于此快速地创造出依赖关系复杂的应用；而使用服务网格，开发者不用关心应用的服务管理，只需要专注于业务逻辑的开发，这将赋予开发者更多的创造性。

       既然服务网格能给我们带来如此多的好处，我们应该如何快速上手使用服务网格呢？从头开发一个服务网格平台不仅费时费力，最后的实现也很可能与开源实现的功能基本一致，不如直接选择开源的服务网格实现，或者基于开源的服务网格实现做二次开发以适应自己公司的业务。在开源的服务网格实现中，现在相对比较成熟、可以应用于生产环境的只有Istio和Linkerd2（Conduit）。因为Istio项目的功能最为完整、稳定，所以综合来看，选择使用Istio更为合理一些。