基于服务架构的世界

微服务和SOA都被认为是基于服务的架构，这意味着这两种架构模式都非常强调将“服务”作为其架构中的首要组件，用于实现各种功能（包括业务层面和非业务层面）。微服务和SOA是两种差异很大的架构模式，但是他们仍有一些相同的特征。

所有基于服务的架构的一个共性是他们一般都是分布式架构，也就是服务组件都是通过远程访问协议来实现的，例如REST、SOAP、AMQP、JMS、MSMQ、RMI或者.NET Remoting。相对于单体式架构和分层式架构，分布式架构有很多优势，包括可伸缩性、解耦能力以及对开发、测试和部署的可控性等。分布式架构中的组件更趋向于自包含，因此其变更管理和维护也更容易，从而使得相应的应用也更稳定，响应也更快。分布式架构也非常适用于各模块之间耦合度较低、更加模块化的应用。

在基于服务的架构语境中，“模块化”指的是将应用的各个部分分别封装为自包含的服务的做法。拆分后的每个服务都可以单独设计、开发、测试和部署，与其他组件或服务之间的依赖性很低甚至没有。模块化的架构还支持用重写的方式来维护组件的做法。随着业务增长，架构可以逐渐地、以很小的部件为单位进行重构或者替换，而不是大张旗鼓地对整个应用进行重构或者替换。

不幸的是，凡事都有代价，享受分布式系统的优点也一样。与优点相伴的缺点则是复杂性的增加和投入的增长。维护服务合约、选择正确的远程访问协议、处理不响应的或不可用的服务、加密远程服务和管理分布式事务，这些还只是构造基于服务的架构时许多复杂问题中的一部分。本章中，我会描述这些与基于服务的架构有关的复杂问题。

服务合约

服务合约是服务提供者（通常是远程的）和使用者（客户）之间使用合约语言（XML、JSON、Java Object等）约定数据输入和数据输出的一份协议。创建和维护服务合约是一项困难的工作，不应该被轻视或者当作补充条款。因此，服务合约的议题在基于服务的架构设计中值得特殊关注。

在基于服务的架构中，存在两种服务合约模型可供使用：基于服务的合约和客户驱动的合约。两者之间的真正差别在于合作程度。在基于服务的合约中，服务是合约的唯一拥有者，一般可以在不考虑服务客户需求情况下演化或修改合约。这种模式强迫服务的所有客户都要接受新的服务合约变更，而不管客户是否需要这些新功能。

与之相反，客户驱动的合约所基于的是服务和与服务客户之间更为密切地合作的一种关系。在这种模型下，服务拥有者和客户有很强的合作（关系），因此任何服务合约变更会充分考虑客户的需求。采用这种模型时，服务（拥有者）一般需要了解客户是谁以及每个客户都是如何使用这些服务的。客户可以对服务合约随意提出变更建议，服务方则可以根据是否影响其他客户而自行决定是否采纳。理想情况下，服务的客户向服务拥有者发起修改建议和测试用例，测试被执行时可以监测该修改是否影响其他客户。开源工具如Pact和Pacto可以帮助维护和测试这类客户驱动的合约。

服务合约的上下文中另一个重要议题是合约的版本。我们必须接受这一现实——在服务和服务客户间实现绑定的合约终究是要变化的。改变程度和范围取决于这些变更如何影响每个客户，以及合约改变后服务的向后兼容性。

合约的版本化使得启用新的、包含合约变更的服务功能时能够为仍旧使用老版本合约的客户提供向后兼容性。从开始开发之前就要为合约的版本化做出规划，即使开始你觉得不需要，到了最后一定需要，这也许是本章最重要的一条建议。有很多开源和商业版本的框架可以用来帮助管理和实施合约版本化策略，不过你也可以选择使用两项基本技术来实现自己的合约版本化策略：同质版本化和异质版本化。

同质版本化是指在同一个服务合约中使用合约版本号。图1-1中，被客户A和B同时使用的合约都用圆形（代表同一服务合约）来表现，但是其中各自包含着不同版本号。举一个简单例子，假定合约是基于XML的，用来表示某些商品的订单，采用合约版本号1.0。现在新版本1.1发布了，其中包含了额外字段用于提供当订单派送而接收人不在家的时候的交货规则。这种情况下，可以通过让新的delivery-instructions字段成为可选字段来保持向后兼容版本1.0的合约。