谈谈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.

 

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

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

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

4、服务链路跟踪适配

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

能够经过TraceId传递，来衔接多语言混合链路跟踪，而且须要把收集性能跟踪信息交互到skywalking,如下是实现的链路跟踪

 

 

 

4、拦截器的适配

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

 

 

五、总结

以上是对于多语言混合微服务架构的一些构思，在如下日子里会去实现多语言混合架构，第一目标是先实现JAVA，还须要去花一些时间去作企业微服务培训和帮助企业更快熟悉如何构建微服务程序