微服务与SOA架构(4）

较架构能力

上一章中我们讨论了架构模式如何帮助确定基本的架构特性。本章中，我们采用类似方法，集中讨论架构模式所描述的架构能力而不是架构特性。通过分析架构模式，你可以判定应用是否易伸缩、易维护和易扩展，以及是否相对地易于开发、测试和部署。 本章中，会对微服务和SOA的架构能力进行集中讨论，主要包括三个方面：每种架构模式所能支持的最大应用规模、使用每种架构模式可以集成的系统和组件类型以及架构模式支持合约解耦的能力。

应用范围

应用范围是指某种架构可以支持的应用的总体规模。例如，微内核或者管道架构更适合较小的应用或者子系统，而其他模式如事件驱动的架构则适合于大型、更复杂应用。那么在这个谱系中微服务和SOA模式适合哪种规模的应用呢？ SOA更适合大型、复杂的、企业级系统，一般都需要整合很多异构应用和服务。也比较适合有很多共享组件的应用，特别是包含全企业内共享组件的应用。因此，SOA更适合于大型保险公司，因为这类企业内部有很多异构的系统环境，并且需要在多个应用和系统之间共享很多公共服务，如：客户、索赔和策略等等。 然而，对于拥有很多定义良好的处理工作流的基于流程的应用（例如证券交易）而言，因为没有很多共享组件，用SOA实现起来比较困难。小的、基于web的应用也不太适合SOA因为不要大量的服务术语、不需要抽象层或消息中间件。 微服务模式更适合于小型的、功能划分明确的基于web的系统而不是大规模企业级系统。使之不适合大规模复杂业务应用环境的最主要原因之一就是架构中没有一个协调者（消息中间件）。适合微服务架构模式的另外一些应用的例子是共享组件很少以及以及可以划分为更小的操作模块的应用。 某些场合中你会发现微服务架构是业务开始时很好的架构选择。随着业务成长变得成熟时，会开始需要对复杂请求进行转换的能力、实时复杂调配的能力和整合异构系统的能力。这时，你很可能会用SOA架构模式替代初始的微服务架构。当然，反之亦然。你也可能最开始设计的是复杂的、大规模的SOA架构，在后来意识到其实并不需要SOA架构的所有的强大能力。这时候，你很可能又会希望从SOA架构迁移到微服务，以简化系统架构。

异构互操作

异构可互操作性（heterogeneous interoperability）指的是与用不同语言和平台实现的系统进行集成的能力。例如，可能出现的一种场景是对同一复杂业务请求的处理需要协调一个基于Java应用，一个.NET应用和一个客户信息控制系统（Customer Information Control System，CICS）的COBOL程序。其他例子还有，比如用.NET平台实现的一个交易系统需要访问一个AS400平台完成股票交易的合规检查；某个基于Java的零售商店需要与一个大型的第三方.NET数据仓库系统相集成。 这些例子在大公司中随处可见。许多银行与保险系统仍然有大量后台核心处理采用COBOL大机应用，而这些应用需要被现代的基于Web的平台访问。整合多个异构系统和服务的能力微服务架构与SOA相比稍显薄弱的地方之一。 微服务架构风格试图通过减少服务集成的选项来简化架构模式和相关实现。REST和简单消息机制是最长用到的两个主要远程访问协议。SOA则对异构协议的使用没有约束甚或通过消息中间件来促进了异构协议的多样化。 微服务架构风格支持协议感知异构互操作（protocol-aware heterogeneous interoperability）。如果具备了协议感知的异构互操作性，就意味着架构可以支持多种远程访问协议，但是特定客户和与所访问的服务之间必须使用同一协议（例如，REST）。如图4-1所示，事实上，了解服务客户与服务之间所采用的远程访问协议并不意味着就了解任何一方是如何实现的，也不意味着双方在实现上要保持一致。例如，通过REST，服务客户可以很容易地在.NET上用C#实现出来；而服务自身则可以通过Java实现。不过，对于微服务而言，客户端与服务端在协议上必须一致，因为二者之间没有中间件组件进行协议转换。

图4-1 SOA也支持协议感知的异构互操作能力，但是它支持得更进一步，可以做到协议无关的异构互操作能力。具备协议无关的异构互操作能力意味着服务的消费者不但不关心服务端如何实现而且也不关心服务端在采用哪种协议进行侦听。例如，如图4-2所示，在.NET平台上用C#实现的某个服务客户端可以使用REST调用对应的服务，但是服务（本例中是EJB3 Bean）只能使用RMI通信。能够将客户协议转移为服务协议的能力称作叫协议转换，是通过使用中间件组件来实现的。再重复一次，因为微服务架构没有消息中间件组件的概念，也就不支持协议无关的异构互操作能力。

图4-2 如果你发现自己所处的是异构环境，需要对多种使用不同协议的系统或者服务进行整合，那么很可能需要采用SOA架构而不是微服务架构。反过来，如果所有服务都可以通过同样远程访问协议（例如，REST）提供给客户访问，那么微服务应该是正确的选择。不论哪种情况，在选择架构模式之前，都需要充分了解互操作性需求。

合约解耦

合约解耦（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。 如果想深入了解微服务，建议参考Sam Newman的书： Building Microservices（O'Reilly）。 最后，如果想了解微服务和SOA等基于服务的架构中所涉及的消息技术，可以参看 Enterprise Messaging: JMS 1.1 and JMS 2.0 Fundamentals （O'Reilly video）和 Enterprise Messaging: Advanced Topics and Spring JMS（O'Reilly video）。 原文链接：Microservices vs. service-oriented architecture（https://www.oreilly.com/learning/microservices-vs-service-oriented-architecture#service_component_sharing，翻译：杨峰 审校：滕启明）