单纯从技术角度考虑,依托于sidecar 这种设计模式的service mesh 框架应该是最合适的答案,但在现实企业环境里面,企业管理者是否会选择多语言这种模式去运营自己的技术团队?管理成本、人力成本是否会造成很大的负担?
收起1、企业或团队选择的技术栈和开发框架应尽量统一,不仅能有效减少技术管理的复杂度,而且能有效降低各类技术平台落地的复杂度,包括微服务架构体系在企业或团队的落地。
2、在多语言的开发体系下,最好是逐步转向以一种语言和微服务框架为主的方向,同时可通过服务网格等方式标准化服务交互来实现不同体系的服务治理。
1 、微服务框架其服务节点之间通讯协议必须是标准的、规范的,例如 HTTP 协议,基本上大部分语言都支持 HTTP 协议 ,这样才能跨语言。
2 、梳理项目团队对微服务框架的功能、性能、扩展型方面的需求,然后对比业界主流的微服务框架,那个更满足需求。
3 、选择的微服务框架在满足需求的基础上最好是项目团队比较熟悉的语言开发的,并且容易学习,这样后期维护成本和风险低。
认为先确认下是否有跨语言的场景或是否可以统一成语言,多语言是技术负债。单语言的微服务框架当然首选spring cloud,首先是java的普及率在成本及快速满足业务上有很大优势,另spring cloud的服务治理体系很完善。
如果真有多语言的场景,可以在架构上划区分层。例如交易基础服务采用C,业务操作区域采用java,两个区域通过边界总线交互。
微服务框架当前有两种模式:SDK模式与SideCar模式。SDK模式是语言相关的、侵入式的;SideCar模式是语言无关的、非侵入式的。
要选择跨语言的微服务框架,就选择SideCar模式的,Istio。
目前好想没有什么做的比较好的跨语言微服务框架,但是大部分的服务治理服务都支持通用的协议。 在实际应用中,一个系统采用多语言的情况也不多,都有一种主要语言,选择主要语言的框架,其他语言通过API实现一个轻量级的对接。
如果确实需要实现多语言的微服务系统,目前ServiceMesh(如:Istio)是最好的选择,通过Sidecar实现,和语言无关。