《架构整洁之道》第 16 章 独立性

均为原创,读架构整洁之道的笔记。

包含了部分自己的理解,包含了原书中至少70%的知识点。
完整笔记,各位老哥友链加起来吧。
我的博客地址:www.yuque.com/_huangkuan


设计良好的架构必须支持以下4

  • 系统的用例,和正常运行
  • 系统的维护
  • 系统的开发
  • 系统的部署

可以看到,正常运行,只是其中的一项

用例

用例也叫使用案例。它描述系统如何响应外界请求,每个用例会提供一个或多个场景,告知用户如何使用交互。编写用例时,应当避免技术用语,要让用户都能看懂的语言。

一个系统,应当不需要查看源码,仅查看用例,就能完整的覆盖该系统的所有功能。即用例要完整,要全。

运行

架构在支持系统运行方面,扮演着更实际的角色。架构必须能够支持,各种场景的运行,比如大数据量的访问,快速的查询等。

这意味着它的架构应该支持将其计算部分,拆分成一系列小型服务。单体模式编写的系统,之后想改架构比较难。微服务可以有更多的组合和空间。

开发

需要恰当的将系统切分为一系列的隔离良好,可独立开发的组件,才能将组件分配给不同的团队进行独立开发。

部署

一个设计良好的架构通常不会依赖成堆的脚本和配置文件,也不需要用户手动创建一堆有严格要求的目录与文件。好的架构可以让系统在构建完成之后立刻就能部署。

要做到这些也需要通过正确的划分隔离系统组件,才能实现。其中包括了主组件,它的作用是将整个系统黏合在一起,启动,连接并监控每个组件。

保留可选项

通过之前学习的一些架构原则,可以帮助我们将系统划分为一系列隔离良好的组件,这样可以长时间的为未来保留尽可能多的可选项。良好的架构设计,让系统可以在任何情况下都能做出必要的变更。

按层解耦

架构师的目的,是让系统支持其所需要的所有用例。但难点在于我们无法预知所有的用例。好在架构师知道我们要做的是一个什么样的系统。所以可以通过采用单一职责原则(SRP)共同闭包原则(CCP),隔离那些变更原因不同的部分,集成变更原因相同的部分。

比如,用户的界面变更,肯定是和业务无关的。即UI要和业务逻辑部分隔离。

比如,字段的校验逻辑,和计算用户利息的业务逻辑,也应当隔离。因为它们的变更逻辑不一样。

比如,数据库,和编程语言无关,属于技术细节。和上述的业务逻辑都无关。

这样一来,我们可以发现,一个系统,可以被分为若干个水平分层。

UI界面,代码的业务逻辑,领域普适的业务逻辑,数据库,等。

用例的解耦

对用例也需要进行细分划分,颗粒度要细。

解耦的模式

解耦对架构设计的第二个目标系统运行,有什么意义?如果用例得到了良好的隔离,那么需要高吞吐量的用例和低吞吐量的用例也就互相自然分开了。如果水平分层了,那么比如UI和数据库,就能单独部署在其他服务器上。而需要较大宽带的应用就能运行在多个实例上。比如微服务。这里不是鼓吹SOA是一种最佳的软件架构,只是有时候我们必须要把组件切割到服务这个应用层次。

开发的独立性

进行架构设计的第三个目标就是支持系统的开发。组件被高度解耦后,开发团队之间的干扰就大大减少了,能支持多团队开发,不管组织是分功能进行开发,分组件开发,分层开发,还是按照别的什么方式开发。

部署的独立性

按水平分层的解耦,还能带来部署的灵活性。比如在系统的运行中,可以热切换分层的实现和具体用例,而不会影响其他的组件。

重复

架构师经常会钻牛角尖——害怕重复。

当然,重复在这个行业一般来说都是坏事。我们有责任减少这种重复。但有些是真的重复,有些是假的重复。例如两段代码一样,但是他们走的是不同的演进路线,有着不同的变更原因和变更速率,它们就不是真正的重复

之所以讨论重复的问题,是因为我们在垂直切分系统时,这样的困惑经常出现。例如两个不同的系统,需要展示的数据大部分相同,少部分不同,这两个系统交由不同的用户使用,那么就应当分开,因为很有可能他们的变更原因和变更速率不同。

再谈解耦模式

回到解耦模式上面来,按水平和用例解耦一个系统,可以有很多方式。例如,源码层次上解耦,二进制层次上解耦(部署),也可以在执行单元层次上解耦(服务)。

源码层次

控制源码模块之间的依赖,以此达到模块的变更不会导致其他模块也需要变更和重新编译。这种解耦模式通常系统是单体结构。组件之间的通信是调用内部函数。

部署层次

我们可以控制部署单元之间的依赖关系,以此实现一个模块的变更,不会导致其他模块的重新构建部署。这种模式一般会在同一个进程中运行,但也有的会进行跨进程通讯。重要的是这种模式会解耦出很多可独立部署的单元。组件之间的通信大多还是同一进程内调用函数。

服务层次

将组件之间的依赖关系,降低到了数据结构层次,组件之间仅通过网络数据包通信。它们在源码和二进制层次上都是独立的个体。它们的变更不会影响到其他组件。比如微服务。


现在我们要问,哪个最好呢?答案是在项目早期,很难知道哪种最好,随着项目的逐渐成熟,最好的模式可能会发生变化。

服务层次解耦,一般都用微服务,但是成本太高,不仅系统资源成本高,人力成本也高。所以应当要将系统在最开始时,将解耦推进到一旦有需要,就可以随时转变为服务的程度即可。让整个程序尽量长时间保持为单体结构,以便给未来留下可选项。

上述三个层次,应当按照项目成熟度来实时推进。

一个良好的架构,应该允许一个系统从单体开始,以单一文件或项目进行部署,然后逐渐成长为互相单独部署,甚至是独立的服务或者微服务。最后还能随着情况的变化,允许系统逐渐退回到单体。

并且在上述过程中,还能保持大部分源码不受变更影响。解耦是一个可选项,大型项目部署可以采用一种模式,而在小项目中则可以采取另一种模式。

本章小结

要达到上述要求难度不小。一个系统所适用的解耦模式,可能会随着时间变化,优秀的架构师,应该能预见这一点,并且做出相应的对策。

本作品采用《CC 协议》,转载必须注明作者和本文链接
《L05 电商实战》
从零开发一个电商项目,功能包括电商后台、商品 & SKU 管理、购物车、订单管理、支付宝支付、微信支付、订单退款流程、优惠券等
《L03 构架 API 服务器》
你将学到如 RESTFul 设计风格、PostMan 的使用、OAuth 流程,JWT 概念及使用 和 API 开发相关的进阶知识。
讨论数量: 0
(= ̄ω ̄=)··· 暂无内容!

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!