目前业界跟微服务相关的开发平台和框架更是不胜枚举：Spring Cloud， Service Fabric，Linkerd，Envoy，Istio ...
这些纷繁的产品和Sevice Mesh有什么样的关联?哪些属于Service Mesh的范畴?
为了理清这些繁复的产品和概念，我们先来了解下微服务和Service Mesh技术的历史发展脉络。
了解清楚了技术的主要脉络，就能清晰的知道上述的各个平台、框架属于技术脉络中的哪个结点，其间的关系也就一目了然。
Phil Calçado的文章《Pattern: Service Mesh》，详细的介绍了从开发者视角来看，服务开发模式和Service Mesh技术的演化过程，个人认为是非常经典的学习Service Mesh的资料。这里借用文章的脉络，结合自己的理解并予以简化，试图说清楚ServiceMesh的概念和这项技术诞生的历史必然性。你可以把本文当做原文的一个中译版本来阅读。
时代0：开发人员想象中，不同服务间通信的方式，抽象表示如下：
时代1：原始通信时代
然而现实远比想象的复杂，在实际情况中，通信需要底层能够传输字节码和电子信号的物理层来完成，在TCP协议出现之前，服务需要自己处理网络通信所面临的丢包、乱序、重试等一系列流控问题，因此服务实现中，除了业务逻辑外，还夹杂着对网络传输问题的处理逻辑。
时代2：TCP时代
为了避免每个服务都需要自己实现一套相似的网络传输处理逻辑，TCP协议出现了，它解决了网络传输中通用的流量控制问题，将技术栈下移，从服务的实现中抽离出来，成为操作系统网络层的一部分。
时代3：第一代微服务
在TCP出现之后，机器之间的网络通信不再是一个难题，以GFS/BigTable/MapReduce为代表的分布式系统得以蓬勃发展。这时，分布式系统特有的通信语义又出现了，如熔断策略、负载均衡、服务发现、认证和授权、quota限制、trace和监控等等，于是服务根据业务需求来实现一部分所需的通信语义。
