不同选择分别代表了两个方向：
- embedded component 内嵌组件 如（Ribbon，DiscoveryClient，Hystrix，Sleuth等）
- attached sidecar 附着挎斗 （如 kube-proxy, istio sidecar等）
sidecar分离了服务治理所需的部分职能到与业务应用不同的进程中完成，也代表着：
- 业务应用的技术栈选择更加灵活
- 服务治理的配置与业务应用分离
- 服务治理的配置对于DevOps人员更加友好
- 服务治理相关功能的演进速度更快
这些好处显而易见，在happy-path下我们可能无往不利
但同时也意味着：
- 熔断、限流等需要DevOps人员不止关注到业务应用，还需要对不同接口进行配置管理。可能需要和开发人员对齐不同接口的设计规格（流量、负载、可用性指标等）
- 根据老马对熔断的描述，熔断不单单是断掉就万事大吉，需要我们关注降级处理方案（fallback）(注1），而这些istio并未提供支持（注2，3）
- 灰度/金丝雀发布在istio中的实现方案（注7、8）基于header(cookie)，意味着可能会信息泄露或被客户端仿造，若内部组件控制则可能再次出现业务逻辑的耦合
- 灰度/金丝雀发布在某些需求下可能涉及业务逻辑（如：VIP会员可以尝鲜新版应用），需要定制化开发路由逻辑，而在sidecar中编入业务逻辑明显不符合其设计初衷
- 定位错误、调试、定制化开发不同程度上需要团队中有对应平台（Go，C++等）经验的自身工程师存在，并且该工程师需要高度适应平台的快速迭代
- sidecar不是特等公民，一样会崩溃、报错（注4）。monitor 和metrics等监控、报警相关基础设施及配置也是必经之路（注5）
- 两次请求转发带来的性能损耗不可忽视，在不同的挂载方案中性能损耗可能有数倍差别（注6），被挂载sidecar的应用thoughtput能力越强，性能损耗对其影响越大
当然，以上问题并不是所有服务集群都涉及到，简单归纳结论即：
适合采用或继续选择SpringCloud方案的情况：
- 团队主要/完全由熟悉Java/Spring 技术栈的工程师组成
- 对灰度发布、服务注册/发现等组件有定制化能力需求
- 有完整的熔断能力需求
- DevOps团队尚未具有可以自主完成高压问题的定位、处理能力
适合采用Kubernetes/Istio方案的情况：
- 团队由多技术栈工程师组成
- 服务治理需要涉及不同平台、技术栈
- DevOps与开发团队通力合作，可以顺利完成对接口的设计规格（流量、负载、可用性指标等）配置管理
- DevOps团队或者对应技术专家能够自主完成sidecar或类似组件在Go、C++等技术栈下对高压问题定位、处理
- 有完整的sidecar监控、告警
- 不需要熔断，或者熔断方案中不需要服务降级能力
- 不需要业务敏感的路由、灰度发布能力
一点发散思维：
如果我们顺着用sidecar分离非业务代码的方向走，
那我们的应用系统与数据库、磁盘等外部资源进行通信的时候，是否要：
- 做个磁盘IO sidecar？
- 做个数据库连接池sidecar？（注9）
- 做个NFS sidecar？
注：
最后，如果以上观点对你带来了一点点帮助或者启发，动动鼠标点个赞呗
![🙇]()
