4+1视图
为什么架构设计需要多重视图？因为软件需求种类的复杂，以及软件架构涵盖的内容和决策过多。而架构视图是对于从某一视角看到的系统的简化描述，多重视图实现了对复杂软件系统的分而治之。
4：逻辑视图、开发视图、运行视图及物理视图。
1：场景视图。
逻辑视图：不仅关注用户可见的功能，还包括为实现用 户功能而必须提供的“辅助功能模块“；它们可能是逻辑层、功能模块等。
开发视图： 开发视图关注程序包，不仅包括要编写的源程序，还 包括可以直接使用的第三方SDK和现成框架、类库，以及开发的 系统将运行于其上的系统软件或中间件。开发视图和逻辑视图之 间可能存在一定的映射关系：比如逻辑层一般会映射到多个程序包等。
运行视图： 和开发视图的关系，开发视图一般偏重程序包在编译 时期的静态依赖关系，而这些程序运行起来之后会表现为对象、 线程、进程，运行视图比较关注的正是这些运行时单元的交互问题。
物理视图： 和运行视图的关系：运行视图特别关注目标程序的动 态执行情况，而物理视图重视目标程序的静态位置问题；物理视 图是综合考虑软件系统和整个IT系统相互影响的架构视图。
场景视图：又称用例视图，它是对最重要需求的抽象，将上述4视图连接的纽带。因此其看似多余，被归类为+1，但它驱动我们去发现架构元素，用于架构设计其他视图，以及架构设计完成后，对架构设计的使用说明和验证测试。
分层架构模式
分成架构模式将系统划分为一个层次结构。每一层都保持高度的内聚性、抽象性，只对相邻层可见，为上层提供服务，同时又利用下层的逻辑功能。多种系统的架构都采用了分层架构模式，例如Windows操作系统微内核的架构、OSI分层通信协议...
优点：层次功能清晰，开发设计目标明确，可以被标准化；各层之间高内聚、低耦合；支持拓展和重用。
缺点：难以正确的进行层次划分；不是所有的系统都能进行层次划分；多层导致系统性能下降；调试功能时，需要进行跨层调用。
管道-过滤器架构模式
将系统划分为多个加工模块，加工步骤通过过滤器实现，加工数据的传输通过管道实现。每个过滤器独立，无需共享状态，只需完成自己的任务即可。典型实现，编译器、shell程序。
优点：简单、功能模块的重用性、易于拓展和替换、并发性。
缺点：仅少部分程序可以采用管道过滤器架构模式，兼容性较弱。
插件架构模式
拓展点用接口表示，插件负责实现接口，在接口没有插件作为实现时，也可以正常运行。实例，各种与操作系统交互的应用程序。
插件：为系统提供了新功能或拓展现有功能，但不能独立运行，不依赖于应用程序。
优点：应用与插件两者之间是解耦的，应用程序需要高度的拓展性、定制性，插件的独立测试，保持了应用程序的精简。
缺点：初始过程消耗较高。插件增多后，插件管理开销提高。
Broker模式
本质上就是客户端 - 消息分发器（Broker）- 服务器
Client：需要访问远程服务的应用程序，职责：实现客户端功能，发送请求到Broker，接受响应和异常。
Client-side Proxy：联系Client和Broker，使Client调用远程服务就像调用本地的服务一样。例如：Feign简化了微服务之间的相互调用。
Broker：Broker可以被看成消息转发器。提供注册服务、提供服务API、转发消息、容错处理、Broker间信息交互、定位服务。例如：Nacos、DNS、MQ等。
Server-side Proxy：联系Server和Broker，封装特定的系统调用、通讯参数和控制信息并调用服务的实现接口。
Server：实现服务，注册自己到Broker，处理请求并返回异常。
优点：分布式的优秀解决方案。隐藏了服务器的物理地址，实现了C/S解耦。
缺点：间接调用增加了服务调用的通信开销，Broker需要容灾措施。
SOA架构模式
SOA架构模式，又称面向服务的体系结构，是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。如Nacos，controller - service - dao。这种架构模式更像是一种围绕服务编程的思想。
MVC架构模式
Model（模型）：核心功能，封装系统数据和对数据的加工。
View（视图）：将数据展示给用户，含有模型要展示的数据。
Controller（控制器）：接收输入，并对输入内容进行解释。
SpringMVC运行逻辑。
优点：模型类和用户界面分别设计，修改界面无需修改模型，实现了前后端分离。同一应用设计可以用于不同用户界面。
缺点：如果人不分离，会增加学习成本。
标签：插件,服务,Broker,视图,模式,架构 From： https://www.cnblogs.com/LimeCoder/p/17147595.html