组件与中间件架构的耦合

很多软件开发人员构建分布式应用时都离不开中间件的支撑，不过要在什么架构和中间件是最好的这个问题上达成共识就更困难了。本文探讨为什么组件耦合会带来特别的挑战，以及云计算是如何通过微服务等来引入这一系列变化的。

驱动分布式应用的应用或架构需要能够同时控制组件耦合和中间件。这意味着确定主要耦合模型，从云角度考虑组件耦合模型和趋势，在开发中将耦合模型分类，以及将组件耦合和中间件架构关联起来。

在应用组件之间传递工作是分布式开发的核心需求，也是软件组件重用策略的基准。云所具有的关联组件化和耦合效率带来资源的高效和敏捷，这决定性得揭示了耦合组件以及开发分布式软件的最佳方式。理解基础中间件耦合方案至关重要。

中间件耦合的最基本问题是被调和调用进程是否是实时同步的。这意味着所要求的服务只在其可以被接受的时候才会被分发，这在耦合中加入了多线程限制，除非整个应用程序是单线程的。如今，传递消息的接口支持实时耦合，基于消息的中间件支持基于队列的解耦合，从而在有多个请求并且目的地组件不在线时，能够允许处理消息的组件将消息聚合。

中间件耦合领域需要解决的第二个问题是服务请求是阻隔的还是非阻隔的。当消息发送后，理论上说，发送方可以等待回复（阻隔）或者继续做其他事情（非阻隔）——接受组件也与之类似。其他组件的阻隔调用会在服务完成并且返回结果前将调用进程停止，这很容易实现。当使用非阻隔耦合时，应用程序需要识别发送到别处处理的消息回复，这要求更精细的应用程序实现。该模型通常称为事件处理器，因为它要求组件处理异步呈现的工作。

让我们转向云开发。云推动了RESTful模型的流行。该模型下，消息传递给无状态组件处理。在无状态模型里，每个消息作为一个完整的实体处理，RESTful组件的调用者负责在一系列工作请求链里维护上下文或者状态——比如在事务处理里会发生什么。

针对组件间工作流管理的RESTful方案，和更为传统的通常和CORBA以及SOA一起使用的远程过程调用（RPC）模型相对比。使用RPC方案，应用程序组件通过把远程组件当做本地调用而对其做操作。因此，调用组件的上下文和状态和被调用组件是紧耦合的。

使用合适的组件设计方案，RPC模型能够支持时间同步和异步两种方式，以及阻隔和非阻隔消息处理。主要由支持大量并发事件的Web服务器应用程序设计的RESTful接口，自然会更偏向于异步。良好的云组件设计倾向于鼓励使用事件处理器，和非阻隔应用程序设计模式。

中间件耦合的最后一点和方向性相关。在传统中间件架构里，开发人员可以构建双向（请求/响应）流，或者可以构建单向（一个方向）流，这里请求和响应是单独事件，通过消息内容，而不是流程状态相关联。消息处理接口通常用于双向流，基于消息的中间件内容（MOM）的概念通常用于单向流。

中间件耦合问题，特别随着向云技术的演进，将应用当作一系列进程而不是一系列组件可以很好得控制这个问题。一个Web应用程序线程在客户端形态各异，在服务器端差异不大。大多数情况下，展示给用户的客户端天然是单线程和阻隔的。如果你的应用程序可以使用该模型，那么设计本质上就是一个Web应用，并且主要遵循RESTful原则。这时，必须为耦合使用最小的中间件支持，并且在Web兼容性上关注于中间件的选择。

真正分布式处理中的事务线程是工作流事件链。通常最好使用服务或者消息总线以及流程语言引擎来缓解这样的耦合。将这样的方案应用到云环境里会创建出比很多应用程序规划师和架构师想要的更为严格的耦合性，但是避免这样的方案则要求每个事务一个线程，这在很多场景下可实现，但是要求特别的设计。消息里的状态管理，和基于消息的中间件以及RESTful接口，能够创造出适合云的框架。

中间件耦合的三大主要问题可以通过云上的实践，比如微服务，来加以解决，但是不可否认MOM模型更容易实现。但是，组件可以聚合起来，在其内部使用不同的机制解决耦合问题。在Web应用程序里，这样的方案很常见，在前端使用RESTful耦合客户端线程，然后后台实现基于MOM的事务处理。

重点是耦合组件必须首先基于应用作优化，然后选择中间件和接口来支持这个优化过的模型。当这么做时，使用最简单的中间件架构和最开放的实现。这样会让你的方案尽可能得开放。