1.1.1. 一、Service Mesh：网格服务：

https://blog.csdn.net/ityouknow/article/details/83629479

1、服务注册发现和负载均衡是微服务架构在技术上的根本问题，解决的办法是采用代理 Proxy。根据代理在架构上的位置不同，服务发现代理一般有三种模式：

• 模式一：集中式代理

• 模式二：客户端嵌入式代理

• 模式三：主机独立进程代理

这三种模式没有绝对的好坏之分，只是三种不同的架构风格，各有优劣和适用场景，在不同企业都有成功落地案例。

2、ServiceMesh 本质上就是模式三中主机独立进程代理，它结合了模式一和模式二的优势，但是分布式部署运维管理开销大。Istio 对 ServiceMesh 的架构、功能和 API 进行了标准化。

3、ServiceMesh 还在演进中，生产落地仍有挑战，一般企业不建议生产级使用。集中式代理最成熟，对于一般中小企业，建议从集中式代理开始，等达到一定规模和具备一定的研发运维能力，再根据需要考虑其它服务发现模式。

4、架构师不要盲目追新，在理解微服务架构原理的基础上，可以学习和试点新技术，但是对于生产级应用，应该以成熟稳定，有大规模落地案例作为选型第一准则。

1.1.2. 二、Service Mesh(网格服务)有哪些产品：

https://baijiahao.baidu.com/s?id=1628332193623751070&wfr=spider&for=pc

1、Istio：

Istio是由Google、IBM和Lyft发起的开源的服务网格项目。该项目在2017年推出，并在2018年7月发布了1.0版本。

Istio基于Envoy代理并以Envoy为数据层（data plane）。可以说Istio是如今最炙手可热的服务网格，但由于仅应用于Kubernetes，其应用价值受到某种限制。

2、Linkerd：

Linkerd（音似chickadee），最初是由Buoyant团队于2016年打造的一个服务网格项目。Linkerd是CNCF的官方项目，基于Twitter的Finagle项目并和后者一样，最初是由Scala语言编写，设计理念是支持基于主机（物理主机或者虚拟节点）的部署模式。由于最初版本的内存占用广受诟病，导致了Conduit项目的开发，Conduit是一个轻量级的服务网格，为Kubernetes定制，用Rust和Go语言编写。Conduit项目目前已经合并到Linkerd项目，并在2018年7月发布为Linkerd 2.0 版本。鉴于Linkerd 2.x 基于Kubernetes，而Linkerd 1.x 可以基于节点的模式部署，当面临复杂环境的场景时，人们可以有更灵活的选择。除非特指，本文的比较都是基于Linkerd 2.x。

1.1.3. 三、架构：

Istio和Linkerd都支持以主流的外挂（Sidecar）模式部署。在这种模式下，每个微服务都被分配一个单独的代理。微服务间的通信并不直接进行，而是通过自身的代理转发。代理会将请求路由到目标微服务的代理，该代理再将请求转发到目标微服务。所有这些服务代理构成了数据层。在服务网格的架构下，数据层由控制层（control plane）来进行配置和监控，控制层一般另行独立部署。