转载

谈谈surging 与多语言混合微服务构思

1、前言

微服务架构已成为目前互联网架构的趋势，关于微服务的讨论，几乎是各大技术论坛、技术大会的热门话题。而Surging是高性能的模块化微服务引擎，是大家首选微服务引擎架构之一，而针对于框架有个突出的缺点就是只能支持基于.NET CORE开发，而现如今各大公司开发语言是多样的，每个业务线有各自开发的语言，所以出现了多语言之间服务调用的问题。

跨语言调用是大家比较关心的话题，在这里我也提出自己的构思，后面计划实现基于java的surging ，可以和.NET CORE 进行互相调用。在这篇文章也会大致讨论一下我的构思：

而在开始之前，我想说下surging 是开源的，大家可以花时间去专研研究代码，也欢迎大家提供想法，贡献PR,但是如果你想节约时间，想深入了解surging,或者熟知如何部署，您可以购买作者的时间给你来四场一对多的直播，或者您有技术的疑难也可以通过购买企业服务的方式进行一对一的解答。而大家关心的事，有没有企业购买或者使用，在这里可以告诉你有，有很多。而且已经做了多场直播，还有购买OEM版权的。

2、协议之间适配

大家最初最常用的想要实现“跨语言”大多数方案是使用 http 协议做一层转换，最常见的手段莫过于借助 webapi 提供的 controller/action，间接通过httpclient调用webapi 提供的rest。这种方案的调用使得链路变长，tcp 通信之上又多了一层 http 通信,还需要写一套外层的webapi,不论是开发时间还是性能都有所拉长。

而针对于surging 是支持多种协议，surging内部提供了基于netty 的RPC协议之外，还有rest协议和grpc协议可供选择。这两者都是通用的跨语言协议。

rest 协议为满足标准规范，在开发过程中引入了 GET、POST、PUT、DELETE 等特性，而这些特性可以通过元数据的方式注册到注册中心，对于习惯于编写传统rest 接口的人可以通过rest进行对接。

Gprc 更可以通过Google Protocol Buffers做到跨协议调用

RPC 跨协议调用就需要考虑消息模型报文格式和序列化方案，而针对于消息报文包括了消息Id，消息类型，消息内容，而消息内容有两种类型，一种是远程调用消息，一种是远程调用结果消息。只要满足以上报文传递就可以了，而针对于报文必然要序列化和反序列化，而框架中提供了messagepack、ProtocolBuffers、Json.

谈谈surging 与多语言混合微服务构思

3、服务治理与注册中心适配

谈到服务治理必然要谈到容错规则、负载均衡、服务路由，对于这些参数的适配，必然需要注册中心进行存储，而框架实现了基于consul 和 zookeeper 注册中心。

而谈到多语言混合，必然针对于每种语言都要考虑如何把服务路由信息注册到注册中心，并且需要实现一套基于consul 的心跳方式交互，还有一套基于zookeeper 的watcher 机制交互，而针对于服务路由里面包含了服务地址列表，需要实现针对于每种语言写一套负载算法，包括了轮询、哈希、随机算法，还需要实现一套各语言容错规则的判断，再发生错误时，能通过容错规则发生熔断。

4、服务链路跟踪适配

而针对于框架实现了一套基于skywalking的服务链路跟踪，它支持基于rpc、rest、mqtt 协议服务跟踪，如果没有通过rest 主入口访问调用所产生的调用都是单链路的，而通过rest,可以产生调用链路，

可以通过TraceId传递，来衔接多语言混合链路跟踪，并且需要把收集性能跟踪信息交互到skywalking

4、拦截器的适配

而针对于拦截器考虑到需要跨语言和扩展性，在框架内部已经把拦截器参数和ID抽象化到服务路由元数据当中。并且可以针对于拦截器进行扩展，而框架实现了ServiceCacheIntercept和ServiceLogIntercept，而针对于跨语言需要做的是解析元数据，转化成拦截器参数，再通过参数去实现业务拦截降级，而以下是基于consul 注册的服务路由，里面包含了拦截器元数据

谈谈surging 与多语言混合微服务构思