https://www.cnblogs.com/myshowtime/p/15262334.html
在第一代微服务架构中，应用除了需要实现业务逻辑之外，还需要自行解决上下游寻址、通信及容错等问题。随着微服务规模的逐渐扩大，服务寻址逻辑的处理正在变得越来越复杂，哪怕是通同一种编程语言的另一个应用，上述微服务的基础能力也需要重新实现一遍。
在第二代微服务架构中, 旁路服务注册中心作为协调者完成服务的自动注册和发现，服务之间的通信及容错机制开始模块化， 并形成独立的服务框架。 但是， 随着服务框架内功能的日益增多，复用不同编程语言开发的基础功能就显得十分困难，这也意味着微服务的开发人员将被迫绑定在某种特定语言之上，从而违背了微服务的敏捷迭代原则。
2016年出现了第三代微服务架构, 即服务网格( Service Mesh)。原来被模块化到框架里的微服务基础能力，从一个SDK演进成为一个独立的进程 Sidecar(边车)。这个变化使得第二代架构中的多语言支持问题得到了彻底解决, 微服务基础能力演进和业务逻辑迭代彻底解耦。第三代微服务架构就是云原生时代的微服务架构,边车进程开始接管微服务应用之间的流量, 承载第二代微架构中服务框架的功能, 包括服务发现、调用容错以及丰富的服务治理功能，例如权重路由、灰度路由、流量重放、服务伪装等。