服务网格是一个用于处理服务间通信的基础设施层。服务网格保证请求在云原生应用组成的复杂服务拓扑中可靠地传递。在实际应用当中，服务网格通常是由一系列轻量级的网络代理组成，它们与应用程序部署在一起，但对应用程序透明。

微服务 (Microservices) 是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通信。

Service Mesh定义

Service Mesh功能在于处理服务间通信，职责是实现请求的可靠传递。在实践中，Service Mesh通常由服务与轻量级网络代理（Sidecar，与服务部署在一起）组合而成.Sidecar中文翻译为边车，它在原有的客户端和服务端之间加了一个代理，但对应用程序透明。如下图所示为两个微服务之间通过Sidecar互相调用的情形：

当微服务（Service）集群扩大到一定规模后，就会形成网格状（Mesh），即形成了Service Mesh形态：

Service Mesh会接管整个网络，在服务之间转发所有的请求。在这种情况下，业务服务不再负责处理请求的具体逻辑，只负责完成业务处理。服务间通讯的环节就从服务里面剥离出来，呈现出一个抽象的基础设施层。对应的服务间通讯相关的治理功能，如流量路由（根据权重或参数分流、负载均衡、黑白名单）、流量治理（熔断、限流、容错）、请求认证鉴权、调用拓扑等均在下沉的Service Mesh层实现，微服务研发者专注于业务研发本身即可。

容器化与Service Mesh

在基于Envoy+Istio方案中， 容器化是Service Mesh高效落地的基础。容器化+Kubernetes编排不仅为微服务本身带来灵活部署调度、扩缩容、高可用等诸多能力，对Service Mesh架构下Sidecar注入、生命周期管理、流量拦截、安全管理等也提供了十分重要的特性。简而言之，容器化与Service Mesh具备天生的亲和性。

Service Mesh架构本身并未限定业务微服务本身必须容器化,但 从微服务业务长期规划、Service Mesh核心价值最大化、压缩迁移成本等方面考虑，容器化+Service Mesh一定是微服务业务演进的重要方向。

注册中心的选择

在基于Envoy+Istio方案下， Kubernetes基于ETCD的注册中心机制是社区注册中心的默认方案。对于其他注册中心，可以通过Istio的MCP机制接入（Consul、Eureka、ZooKeeper等）。

值得注意的是，Service Mesh架构下服务注册、发现与传统服务框架存在较大差异： 传统服务框架下，微服务的注册通常通过服务框架SDK将微服务注册到注册中心，通过SDK中的发现方法从注册中心发现服务与实例列表，即 通过客户端SDK完成注册发现。

在Service Mesh架构下，控制面组件（如Istio Pilot）负责对接注册中心。服务在创建Kubernetes Service、Deployment时会完成自动注册；服务的发现则是由控制面组件拉取或监听注册中心，将获取到的服务与实例信息转换为统一服务模型，再通过GRPC推送到Sidecar，这样Sidecar就获取到了服务与实例信息，即 通过控制面组件完成服务发现。通过控制面组件完成服务发现模式下，控制面组件可以通过实现不同注册中心的适配器，同时获取多种注册中心的服务与实例信息，即 可实现多注册中心服务的互相发现。示意图如下：

虽然Istio Pilot提供了对接多种注册中心能力， Kubernetes基于ETCD的注册中心机制依然是推荐的容器化+Service Mesh下的注册中心选择。原因不仅是这是Kubernetes的原生机制，能力完整性与健壮性强，在实践过程中，通过MCP机制实现各注册中心的对接并不像想象那样平滑：控制面组件对注册中心进行定时拉取或监听，对于不同注册中心会选择不同的策略：如果对接的注册中心没有提供增量式拉取获取监听的机制，控制面组件每次对注册中心全局的信息获取会是巨大的压力