Service Mesh的由来
Service Mesh，中文曾经被翻译为“服务啮合层”，后面统一翻译为“服务网格”，随着微服务架构的火热与云原生应用的普及，逐步为人所知。可以说，Service Mesh概念的出现是必然的。微服务架构能够帮助解决或避免传统单体架构面临的一些问题，但同时，也会带来一些其他或许是更复杂的问题。这些问题包括：
1. 微服务的实例个数爆发式增长，对持续交付产生极高的需求
2. 服务间调用从内部调用变为跨网络调用，对性能产生影响，且网络是不可靠的
3. 服务通信与联系复杂，调用链路复杂，日志分散，对监控运维要求更高
4. 需要实现动态服务注册、服务发现、服务路由、自动扩容、熔断降级等，需要高度统一的服务治理能力
5. 服务分散，更易受到攻击
这些问题都是实施微服务时不可避免的，处理不好，微服务带来的好处将大打折扣，甚至还不如原来的单体应用。人们在落地微服务架构的过程中，往往只看到了微服务带来的好处，却看不到实施微服务所需要的代价与成本。
“Any Problem in computer science can be solved by another layer of indirection.”没错，解决这些问题的办法就是增加抽象层。以kubernetes为代表的云原生系统的出现以容器技术为基础，可在一定程度上解决持续交付、伸缩等问题。但是关键的服务治理问题并没有得到彻底解决。这个时候，Service Mesh就诞生了。
Service Mesh的发起人William Morgan曾经对Service Mesh有如下定义：
1. 专用基础设施层：独立的运行单元。
2. 包括数据平面与控制平面：数据平面负责交付应用请求，控制平面控制服务如何通信。
3. 轻量级透明代理：实现形式为轻量级网络代理。
4. 处理服务间通信：主要目的是实现复杂网络中服务间通信。
5. 可靠地交付服务请求：提供网络弹性机制，确保可靠交付请求。
6. 与服务部署一起，但服务感知不到，对应用透明。
实际上，Service Mesh作为一个透明网络代理，采用非侵入式的运行方式，与业务逻辑隔离，业务应用并不能感知到。通过这一层透明网络代理，很好的解决了容器系统不能解决的其余问题，云原生应用所缺的最后一块短板就这样被补齐了。
主流Service Mesh产品
现如今，主流的ServiceMesh产品只有两款：Linkerd 与 Istio。还有另外的一些产品，例如Istio的前身Envoy，以及Linkerd的继任者Conduit等，由于功能上的欠缺或者是推出时间不长功能不完善等原因，使用者相对较少，得到的验证也不全面。所以本文主要还是围绕Linkerd与Istio进行讨论，从几个不同的维度对双方展开对比，给Servcie Mesh的选型提供一些思路。
Linkerd
Linkerd是2016年由Buoyant公司推出的，可以说是业界第一款Service Mesh产品。它是基于Scala语言的，底层基于Twitter的Finagle库。它的出现标志着Service Mesh时代的开始。
Istio
Istio是2017年5月由Google、IBM与Lyft联合推出。它是基于C++与Envoy的。由于是Google与IBM的亲儿子，竞争力强大，一经推出就获得Red Hat、F5等其他大厂的响应，社区非常活跃，大有后来居上之势。
部署方式
Linkerd支持per-host模式与sidecar模式，Istio只支持sidecar模式。简单来说，per-host模式就是Service Mesh进程部署在主机上，主机上所有的服务进程共享一个Service Mesh；sidecar模式就是Service Mesh进程是服务专属的，一个服务一个Service Mesh进程，多个Service Mesh进程部署在同一台主机。两种模式都有各自的优点与缺点，应用场景也有所侧重。相对来说，per-host实现比较简单，sidecar相对复杂，如果没有使用K8S等容器编排工具，将比较难管理。这也体现了二者的设计思路不同，Linkerd设计时充分考虑了跨平台的特性，而Istio可以说天生是为云原生应用设计的，所以选择了更激进的方式，只支持sidecar模式。
访问控制
Istio支持基于RBAC的访问控制，Linkerd不支持，必须通过其他代理如HAproxy来实现这个功能。
协议支持
Linkerd支持HTTP/1.x、HTTP/2、gRPC等，其继任者Conduit才支持TCP；Istio支持HTTP/1.x、HTTP/2、gRPC、TCP。
负载均衡
Linkerd支持多种负载均衡算法：如Power of Two Choices（P2C）、LeastLoaded、Peak EWMA、Aperture、Round Robin等；相对来说，Istio能够支持的负载均衡算法要少一点，如Round Robin、Maglev等。
运行平台
Linkerd是平台无关的，而Istio初始的设计目标是K8S，虽然提供了对物理机或者虚拟机的支持，但其他平台的支持还很初级，如果没有自研能力，不建议尝试。
部署与配置
由于需要考虑到跨平台，Linkerd的部署与配置相对来说比较复杂，尤其是其基于dtab委托表的路由转换规则与数据访问流，非常复杂，对于刚接触Linkerd的人来说确实是对心智的一大考验。相对来说，Istio的安装配置比较简单，如果不是有非常高的要求，基本上是开箱即用，但当然前提条件是K8S集群已经安装就绪。而且，可通过Helm的方式实现快速部署，这点对于新接触的人来说非常容易上手。
生产验证
个人认为这是最重要，最需要考虑的一点。稳定性是构建企业级应用的重中之中。任何一个细小的缺陷都有可能给企业带来巨大的损失。虽然Istio已经推出了生产版，并且有越来越多的企业开始使用，但是很多功能还是处于快速开发与迭代过程中，不是特别稳定，经受的生产验证不是特别充分。相对来说，Linkerd推出后经受的生产验证要充分很多。
以上列出个人认为二者差异比较大的几个维度，在选择时可以优先考虑。至于其他方面的对比，例如服务发现、动态路由，熔断，监控运维等，二者在功能上的差别不是特别大，在选型时考虑的优先度可以适度降低。
你需要Service Mesh吗？
答案毫无疑问。如果没有Service Mesh，即使用上了微服务架构与容器编排工具，微服务治理缺失带来的问题很快就会暴露。所以问题不是需不需要，而应该是怎么选择。基于以上分析，现阶段个人建议如果是企业级关键应用还是优先考虑Linkerd。如果是个人或者是小型应用，追求快速响应的项目，又或者是试验性质的项目，可以考虑Istio，但必须得有足够的心理准备踏坑。