Siam博客

《架构师修炼之道》第七章--架构模式

2022-11-27

架构模式

架构模式是针对特定问题的可复用解决方案 ,通过特定的结构组合提升某方面的质量属性。

架构模式 vs 设计模式

设计模式可以提高面向对象程序的可复用性和可维护性

架构模式有所不同,定义了各种质量属性场景(包括设计属性、运行属性、感知属性)的解决方案,常常涉及软件系统的多个组件。

分层模式

分层实现了层间的低耦合与层内的高内聚,提升了可维护性。

如果想更改模块内的代码而不影响其他模块,就应该使用分层模式

优势: 提升可运维性、可移植性、可复用性、可测试性、设计阶段的可修改性,概念上比较容易实施。

劣势:从最上层到最下层,每一层都引入了额外的抽象,增加了复杂度,可能会影响性能。层数繁多和抽象泄露(leaky abstraction)可能导致开发过程非常痛苦

端口适配器模式

端口适配器模式可以确保核心业务逻辑不变,在多种环境下使用,以及在隔离其他组件(负责提供数据和事件的)的状态下进行测试

如开发的系统 运行设备较为贵重、不便(雷达、工业物联网设备),开发人员不方便每次都在真机上进行测试和开发,可以采用此模式,将数据输入源输出事件等,抽离为适配器。

开发时使用模拟适配器 ,本地模拟产生数据,进行开发测试

在真机上只需保证数据适配器的调试正确,便可轻松地不改变核心业务逻辑情况下切换适配器到真机使用

管道过滤器模式

一个过滤器负责单一的数据转换或数据操作,数据快速从一个过滤器流转到下一个过滤去。

松耦合的过滤器可以通过各种方式组合和复用,从而创建出新管道(一个业务逻辑就是一个管道,逻辑内分割为多个小步骤,每个小步骤为一个过滤器组件)

该模型多运用在数据分析和数据转换领域。

面向服务架构模式

简称SOA,用独立的组件提供特定功能的服务。各种服务在运行时整合在一起,决定了系统的行为。

  • 传统的SOA非常倚重消息总线和SOAP通信。
  • 现代的SOA则鼓励使用细粒度的微服务,用轻量级消息协议(如HTTP)进行连接。

SOA允许各个部门在其专业领域内独立工作(隐藏重要业务信息),同时这些子系统又能供外部访问

优势:提升互用性、可复用性、可伸缩性

劣势:SOA系统是分布式系统,,带有分布式计算的所有复杂性。组成部分多,集成复杂。

元素

  • 服务:可独立部署的单元,通过定义好的接口提供功能服务
  • 服务注册表:列出所有可用的服务,以便服务查找其他可用服务(服务注册发现中心)
  • 消息系统:如SOAP,REST,gRPC,异步消息

发布订阅模式

在生产者和消费者彼此不知情的情况下独立存在。 事件总线负责将发布的事件与感兴趣的订阅者连接起来。

事件总线技术的选择极大地影响系统属性。

如果有多个独立组件要访问相同的信息,就可以选用发布订阅模式。

优势: 提升可扩展性、可复用性、可测试性。根据事件总线的选择及其配置方式,还可以提升可用性、可靠性、可伸缩性

劣势:考虑到组件通信的独立性和异步性,发布订阅系统的性能很难判断,事件总线的选择决定了发布订阅系统的成败

开源贡献模式

除了开发团队负责开发架构组件,同时允许其他人为开发做贡献。

团队负责从质量和概念完整性的角度审核其他人提交的组件和更新。

当有来自多个开发团队的专家参与项目,或对某些组件存在共同依赖时,可以使用该模式。

这种模式可以进一步强化团队对组件的责任,并且事先编写风格指南、注重可测试性,限制技术选择和开发平台的选择,可以让开发人员更容易做出贡献

开源贡献模式 个人理解更多偏向于协作模型,可以与其他技术模型配合使用。

大泥球模式

其实更应该叫一种开发现象,对所有元素关系不做定义,杂乱无章。

大泥球模式的唯一优势是在短期内提升开发速度(以牺牲设计的完整性为代价)

领悟

架构师决定的不只是技术选型,还有协作模型、公司部门结构模型

比如可以采用能力中心模型,由专家团队和架构师团队组成Coc部门,为其他项目团队部门建立最佳范例、开发支持工具、提供培训等。

Coc团队不会构建和交付系统模块,也可以成立中台团队,为其他项目团队部门提供通用的能力服务,如短信中台、日志中台、Im中台等

本文链接:
版权声明: 本文由 Siam原创发布,转载请遵循《署名-非商业性使用-相同方式共享 4.0 国际 (CC BY-NC-SA 4.0)》许可协议授权
Tags: 架构

扫描二维码,分享此文章