微服务与SOA架构（一）

合约解耦

合约解耦（contract decoupling）可以认为是抽象的最高境界。合约解耦的本质含义是允许服务客户用不同于服务所期望的消息格式与之通信。

合约解耦是一种强大的能力，能够为服务客户和服务之间提供最大程度的解耦。这种能力允许服务和服务客户之间相互独立地演化，同时仍然在彼此之间维护着合约。这种能力也使得服务客户有能力通过客户驱动的合约来推动合约变更，从而在服务客户和服务之间建立一种更加密切的合作关系。

合约解耦的形式主要有两种：消息转换和消息增强。消息转换只关注消息格式而不是请求数据本身。例如，一个服务可能要求消息请求以XML作为输入格式，但是某个服务客户决定发送JSON数据。这种转换工作比较直接，可以使用大多数开源的集成枢纽软件来处理，包括Apache Camel、Mule和Spring Integration等等。

当服务客户所发送的数据跟服务所期望的不同时，事情就会变得比较麻烦。实际合约数据中的失配可以通过消息增强能力来解决。消息转化关心的是请求数据的格式，消息增强则关注的是数据本身。消息增强能力允许组件（一般是中间件组件）添加或者改变请求数据，从而使得服务客户所发送的数据复合服务的期望。

考虑这样一个场景，客户为执行简单股票交易以JSON对象的格式发送数据。服务客户通过发送客户ID、CUSIP代码来指定对哪只股票执行操作、要操作多少股，最后是MM/DD/YY格式的交易日期。

{"trade": {
"cust_id": "12345",
"cusip": "037833100",
"shares": "1000",
"trade_dt": "10/12/15"
}}

而服务本身期望接收的是XML格式数据，其中包括账户号、股票代码、交易股数以及格式为YYYY.MM.DD的日期。

<trade>
<acct>321109</acct>
<symbol>AAPL</symbol>
<shares>1000</shares>
<date>2015-10-12</date>
</trade>

如果客户和服务之间在合约格式上出现分歧，一般需要依靠消息中间件或者定制的客户适配器来执行必要数据转换以及数据查询功能使得不同合约之间能够平滑工作。图4-3给出了一个这样的例子。数据库或者缓存查询可以基于customer ID得到账户号，基于CUSIP代码的股票号码。日期可以被转换成不同格式，交易股数则可以不做转换地拷贝到新的数据结构。通过转换，可以允许客户采用与服务不同的协约，当发生合约变更发生时，消息中间件可以屏蔽这些差异。

图 4-3

合约解耦显然有一些使用上的局限。如果服务所需数据无法从客户所发送数据转换获得也无法从其它数据源获得，服务调用只能返回失败，因为服务合约无法得到满足。幸运的是，服务客户与服务之间的协议分歧大多数时候可以通过查询能力和基本的转换（例如日期，时间和数字域）来予以弥补。

现在IT业界碰到 一个问题是如何防止技术（IT部门）驱动业务。无论是升级一个大规模子系统的软件版本还是替换财务或客户管理系统，都可以通过合约解耦来实现接口和合约抽象，进而使得IT部门的技术变更不会影响到企业的业务应用。之前的股票交易场景是一个很好的例子。将使用CUSIP代码的交易平台替换为使用SEDOL代码的平台并不意味着企业的所有业务应用都需要改成使用SEDOL代码。

不幸的是，微服务在这一架构上又输给了SOA。微服务架构不支持合约解耦，而合约解耦是SOA架构所提供的主要能力之一。如果你自己的架构中需要这种层次的抽象化，那么最好为自己的应用或系统选择SOA解决方案而不是微服务。

总结

微服务架构模式是IT行业正在升起的明星。尽管微服务模式解决了大规模单体式应用和复杂SOA架构下的很多问题，但是它的确也缺少某些SOA提供的核心能力，包括合约解耦和协议无关的异构互操作性。

需要记住的一个基础概念是，微服务架构是“能不共享则不共享”的架构模式，非常强调限定语境，而SOA是“能共享则共享”的架构模式，侧重抽象和业务功能的重用。通过理解这一基本概念以及微服务与SOA的其它特点、能力与不足，就可以在做架构选择时有更明确的判定标准。

如果了解更多微服务和SOA以及分布式架构，可以参看Neal Ford和Mark Richards的Service-Based Architectures: Structure, Engineering Practices, and Migration（http://shop.oreilly.com/product/0636920042655.do）。

如果想深入了解微服务，建议参考Sam Newman的书：《 Building Microservices》（http://shop.oreilly.com/product/0636920033158.do）。

最后，如果想了解微服务和SOA等基于服务的架构中所涉及的消息技术，可以参看 Enterprise Messaging: JMS 1.1 and JMS 2.0 Fundamentals （http://shop.oreilly.com/product/0636920034698.do）和 Enterprise Messaging: Advanced Topics and Spring JMS（http://shop.oreilly.com/product/0636920034865.do）。

原文来自:Docker

声明：所有来源为“聚合数据”的内容信息，未经本网许可，不得转载！如对内容有异议或投诉，请与我们联系。邮箱：marketing@think-land.com