架构模式

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

架构模式 vs 设计模式

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

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

分层模式

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

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

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

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

端口适配器模式

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

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

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

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

管道过滤器模式

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

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

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

面向服务架构模式

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

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

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

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

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

元素

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

发布订阅模式

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

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

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

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

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

开源贡献模式

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

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

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

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

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

大泥球模式

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

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

领悟

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

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

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