【转】大型Java分布式应用纵横谈

      越来越多的基于REST的服务开始取代SOAP。Java中的REST服务在JSR 311中有说明，是基于HTTP所支持的基本操作而设计的。但是，REST不是作为RCP协议，而是面向资源的，为了访问和操作(web)资源而设计的。这两个协议都支持同步通信。这也是底层HTTP协议所要求的。WS-地址对SOAP协议进行扩展，所以它也允许异步服务的实现。REST最大的优点是，能够很容易的通过HTTP代理实现缓存。REST依靠使用HTTP底层协议，无论如何都和用的机制。

　　可能犯的错

　　分布式应用的很多地方都可能出现潜在的问题，如图所示：

　　图5 分布式应用的问题起因

　　在客户端，主要的问题在于糟糕的交互设计-太多的服务调用，或者选择了错误的通信模式。同步事务运行时间过长很容易导致性能问题。在通信层，大量的数据和过多的服务调用所产生的高的网络负载是主要问题。在服务端，不适当的服务接口设计和不合适的序列化策略的使用导致性能和扩展性问题。我们下面仔细看下这些问题。

　　分布式应用的问题起因

　　通信协议的正确选择主要取决于系统的整体架构和底层的需求。如果你工作在有mainframe、Java和.NET组件相互交互的特异环境中，用SOAP是行不通的。在纯Java环境中，在JRMP上使用RMI仍是性能最优，可扩展性最好的解决方案，你能够获得开箱即用的编程支持。在很多SOA实现中，SOA和基于Web Service的实现同义而语。所以有越来越多的使用SOAP作为RPC协议的纯Java应用案例出现，尽管采用这样的方法一点有点都没有。调查显示，和RMI-JRMP相比，经常使用SOAP还是有意义的。除了描述过的标准协议，一些其他的基于XML的和二进制协议也在一些应用中使用。Hessian的性能就不错。另外，还有一些其他编程语言的实现。例如使用Spring把POJOs暴露给远程调用使不改变实现就在不同的协议间切换变得相对容易。Spring 支持RMI, HTTP, Hessian, Burlap, JAX-RPC, JAX-WS 和 JMS。

　　反模式：饶舌的应用

　　在搭建分布式应用时，一个核心的原则就是尽量减少远程调用。这些意味着数据序列化的开销，建立连接的开销和附件的网络负载。另外，CPU,内存和网络资源的消耗限制了可扩展性。所以，为远程应用的接口设计一种方法，来确保必要的服务交互数最小是十分重要的。尤其是那些起初是在本地搭建的，然后为了可扩展性原因遭遇了大量服务交互的应用。这些问题大多会在负载测试或产品化时出现，但当本地开发测试时一点问题都没有。可以采用适当的性能管理方法，在开发过程中分析远程行为就可以避免这些问题。下图显示的是一个通过dynaTrace分析一个应用的远程行为的例子 。

 

　　基于这个分析，接口能够重新创建，应用逻辑能够重新设计来减少远程调用的次数。可能的方法是，合并几个方法的逻辑为一个，或在几个调用请求周边的对象处，使用数据容器。特定数据的位置也可以帮助减少远程调用，因为在需要的地方数据是可用的。尤其当读数据时，使用cache可以很大程度上提高性能和可扩展性。在软件设计的早期，服务的分发和可能的通信在成为需求或将成为需求时已经考虑到是很重要的。

　　反模式：大格式消息

　　当调用远程的服务时，这通常意味着数据会在不同的协议上传输。像XML在SOAP协议上传输或二进制数据在RMI协议上传输。大多数技术传输对象的数据或对象本身。大多数情况下，序列化的发生是在远程实现的底层。序列化的开销和所传输对象的大小相对应。在实际情况下，我们进行序列化的开销要占到98%。怎么会这样?一个鉴权服务接口需要一个用户对象来授权。这个用户对象不仅有用户名和密码，还有很多属性，关联到其他用例的数据引用。标准的SOAP序列化要创建几千字节的数据消息。这些数据要被服务解析并映射到用户对象结构上，导致大量CPU和内存的消耗。解决方案再明显不过了。接口要重构，只需要用户ID和密码。所以，除了选择正确的远程技术，消息内容的设计对构建好的性能和可扩展性的应用很重要。通常正好符合设计的很好一般对象会带来高性能的回报。

　　反模式：分布部署

　　分布式的Java企业级应用会导致一个应用分割成多个服务和一些部署单元部署到一些应用服务上。分布式的有一个组件新的部署包不需要重新部署到其他组件上。另一个可能性是，大量使用的服务能够部署到独立的硬件或被部署多次。有大量部署单元的复杂应用，服务的交互变得越来越难理解。这会导致2个交互频繁的服务被部署到不同的硬件上从而产生很多的远程调用情况出现。在大规模应用中，分析交互的频率和数据大小与部署结构一致是很重要的。很多时候，从分布式部署到本地可以使性能得到很大的提升而不需要损失灵活性和可扩展性。尤其对那些无状态的服务，把它们部署到不同的节点来提升其本地性。

　　结论

　　从这些反模式中可以看出，在应用的设计初期阶段就考虑可扩展性是很重要的。它是应用架构的一个关键驱动。在后期提高性能和可扩张性在多数或大多数情况下工作会越困难。对应用产品的详细分析来识别远程调用的频率或大体积数据，优化系统的一致性是不可或缺的。如果你遇到了相似的或不同的问题，请让我知道，我好扩充我的反模式记录。