架构模式
架构模式是针对特定问题的可复用解决方案 ,通过特定的结构组合提升某方面的质量属性。
架构模式 vs 设计模式
设计模式可以提高面向对象程序的可复用性和可维护性
架构模式有所不同,定义了各种质量属性场景(包括设计属性、运行属性、感知属性)的解决方案,常常涉及软件系统的多个组件。
分层模式
分层实现了层间的低耦合与层内的高内聚,提升了可维护性。
如果想更改模块内的代码而不影响其他模块,就应该使用分层模式
优势: 提升可运维性、可移植性、可复用性、可测试性、设计阶段的可修改性,概念上比较容易实施。
劣势:从最上层到最下层,每一层都引入了额外的抽象,增加了复杂度,可能会影响性能。层数繁多和抽象泄露(leaky abstraction)
可能导致开发过程非常痛苦
端口适配器模式
端口适配器模式可以确保核心业务逻辑不变,在多种环境下使用,以及在隔离其他组件(负责提供数据和事件的)的状态下进行测试
如开发的系统 运行设备较为贵重、不便(雷达、工业物联网设备),开发人员不方便每次都在真机上进行测试和开发,可以采用此模式,将数据输入源
、输出事件
等,抽离为适配器。
开发时使用模拟适配器
,本地模拟产生数据,进行开发测试
在真机上只需保证数据适配器
的调试正确,便可轻松地不改变核心业务逻辑情况下切换适配器到真机使用
管道过滤器模式
一个过滤器负责单一的数据转换或数据操作,数据快速从一个过滤器流转到下一个过滤去。
松耦合的过滤器可以通过各种方式组合和复用,从而创建出新管道(一个业务逻辑就是一个管道,逻辑内分割为多个小步骤,每个小步骤为一个过滤器组件)
该模型多运用在数据分析和数据转换领域。
面向服务架构模式
简称SOA,用独立的组件提供特定功能的服务。各种服务在运行时整合在一起,决定了系统的行为。
- 传统的SOA非常倚重消息总线和SOAP通信。
- 现代的SOA则鼓励使用细粒度的微服务,用轻量级消息协议(如HTTP)进行连接。
SOA允许各个部门在其专业领域内独立工作(隐藏重要业务信息),同时这些子系统又能供外部访问
优势:提升互用性、可复用性、可伸缩性
劣势:SOA系统是分布式系统,,带有分布式计算的所有复杂性。组成部分多,集成复杂。
元素
- 服务:可独立部署的单元,通过定义好的接口提供功能服务
- 服务注册表:列出所有可用的服务,以便服务查找其他可用服务(服务注册发现中心)
- 消息系统:如SOAP,REST,gRPC,异步消息
发布订阅模式
在生产者和消费者彼此不知情的情况下独立存在。 事件总线负责将发布的事件与感兴趣的订阅者连接起来。
事件总线技术的选择极大地影响系统属性。
如果有多个独立组件要访问相同的信息,就可以选用发布订阅模式。
优势: 提升可扩展性、可复用性、可测试性。根据事件总线的选择及其配置方式,还可以提升可用性、可靠性、可伸缩性
劣势:考虑到组件通信的独立性和异步性,发布订阅系统的性能很难判断,事件总线的选择决定了发布订阅系统的成败
开源贡献模式
除了开发团队负责开发架构组件,同时允许其他人为开发做贡献。
团队负责从质量和概念完整性的角度审核其他人提交的组件和更新。
当有来自多个开发团队的专家参与项目,或对某些组件存在共同依赖时,可以使用该模式。
这种模式可以进一步强化团队对组件的责任,并且事先编写风格指南、注重可测试性,限制技术选择和开发平台的选择
,可以让开发人员更容易做出贡献
开源贡献模式 个人理解更多偏向于
协作模型
,可以与其他技术模型配合使用。
大泥球模式
其实更应该叫一种开发现象,对所有元素关系不做定义,杂乱无章。
大泥球模式的唯一优势是在短期内提升开发速度(以牺牲设计的完整性为代价)
领悟
架构师决定的不只是技术选型
,还有协作模型、公司部门结构模型
比如可以采用能力中心模型
,由专家团队和架构师团队组成Coc部门,为其他项目团队部门建立最佳范例、开发支持工具、提供培训等。
Coc团队不会构建和交付系统模块,也可以成立中台团队,为其他项目团队部门提供通用的能力服务,如短信中台、日志中台、Im中台等
扫描二维码,分享此文章