软件架构风格——4+1视图、5大传统架构风格及其它风格

软件架构风格定义：

在某一特定领域中的系统组织方式和惯用模式，反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个构件有效的组织成一个完整的系统。

软件体系结构风格是描述某一特定应用领域中系统组织方式惯用模式。体系结构风格定义一个系统家族，即一个体系结构定义一个词汇表和一组约束。词汇表中包含一些构建和连接件类型，而这组约束指出系统是如何将这些构建和连接件组合起来的。

体系结构风格反映了领域中众多系统所共有的结构和语义特征，,并指导如何将各个模块和子系统有效地组织成一个完整的系统。对软件体系结构风格的研究和实践促进对设计的重用，一些经过实践证实的解决方案也可以可靠地用于解决新的问题。例如，如果某人把系统描述为"客户/服务器"模式，则不必给出设计细节，我们立刻就会明白系统是如何组织和工作的。

架构发展历程

传统的五大架构风格 和 其他新类型风格：

五大架构风格	子风格
数据流风格	批处理序列（数据一个为整体）、管道-过滤器
调用/返回风格	主程序/子程序、面向对象、层次结构
独立架构风格	进程通信、事件驱动（隐式调用）
虚拟机风格	解释器、（基于）规则的系统
仓库风格(也叫数据共享风格)	数据库系统、超文本系统、黑板系统

                      记忆方式：数（树）调（凋）独虚（须）仓（苍）

其他类型：

6、闭环控制架构：

• 适用于嵌入式系统，用于解决简单闭环控制问题
• 经典应用：空调温控、定速巡航

7、C2风格

C2架构基本规则：

• 构件和连接件都有一个顶部和一个底部
• 构件的顶部要连接到连接件的底部，构件的底部要连接到连接件的顶部，构件之间不允许直连
• 一个连接件可以喝任意数目的其他构件和连接件连接
• 当两个连接件直接连接时，必须由其中一个的底部到另一个的顶部

8、层次架构风格

 9、soa架构风格 和soa架构风格的实现方式：

SOA（Service-Oriented Architecture，面向服务的架构）

百度概念

面向服务的体系结构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。

白话概念

SOA是一种面向服务的架构 ，基于分布式架构 ，它将不同业务功能按服务进行拆分 ，并通过这些服务之间定义良好 的接口和协议联系起来。

（由调用/返回风格演进而来，一种特殊的调用/返回风格）

SOA架构

SOA是一种面向服务的架构 ，基于分布式架构 ，它将不同业务功能按服务进行拆分 ，并通过这些服务之间定义良好 的接口和协议联系起来。

9.1SOA实现方法

SOA作为一种架构设计的概念和思想，需要借助具体的技术和方法来实现。目前SOA的主流实现方法包括：Web Service、服务注册表和企业服务总线。

9.1.1Web Service

 

9.1..2 服务注册表

服务注册表(Service registry)提供一个策略执行点，在这个点上，服务可以在SOA中注册，从而可以被发现和使用。大多数商用服务注册产品支持服务注册、服务位置和服务绑定功能。
9.1.3 企业服务总线ESB

ESB(Enterprise Service Bus)将企业中各个不同的服务连接在一起。因为各个服务是异构的，没有统一的标准，各个异构系统对外提供的接口是各式各样的，SOA使用ESB来屏蔽异构系统对外提供的不同接口，以此来达到服务间高效的互联互通。

特点 ：
1、基于SOA的架构思想 ，将重复公用的功能抽取为组件 ，以服务的方式向各各系统提供服务。
2、各各系 统与服务之间采用webservice、 rpc等方式进行通信。（可以直接调用服务）
3、 ESB企业服务总线作为系统与服务之间通信的桥梁。（也可以通过将数据传输给ESB，间接调用到服务）

优点 ：
1、将重复的功能抽取为服务 ，提高开发效率 ，提高系统的可重用性、 可维护性。
2、 可以针对不同服务的特 点按需伸缩。
3、采用ESB减少系统中的接口耦合。

缺点 ：
1、系统与服务的界限模糊，会导致抽取的服务的粒度过大，系统与服务之间耦合性高。
2、 虽然使用了ESB，但是服务的接口协议不固定，种类繁多，不利于系统维护。

10、微服务架构

基于SOA架构的思想 ，为了满足移动互联网对大型项目及多客户端的需求 ，对服务层进行细粒度的拆分 ，所拆分的 每个服务只完成某个特定的业务功能 ，比如订单服务只实现订单相关的业务 ，用户服务实现用户管理相关的业务等 等 ，服务的粒度很小 ，所以称为微服务架构。

特点 ：
1、 服务层按业务拆分为一个一个的微服务。
2、微服务的职责单一。
3、微服务之间采用RESTful、 RPC等轻量级协议传输。
4、有利于采用前后端分离架构。

优点 ：
1、 服务拆分粒度更细 ，有利于资源重复利用 ，提高开发效率。
2、 可以更加精准的制定每个服务的优化方案 ，按需伸缩。
3、适用于互联网时代 ，产品迭代周期更短。

缺点 ：
1、==开发的复杂性增加 ==，因为一个业务流程需要多个微服务通过网络交互来完成。
2、微服务过多 ，服务治理成本高 ，不利于系统维护。