Implement_multiple_languages

跨语言支持

前言

本文主要讨论的是一个Java服务化框架在做跨语言支持时的一些思路。

我们大家都知道，RPC通讯在跨语言时，主要关注两件事情：通讯协议和序列化协议。

下面我就列举下常见的几种做法：

通用协议模式

1. 选择一种通用的通讯协议，例如HTTP/1.1
2. 选择一种泛化的序列化协议，例如JSON、XML。
3. 处理起来简单，直接转为Java对象调用接口即可，返回的时候也返回泛化数据

优点：

• 简单，基本无需改动
• 扩展性好。

缺点：

• 太随意，所以基本没有所谓的接口定义
• 性能一般。

常见的如：HTTP/1.1+RESTFul+JSON

接口定义优先模式

1. 双方约定一种协议描述语言，用于描述接口、方法、参数等；
2. 然后用这个协议语言编写接口描述文件
3. 使用接口描述文件，生成不同语言的各自代码。简单点的生成序列化代码，高级点的可以生成服务端和客户端的代码。
4. 通讯协议的选择不用太关注，只要双方能知道拿到的数据即可。

优点：

• 严格的接口定义
• 性能高

缺点：

• 支持的数据结构不能太复杂
• 代码入侵，如果已有系统改成这种，则改动较大

常见的如：thrift、gRPC（HTTP/2+Protobuf）

Java定义优先模式

但是假如有的Java系统，已经运行在线上了，而且传输的数据格式比较简单，能够平滑生成接口描述，那么我们可以采用这种方式。

1. 读取已有的Java接口文件，可以简单加个注解等增加描述准确度
2. 使用插件等手段自动生成一份接口描述文件，再生成双方代码。（参见接口定义优先）
3. Java端在调用和被调用的时候，都进行一个数据的内部协议转换，将跨语言的数据结构转换为内部的数据结构。

优点：

• 面向Java定义的已有接口，开发工作量小
• 性能高

缺点：

• 支持的数据结构不能太复杂，而且生成的接口描述文件为特殊格式（需要用于转换）
• 可以使用代理类忽略Java端的代码入侵

其它语言兼容模式

如果系统非常重要，不能动，抑或数据结构很复杂（例如Java的父子类，泛型，抽象类等），那么可以要求跨语言端进行全面兼容。

1. 读取已有的Java接口文件，可以简单加个注解等增加描述准确度
2. 使用插件等手段自动生成一份接口描述文件，再生成其它语言端代码。（参见接口定义优先）
3. 其它语言全面实现Java服务框架目前的序列化协议和通讯协议，让Java端调其它语言和调Java语言一模一样

优点：

• Java端无需任何开发工作
• 性能高

缺点：

• 其它语言端工作量大
• 支持Java服务框架目前的序列化协议和通讯协议

Beyond SOA

本框架支持：

• 通用协议:
  • 支持HTTP+JSON直接调用
• 接口定义优先：
  • 支持protobuf协议，可使用protoc和protoc-gen-bsoa-java.exe插件，生成接口文件和对象文件
  • 支持thrift协议
• Java定义优先：
  • 使用bsoa-protobuf-maven-plugin生成.proto文件
  • 使用.proto文件支持接口定义，或者支持gRPC调用