云时代架构阅读笔记13——架构层的开闭原则

在架构层级，我们并不会变更系统的一部分功能（可能是最适用于当前架构的进程，守护进程，服务，或者微服务），而是通过新增功能的方式来复用已完成的代码。为了不对现有的部分做出变更，系统需要做到完全的解耦。接下来的内容将聚焦于事件驱动系统，并以消息队列实现服务间通信。消息队列 可以是ActiveMQ， RabbitMQ， ZeroMQ， Kafka或者其他服务，我将以Kafka的话语体系来进行描述，如主题（Topic），发布者，订阅者，以及类似Kafka的多个订阅者共享相同主题的能力。

一、消息系统

上图是一个一般用例：发布者向主题发布消息（或者事件），多个订阅者可以从主题处获得该事件。箭头指示了通信的流向。假定发布者和订阅者都是微服务的话，双层的圆角矩形代表某一特定微服务的多个实例。在本例中的四个微服务：发布者，订阅者1，订阅者2，订阅者n，每个微服务都有多个实例。

二、具体示例

举一个具体的例子。假设我们在一家汽车租赁公司工作，并负责建立一个车辆的可用性系统。整个租赁流程的简化视图如下：

第1步，车辆租赁：包含租赁协议的签订和客户选车的过程。随即可用的车辆数减1。

第2步，客户用车：客户在一定的时间范围内使用租赁的车辆。

第3步，车辆归还：车辆的归还和签到。随即可用的车辆数加1。

其中第1步和第3步都需要将租赁协议入库，因此我们可以设计一个事件，RentalAgreementSaved，在保存数据时触发。这一事件将被存储在RentalAgreementSaved主题中。因此到目前为止，共有两个发布者向主题发送消息，一个是CarRental微，另一个是CarCheckin微服务。

下面来定义消息的内容。鉴于本主题的意图是为了表征租赁协议的保存，因此所需的最小信息量即协议ID。但系统的使命是跟踪车辆的可用性，最好还是设置一个Status字段。这一字段可以有两个值：

激活状态。代表客户正在使用车辆。

关闭状态。代表客户已经归还了车辆并进行了签到。

CarRental微服务可以选用如下的JSON数据结构：

｛＂Status＂：＂Active＂，＂RentalAgreementID＂：1234｝

CarCheckin微服务对应的数据结构是：

｛＂Status＂：＂Closed＂，＂RentalAgreementID＂：1234｝

Status字段本应从数据库读取，并通过协议ID加载租赁协议，但因为我们只关心车辆的可用性，直接在JSON消息中写入协议ID更简单，性能也更好。这一点在后文还会提到。

有了消息发布者和消息的格式，我们就可以完成下面的图表：

CarAvailability微服务会对发送给RentalAgreementSaved主题的消息进行消费：如果Status是“激活状态”，就减1，如果Status是“关闭状态”，就加1。

现在已经有了能够完成既定目标的可用系统，可以计算车辆的可用性。这一系统是否可以扩展以适用其他有意义的工作？是否可以真的在此过程中应用开闭原则？

三、系统扩展

假定我们需要在租赁流程结束的时候，给客户开具发票。可以设计一个Invoicing微服务来订阅RentalAgreementsSaved主题消息（消息中附加了租赁协议的ID）。当Status是“关闭状态”时，发票微服务可以从数据库中读取租赁协议的数据，并从Customers表中读取用户数据（Customers表和RentalAgreements表是相关联的）。有了上述信息，Invoicing微服务将可以向用户提供发票。过程如下图所示：

我们扩展了系统的功能，但并没有变更系统的代码。只是利用了多个订阅者可以订阅同一个消息主题的机制。因此是的，OCP原则可以在架构层级得以应用。