谈谈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、拦截器的适配

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

5、总结

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