热门搜索:
您现在的位置是：首页 > 文章详情

Spring Cloud? Kubernetes? Istio?服务治理方案怎么选

日期：2020-10-30点击：579

不同选择分别代表了两个方向：

  • 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？ 
注：
最后，如果以上观点对你带来了一点点帮助或者启发，动动鼠标点个赞呗 🙇
原文链接：https://my.oschina.net/u/267941/blog/4696140
关注公众号

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。

持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

转载内容版权归作者及来源网站所有，本站原创内容转载请注明来源。

相关文章

    文章评论

    共有0条评论来说两句吧...

    文章二维码

    扫描即可查看该文章

    点击排行

    推荐阅读

    最新文章