侵权投诉
订阅
纠错
加入自媒体

谈谈架构层级的“开闭原则”

2019-04-18 09:40
EAWorld
关注

简介:

本文是关于架构层级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字段。这一字段可以有两个值:

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

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

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原则可以在架构层级得以应用。

迪米特法则

迪米特法则(Law of Demeter)又叫作最少知识原则(Least Knowledge Principle 简称LKP),就是说一个对象应当对其他对象有尽可能少的了解。

假设,我们对现有的功能很满意,并准备添加一个新的功能:向用户发出感谢信来感谢他或她使用了我们的服务。参考发票微服务的例子,我们可以同样从数据库中获得租赁协议和用户数据。但这样的设计效率不高,因为CustomerThanking服务根本不需要用到租赁协议的内容。事实上,这也违反了“迪米特法则”,而我们希望所有的系统都是符合良好的架构实现的。

谈谈架构层级的“开闭原则”

也许我们可以这样,变更RentalAgreementsSaved主题的消息内容,添加一个“CustomerID”字段,JSON格式数据如下:

{"Status":"Closed","RentalAgreementID":1234,"CustomerID":8965}

呃,等等,不是说好了要应用OCP原则的么,怎么能变更消息内容呢。看来还真是这样,好吧,我们得想想别的办法。

1  2  下一页>  
声明: 本文由入驻维科号的作者撰写,观点仅代表作者本人,不代表OFweek立场。如有侵权或其他问题,请联系举报。

发表评论

0条评论,0人参与

请输入评论内容...

请输入评论/评论长度6~500个字

您提交的评论过于频繁,请输入验证码继续

暂无评论

暂无评论

文章纠错
x
*文字标题:
*纠错内容:
联系邮箱:
*验 证 码:

粤公网安备 44030502002758号