三种设计模式的特点、场景和区别：
- Sidecar 的方式主要是用来改造已有服务。要在一个架构中实施一些架构变更时，需要业务方一起过来进行一些改造。然而业务方的事情比较多，像架构上的变更会低优先级处理，这就导致架构变更的“政治复杂度”太高。而通过 Sidecar 的方式，可以适配应用服务，成为应用服务进出请求的代理。这样，就可以干很多对于业务方完全透明的事情了。
- 当 Sidecar 在架构中越来越多时，需要对 Sidecar 进行统一的管理。于是，为 Sidecar 增加了一个全局的中心控制器，就出现了 Service Mesh。在中心控制器出现以后，可以把非业务功能的东西全部实现在 Sidecar 和 Controller 中，于是就成了一个网格。业务方只需要把服务往这个网格中一放就好了，与其它服务的通讯、服务的弹力等都不用管了，像一个服务的 PaaS 平台。
- 然而，Service Mesh 的架构和部署太过于复杂，会让运维层面上的复杂度变大。为了简化这个架构的复杂度， Sidecar 的粒度应该是可粗可细的，这样更为方便。Gateway 更为适合，而且 Gateway 只负责进入的请求，不像 Sidecar 还需要负责对外的请求。因为 Gateway 可以把一组服务给聚合起来，所以服务对外的请求可以交给对方服务的 Gateway。于是，只需要用一个负责进入请求的 Gateway 来简化需要同时负责进出请求的 Sidecar 的复杂度。
此文章为4月Day01学习笔记，内容来源于极客时间《左耳听风》，强烈推荐该课程！
