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

Java服务有些什么形式？眼下来看主要是下面几类：

1、  执行在Web应用server的Servlet

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

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

如今我们服务端要全面转向java。

1  若后端子系统所实用Servlet写。将无法实现跨语言，我们如今client大部分还是.NET平台。

2  若用Thrift等框架，如今满足了.NET调用Java服务，以后若client也全面使用用Java了。而且是Webclient，那么用Thrift写的java服务怎样进行服务。

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

 

思考再三决定採用例如以下架构：

 

 

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

 

这仅仅是初步设想，还需进一步细致考虑。若哪位有经验的朋友路过能够赐教。

另一个问题不明。如今互联网业界常规的做法。后端Java子系统的执行形式通常是什么？

是执行在Web应用server的Servlet？那么怎样提供服务给其它平台的子系统使用？

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

这种架构下。.NETclient直接调用后端服务，假设是在广域网环境下，Thrift、Ice这类框架（基于TCP协议）还能够稳定高效地工作？

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