第一代
在第一代微服务架构中，应用除了需要实现业务逻辑之外，还需要自行解决上下游寻址、通信及容错等问题。随着微服务规模的逐渐扩大，服务寻址逻辑的处理正变得越来越复杂，哪怕是同一种编程语言的另一个应用，上述微服务的基础能力也需要重新实现一遍。
第二代
在第二代微服务架构中, 旁路服务注册中心作为协调者完成服务的自动注册和发现，服务之间的通信及容错机制开始模块化， 并形成独立的服务框架。但是， 随着服务框架内功能的日益增多，复用不同编程语言开发的基础功能就显得十分困难，这也意味着微服务的开发人员将被迫绑定在某种特定语言之上，从而违背了微服务的敏捷迭代原则。
第三代: 服务网格
2016年出现了第三代微服务架构, 即服务网格( Service Mesh)。原来被模块化到框架里的微服务基础能力，从一个SDK演进成为一个独立的进程 Sidecar(边车)。这个变化使得第二代架构中的多语言支持问题得到了彻底解决, 微服务基础能力演进和业务逻辑迭代彻底解耦。第三代微服务架构就是云原生时代的微服务架构,边车进程开始接管微服务应用之间的流量, 承载第二代微架构中服务框架的功能, 包括服务发现、调用容错以及丰富的服务治理功能，例如权重路由、灰度路由、流量重放、服务伪装等。
第四代: 多运行时微服务架构
随着AWS Lambda的出现，部分应用开始尝试利用serverless技术来构建微服务, 第四代微服务架构出现。在第四代微服务架构中，微服务由一个应用进一步简化为微逻辑(Micrologic), 这也对边车模式提出了更高要求，更多可复用的分布式能力从应用中剥离，并下沉到边车中，例如状态管理、 资源绑定、链路追踪、事务管理、安全等。同时，开发侧开始提倡面向 localhost 编程的理念，并提供标准API屏蔽底层资源、服务、基础设施之间的差异，以进一步降低微服务的开发难度。第四代微服务架构就是目前业界提出的多运行时微服务架构(Multi-Runtime Microservice)。
参考：《阿里云云原生架构实践》
