争议 | 单语言 or 多语言，SDK or Sidecar，微服务架构如何选择？

来自twt社区同行交流，欢迎更多同行参与交流

如何选用跨语言的微服务框架？

每个语言都有自己的微服务架构实现，如JAVA的Spring Cloud，Go的Go kit等，其实现各不相同，如何选用跨语言的微服务架构？

问题来自@robolwq 软件架构设计师，下文来自twt社区众多同行实践经验分享。

@尘世随缘 上海某互联网金融公司 技术总监：

首先判断自己擅长的语言以及团队擅长的语言，另外使用这门语言的人是否容易招聘，招聘成本是否高，另外这门选择的语言是否有开源的RPC框架，以及框架的使用情况和维护情况。

@gavin_zhang 某股份制银行 系统架构师：

目前好像没有什么做的比较好的跨语言微服务框架，但是大部分的服务治理服务都支持通用的协议。在实际应用中，一个系统采用多语言的情况也不多，都有一种主要语言，选择主要语言的框架，其他语言通过API实现一个轻量级的对接。

如果确实需要实现多语言的微服务系统，目前ServiceMesh（如：Istio）是最好的选择，通过Sidecar实现，和语言无关。

@liufengyi 某互联网银行 软件架构设计师：

跨语言的微服务框架有维护成本高的问题，一般同一个公司有多种语言的存在，建议使用下一代的微服务技术——service mesh，彻底解决跨语言的问题。

@archy77fu 某金融保险公司 产品经理：

1、企业或团队选择的技术栈和开发框架应尽量统一，不仅能有效减少技术管理的复杂度，而且能有效降低各类技术平台落地的复杂度，包括微服务架构体系在企业或团队的落地。

2、在多语言的开发体系下，最好是逐步转向以一种语言和微服务框架为主的方向，同时可通过服务网格等方式标准化服务交互来实现不同体系的服务治理。

@fengqing 中国金融电子化公司 软件架构设计师：

1 、微服务框架其服务节点之间通讯协议必须是标准的、规范的，例如 HTTP 协议，基本上大部分语言都支持 HTTP 协议 ，这样才能跨语言。

2 、梳理项目团队对微服务框架的功能、性能、扩展型方面的需求，然后对比业界主流的微服务框架，那个更满足需求。

3 、选择的微服务框架在满足需求的基础上最好是项目团队比较熟悉的语言开发的，并且容易学习，这样后期维护成本和风险低。

@moonfire94 某证券 系统架构师：

应该先确认下是否有跨语言的场景或是否可以统一语言，多语言是技术负债。单语言的微服务框架当然首选spring cloud，首先是java的普及率在成本及快速满足业务上有很大优势，另spring cloud的服务治理体系很完善。

如果真有多语言的场景，可以在架构上划区分层。例如交易基础服务采用C，业务操作区域采用java，两个区域通过边界总线交互。

@狄俄尼索斯 UProject 软件架构设计师：

微服务框架当前有两种模式：SDK模式与SideCar模式。SDK模式是语言相关的、侵入式的；SideCar模式是语言无关的、非侵入式的。

要选择跨语言的微服务框架，就选择SideCar模式的，Istio。

@于爽 青云QingCloud 产品经理：

单纯从技术角度考虑，依托于sidecar 这种设计模式的service mesh 框架应该是最合适的答案，但在现实企业环境里面，企业管理者是否会选择多语言这种模式去运营自己的技术团队？管理成本、人力成本是否会造成很大的负担？

@roy_winer123 南京楚星 软件架构设计师：

微服务其实是语言无关的，无非是边界服务交互，我觉得最重要的是领域模型边界接口抽象，具体实现服务语言可以是任何语言。