《谈谈架构层级的“开闭原则”》阅读笔记

“对修改关闭，对扩展开放”是在设计模式课程中我学到“开闭原则”的内容，该原则对软件设计适用，也对软件架构适用。“开闭原则”其具体含义是：一个类对扩展是“开”放的，而对变更是封“闭”的，意思是说，应该在不改变类的前提下扩展一个类的行为。通常的方式是继承和多态。

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

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

 

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

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

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

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