微服务架构演进
Spring Cloud
诞生于2015年，最早为微服务治理定义了一系列标准特性，例如智能路由、熔断机制、服务注册发现等等，并提供了对应的库和组件来实现这些标准特性。到目前为止，这些库和组件仍被广泛使用。
但是，Spring Cloud存在一些缺点：
- 对应用本身有侵入性，应用开发人员需要理解并使用微服务框架进行开发
- 对开发语言、开发框架均有要求，技术选择的灵活性较低（JAVA Spring Boot）
- 每块业务要搭建、运维自己的微服务基础组件，成本较高
Linkerd
2016年年初正式发布了Linkerd项目，完成了对Service Mesh的命名。
Linkerd很好的结合了Kubernetes，在每个Node上部署运行了一个Linkerd实例，用代理的方式将加入Mesh的Pod通信接管过来。
该方式将微服务通信的这部分逻辑从应用程序进程中抽取出来，作为一个单独的进程进行部署，作为服务间的通信代理。这使得业务应用不再需要关注服务发现、负载均衡、熔断等底层细节。
Istio
2017年5月诞生的一个新的Service Mesh开源项目，主要参与公司包括Google、IBM和Lyft，一经发布便获得了很多业界公司的响应。
Istio很快就超越了Linkerd，成为了Service Mesh的代表产品，并于2018年8月初正式发布了1.0版本。
Istio补充了Kubernetes生态圈的重要一环，是微服务版图里一个里程碑式的扩张
Service Mesh
服务网格是一个基础设施层，用于处理服务间通信。云原生应用有着复杂的服务拓扑，服务网格保证请求在这些拓扑中可靠地穿梭。在实际应用当中，服务网格通常是由一系列轻量级的网络代理组成的，它们与应用程序部署在一起，但对应用程序透明。
