ServiceMesh-Istio：1. 认识ServiceMesh

初识

前几年微服务概念火了????，微服务火了之后，ServiceMesh随之崛起。2018年是ServiceMesh评估乃至炒作的一年。虽然ServiceMesh作为一种新型的技术引发人们广泛的关注。但是对其重视程度主要停留在评估阶段。尚未真正触及，广泛采用。但是具备实际功能的ServiceMesh在普及之后，将有望帮助运维人员更轻松的管理基于的微服务程序架构。ServiceMesh将有望在不久的将来从炒作阶段，过渡至真正的应用层面。在这个阶段来临之前先发制人，系统了解一下它。

什么是ServiceMesh

什么是ServiceMesh———服务网格，听起来比较高大上，但是它不是一个具体的东西具体的产品。而且一个概念，理论层面的东西。

这个概念是随着微服务而来，前几年微服务火了同时也带来很多新问题。像服务发现、负载均衡、路由、流量控制、服务间通信的可靠性、监控等等需要解决的问题，然后出现了API网关（API Gateway）可以把服务集中管理起来，解决上述的问题，但是它有一个单点的问题：容易成为系统的瓶颈，并且实践起来越来越臃肿，不容易维护。然后一点点出现了ServiceMesh的概念。

上面说的问题都是一个问题：网络问题。所有能不能把网络从功能代码里面单独抽离出来，让他自己实现：服务发现、负载均衡、流量控制去实现熔断，确保通信的安全。让应用开发者不在关注这些底层与应用无关东西，甚至完全感知不到这一层的存在，我们就把这个东西叫做ServiceMesh。然而他只是空中楼阁，需要有人去实现它。目前有两个非常知名的ServiceMesh实现：Linkerd、Istio。

Linkerd

始于2016年的CNCF的官方项目，最初使用Scala语言编写，1.x的版本的时候是基于物理机、虚拟机的部署，由于最初版本的内存占用问题，广受诟病，导致了Conduit项目的开发，Conduit是一个轻量级的服务网格，为Kubernetes定制，用Rust和Go语言编写。Conduit项目目前已经合并到Linkerd项目，并在2018年7月发布为Linkerd 2．0 版本。鉴于Linkerd 2．x 基于Kubernetes，而Linkerd 1．x 可以基于节点的模式部署，当面临复杂环境的场景时，人们可以有更灵活的选择。

Istio

Istio是由三大巨头Google、IBM和Lyft发起的开源的服务网格项目。该项目在2017年推出，并在2018年7月发布了1．0版本。可以说Istio是如今最炙手可热的服务网格，同时他还支持多种平台的部署，目前支持在kuernetes上部署的服务，使用Cousul注册的服务，也支持在虚拟机上部署的服务。

Linkerd&&Istio 对比

都是基于sidecar(边车)模式，在这种模式下每个服务都会分配一个单独的代理(使用Envoy)，服务之间的通信是通过自身的代理进行转发，代理会将请求的数据路由到目标服务的代理，改代理再将请求目标的微服务。所有这些代理构成的数据层，有了数据层就需要一个管理它的那就是控制层。控制层需要单位部署。

Linkerd&&Istio 网上对比，总体来说不管是稳定性，功能丰富程度，还是社区知识都是Istio更胜一筹。

gitHub https://github.com/istio/istio 的Star已经达到21.6K，非常火，所有我们选择Istio来使用。