如何实现

Java 跨语言方案

背景：

在大型分布式

 java 应用中，为了方便开发者，通常底层的 rpc 框架都会做一些调用的封装，

让应用层开发人员在开发服务的时候只用编写简单的

 pojo 对象就可以了，如流行的 spring 

remoting ， jboss remoting 等等，都有这样的效果。

随着业务的需要，可能上层应用希望采用非

 java 技术，如 php ， ruby on rails ，而由于

 

java gc 和内存模型的限制，可能有的底层服务又需要采用更高性能和更加灵活的技术，如
果

 c++ ， python 等。

这时候就会考虑跨语言的问题了，在如何不改动原有

 pojo 实现的 rpc 框架，而让系统实现

跨语言，这个难题摆在了中间件开发者的头上。

问题

 :

现在我们不妨把上面说涉及的问题提取出来：

1）  不能改变原有的 java rpc 服务的发布方式，仍然采用 pojo 。

2）  上层非 java 应用可以调用到由 server 端 pojo 形式发布的服务。

3）  底层非 java 应用，如 c++ ， python 等可以发布格式和 pojo service 一样的服务

4）  提供优雅的借口给应用开发者。

业界考察：

好在我们并不是第一个遇到这个问题的人，那我们来看看在我们业界的前辈们都给我们留
下了哪些宝贵的财富（主要是互联网行业）。

Google protocol buffers ： Google 大神总是早人一步，在 google 架构的初期就意识到了跨
语言的重要性，在构建

 bigtable ， GFS 的同一时期就是定制出了一套跨语言方案。那就是

 

google protocol buffers ，不过直到 08 年， google protocl buffers 才开源出来，正所谓国之利
器不可以示人，我们所看到的，

 google protocl buffers 其实是阉割版，如没有 map 的支持 ( 

根据一些资料表明，

 google 内部是有这个东西的) ， python 的 native c 性能优化，不包括

 

rpc service ，虽然后面补了一个，但是可用性差强人意，不能多参，不能抛异常。不过在这
方面我们确实不应该报太大的希望，因为

 google 自己都说了 protocol buffers – a language-