希腊语言中大概是风帆的意思， 发音 [iːst’iəʊ] ，相当于中文的 伊斯特亿欧。

1. 为何使用服务网格？(Why)

• 服务网格并没有给我们带来新功能，它是用于解决其他工具已经解决过的问题，只不过这次是在云原生的 Kubernetes 环境下的实现。
• MVC 三层 Web 应用程序架构下，服务之间的通讯并不复杂，在应用程序内部自己管理即可，但是在现今的复杂的大型网站情况下，单体应用被分解为众多的微服务，服务之间的依赖和通讯十分复杂，出现了 Twitter 开发的 Finagle、Netflix 开发的 Hystrix 和 Google 的 Stubby 这样的 ”胖客户端“ 库，这些就是早期的服务网格，但是它们都近适用于特定的环境和特定的开发语言，并不能作为平台级的服务网格支持。
• 在云原生架构下，容器的使用给予了异构应用程序的更多可行性， Kubernetes 增强的应用的横向扩容能力，用户可以快速的编排出复杂环境、复杂依赖关系的应用程序，同时开发者又无须过分关心应用程序的监控、扩展性、服务发现和分布式追踪这些繁琐的事情而专注于程序开发，赋予开发者更多的创造性。

2. 简介（What）

服务网格有如下几个特点：

希腊语言中大概是风帆的意思， 发音 [iːst’iəʊ] ，相当于中文的 伊斯特亿欧。

如果用一句话来解释什么是服务网格，可以将它比作是应用程序或者说微服务间的 TCP/IP，负责服务之间的网络调用、限流、熔断和监控。

在服务网格场景下，控制面需要把监听器、路由、集群、端点、证书等配置高效、一致地下发到数据面（每个 sidecar 代理）。本文梳理 Istio 历史上使用过的两类配置分发协议：基于订阅的 MCP 与 Envoy 原生的 xDS。

微服务架构将单体应用拆分为众多独立部署的服务，服务间的依赖与通信变得极其复杂。如何对这些分布式服务进行注册发现、流量调度、故障容错、统一配置和可观测,就是「服务治理（Service Governance）」要解决的核心问题。在 Kubernetes 已成为事实标准的今天，服务治理方案大致沿着「SDK/胖客户端库」到「Service Mesh 服务网格」两条路线演进。

跨集群 Pod 通信（Cross-Cluster Pod-to-Pod Communication）是多集群架构里最常被问到的问题之一。按底层网络是否互通，可以分两种情况讨论。

在 Kubernetes 中，把集群内服务暴露给外部用户访问，最早也最广泛使用的 API 是 Ingress。Ingress 解决了"以域名和路径将外部 HTTP/HTTPS 流量路由到集群内 Service"这一基本问题，但在长期实践中暴露出一些结构性短板：它只覆盖 HTTP/HTTPS，扩展能力几乎完全依赖各 Ingress Controller 自定义的 annotation，无法表达流量权重、请求头匹配、跨命名空间挂载等需求，也难以对应现实中"基础设施、集群运维、应用开发"三种角色的职责划分。

简介

Calico 是一个纯三层的数据中心网络方案（不需要 Overlay），与 OpenStack、Kubernetes、AWS、GCE 等 IaaS 和容器平台都有良好的集成。