概述：本文是关于架构层级SOLID原则的文章系列的第一篇。你有可能熟知如何在面向对象的层级遵循SOLID原则来展开类的设计，或者你也曾多次困惑这些原则否限于于系统的架构设计，关于这一点，我将尝试得出一些我的看法。在类的层级，启闭原则（the－Open－Closed－Principle，全称OCP原则）的含义是：一个类对拓展是“进”敲的，而对更改是封“紧”的，意思是说道，应当在不转变类的前提下拓展一个类的不道德。而一般来说的方式是承继和多态。

在架构层级，我们并会更改系统的一部分功能（有可能是最限于于当前架构的进程，城主进程，服务，或者微服务），而是通过追加功能的方式来适配已完成的代码。为了不对现有的部分作出更改，系统必须做几乎的解法耦。接下来的内容将探讨于事件驱动系统，并以消息队列构建服务间通信。

消息队列可以是ActiveMQ，RabbitMQ，ZeroMQ，Kafka或者其他服务，我将以Kafka的话语体系来展开叙述，如主题（Topic），发布者，订阅者者，以及类似于Kafka的多个订阅者者分享完全相同主题的能力。一、消息系统右图是一个一般用例：发布者向主题公布消息（或者事件），多个订阅者者可以从主题处取得该事件。箭头命令了通信的流向。假设发布者和订阅者者都是微服务的话，双层的圆角矩形代表某一特定微服务的多个实例。

在本例中的四个微服务：发布者，订阅者者1，订阅者者2，订阅者者n，每个微服务都有多个实例。二、明确示例荐一个明确的例子。

假设我们在一家汽车出租公司工作，并负责管理创建一个车辆的可用性系统。整个出租流程的修改视图如下：第1步，车辆出租：包括出租协议的签定和客户选车的过程。旋即能用的车辆数减半1。

第2步，客户用车：客户在一定的时间范围内用于出租的车辆。第3步，车辆交还：车辆的交还和结帐。旋即能用的车辆数特1。其中第1步和第3步都必须将出租协议入库，因此我们可以设计一个事件，RentalAgreementSaved，在留存数据时启动时。

这一事件将被存储在RentalAgreementSaved主题中。因此到目前为止，共计两个发布者向主题发送到消息，一个是CarRental微，另一个是CarCheckin微服务。下面来定义消息的内容。鉴于本主题的意图是为了密切相关出租协议的留存，因此所需的大于信息量即协议ID。

但系统的愿景是追踪车辆的可用性，最差还是设置一个Status字段。这一字段可以有两个值：激活状态。

代表客户正在用于车辆。重开状态。代表客户早已交还了车辆并展开了结帐。

本文来源：十大滚球体育app-www.0710bxg.com