关于部门后端全部转向java前初步设想

Java服务有些什么形式？目前来看主要是以下几类：

1、  运行在Web应用服务器的Servlet

2、  Thrift、PB、Avro等类似框架写的java服务

3、  WebService(JAX-WS、JAX-RS)

现在我们服务端要全面转向java。

1  若后端子系统全部用Servlet写，将无法实现跨语言，我们现在客户端大部分还是.NET平台。

2  若用Thrift等框架，现在满足了.NET调用Java服务，以后若客户端也全面使用用Java了，并且是Web客户端，那么用Thrift写的java服务如何进行服务。

3  Webservice不考虑，restful描述能力有限，SOAP也比较复杂，况且WS的主要应用场景是在于与第三方团队协作开发、或者公布内部系统接口给其他企业使用类似的场景，可能在广域网环境下的C/S架构也会考虑。我们自己内部的平台还是需要考虑使用稳定、可靠、高效、简单的RPC框架较为合适。

 

思考再三决定采用如下架构：

 

 

正好结合我之前开发的分布式注册中心、消息中间件等组件，后端子系统可以形成一个良好的生态圈。 

这只是初步设想，还需进一步仔细考虑，若哪位有经验的朋友路过可以赐教。

还有一个问题不明，现在互联网业界常规的做法，后端Java子系统的运行形式一般是什么？

是运行在Web应用服务器的Servlet？那么如何提供服务给其他平台的子系统使用？

是Thrift等RPC框架编写的Java服务？那么其生命周期，调度等如何进行管理？

这样的架构下，.NET客户端直接调用后端服务，如果是在广域网环境下，Thrift、Ice这类框架（基于TCP协议）还能够稳定高效地工作？

对于这种情况是否换成基于Http协议的WebService较为合适？