后端了解常见的软件架构

Posted 2021-06-29 黑黑白白君

文章目录

• 0）软件架构
• • 什么是软件架构？
  • 为什么需要软件架构？
• 1）分层架构（Layered Architecture）
• • 1.1 构成
  • 1.2 关键概念
  • • closed layer
    • *layers of isolation
  • 1.3 举例
  • 1.4 特性分析（优劣评估）
  • • 优点：
    • 缺点：
• 2）事件驱动架构（Event-Driven Architecture）
• • 2.1 构成
  • • 中介拓扑（Mediator Topology）
    • 代理拓扑（Broker Topology）
  • 2.2 特性分析（优劣评估）
  • • 优点：
    • 缺点：
• 3）微内核架构模式（microkernel architecture）
• • 3.1 构成
  • 2.2 特性分析（优劣评估）
  • • 优点：
    • 缺点：
• 4）微服务架构（microservices architecture）
• • 4.1 核心概念
  • • 服务组件（service component）
    • 分布式架构（distributed architecture）
  • 4.2 构成
  • • 基于 API REST 的拓扑（API REST-based topology）
    • 基于应用程序 REST 的拓扑（application REST-based topology）
    • 集中式消息传递拓扑（centralized messaging topology）
  • 4.3 特性分析（优劣评估）
  • • 优点：
    • 缺点：
• 5）云结构（cloud architecture）
• • 5.1 构成
  • 5.2 特性分析（优劣评估）
  • • 优点：
    • 缺点：
• 6）总结对比

---

0）软件架构

• 什么是软件架构？

  软件架构（software architecture）就是软件的基本结构。
  • 软件架构是指在一定的设计原则基础上，从不同角度对组成系统的各部分进行搭配和安排，形成系统的多个结构而组成架构。
  • 它包括该系统的各个组件，组件的外部可见属性及组件之间的相互关系。
    • 组件的外部可见属性是指其他组件对该组件所做的假设。

• 为什么需要软件架构？

  合适的架构是软件成功的最重要因素之一。
  • 缺乏正式架构的应用程序通常紧密耦合、脆弱、难以更改，并且没有清晰的前景或方向。（“Applications lacking a formal architecture are generally tightly coupled, brittle, difficult to change, and without a clear vision or direction.”）
  • 架构模式有助于定义应用程序的基本特征和行为。（“Architecture patterns help define the basic characteristics and behavior of an application.”）
    • 例如，一些架构模式适用于高度可扩展（highly scalable）的应用程序，而其他架构模式适用于高度敏捷（highly agile）的应用程序。

• 为了满足特定业务需求和目标，有必要去了解每种架构模式的特征、优势和劣势。
  （“Knowing the characteristics, strengths, and weaknesses of each architecture pattern is necessary in order to choose the one that meets your specific business needs and goals.”）
• 下面总结归纳一些常见的架构模式。

---

1）分层架构（Layered Architecture）

分层架构模式（也称为 n 层架构模式）将软件分成若干个水平层，每一层都有清晰的角色和分工，不需要知道其他层的细节，层与层之间通过接口通信。

• 这种模式是最常见的架构模式，也是大多数 Java EE 应用程序的事实标准。

1.1 构成

大多数分层架构由四个标准层组成：表示层、业务层、持久层和数据库。

• 表示层（presentation）：负责处理所有用户界面和浏览器通信逻辑（只处理表示逻辑）
• 业务层（business）：负责执行与请求相关的特定业务规则（只处理业务逻辑）
• 持久层（persistence）：提供数据，SQL 语句就放在这一层
• 数据库（database）：保存数据

1.2 关键概念

• closed layer

  架构中的每一层都是封闭的。（"each of the layers in the architecture is marked as being closed. "）

  • 封闭层意味请求必须依次通过这四层的处理，不能跳过其中任何一层。
    

不能跳过的原因在于"隔离层"这个关键概念。

• *layers of isolation

  隔离层概念意味着在架构的一个层中所做的更改通常不会影响其他层中的组件。（“The layers of isolation concept means that changes made in one layer of the architecture generally don’t impact or affect components in other layers”）
  • 避免组件之间具有许多相互依赖性，有助于软件的更新和维护。

1.3 举例

一个业务用户请求检索特定个人的客户信息：

• 黑色箭头表示请求向下流向数据库以检索客户数据
• 红色箭头表示响应向上流回到屏幕以显示数据
• 客户信息由客户数据和订单数据（客户下的订单）组成
  

1. 客户屏幕收到获取特定个人客户信息的请求，它就会将该请求转发到客户代表模块（因为该模块了解业务层中的哪些模块可以处理该请求、如何访问该模块以及它需要哪些数据）。
2. 业务层中的客户对象负责聚合业务请求所需的所有信息（在本例中为获取客户信息）。
3. 该模块调用持久层的customer dao（数据访问对象）模块获取客户数据，同时调用order dao模块获取订单信息。
4. customer dao和order dao模块依次执行 SQL 语句来检索相应的数据并将其传递回业务层中的客户对象。
5. 一旦客户对象接收到数据，它就会聚合数据并将该信息传递回客户代表，然后客户代表将该数据传递给客户屏幕以呈现给用户。

1.4 特性分析（优劣评估）

• 优点：

  • 结构简单，容易理解和开发
  • 不同技能的程序员可以分工，负责不同的层，适合大多数软件公司的组织架构
  • 每一层都可以独立测试，其他层的接口通过模拟解决
    
    

• 缺点：

  • 一旦环境变化，需要代码调整或增加功能时，通常比较麻烦和费时
  • 部署比较麻烦，即使只修改一个小地方，往往需要整个软件重新部署，不容易做持续发布
  • 软件升级时，可能需要整个服务暂停
  • 扩展性差，用户请求大量增加时，必须依次扩展每一层，由于每一层内部是耦合的，扩展会很困难

---

2）事件驱动架构（Event-Driven Architecture）

事件驱动架构模式是一种流行的分布式异步架构模式（distributed asynchronous architecture pattern），用于生成高度可扩展的应用程序。

• 事件驱动架构由高度解耦的（highly decoupled）、单一用途的（single-purpose）事件处理组件组成，这些组件异步接收和处理事件。
• 事件驱动的架构模式由两个主要拓扑组成，中介（mediator）和代理（broker）。

2.1 构成

• 中介拓扑（Mediator Topology）

  中介拓扑中有四种主要类型的架构组件：事件队列、事件中介/分发器、事件通道和事件处理器。

  

  • 事件流从客户端向事件队列发送事件开始
  • 事件队列（event queue）：接收事件的入口，用于将事件传输到分发器
  • 分发器（event mediator）：将不同的事件分发到不同的业务逻辑单元
  • 事件通道（event channel）：分发器与处理器之间的联系渠道
  • 事件处理器（event processor）：实现业务逻辑，处理完成后会发出事件，触发下一步操作

• 代理拓扑（Broker Topology）

  对于简单的项目，事件队列、分发器和事件通道，可以合为一体，整个软件就分成事件代理和事件处理器两部分。

  • 代理拓扑与中介拓扑的不同之处在于没有中央事件中介（central event mediator）。
  • 相反，消息流通过轻量级消息代理（例如 ActiveMQ、HornetQ 等）以链状方式分布在事件处理器组件之间。
    
    

  代理拓扑中有两种主要类型的架构组件：事件代理组件（broker component）和事件处理器组件（event processor component）。
  

2.2 特性分析（优劣评估）

• 优点：

  • 分布式的异步架构，事件处理器之间高度解耦，软件的扩展性好
  • 适用性广，各种类型的项目都可以用
  • 性能较好，因为事件的异步本质，软件不易产生堵塞
  • 事件处理器可以独立地加载和卸载，容易部署
    
    

• 缺点：

  • 涉及异步编程（要考虑远程通信、失去响应等情况），开发相对复杂
  • 难以支持原子性操作，因为事件通过会涉及多个处理器，很难回滚
  • 分布式和异步特性导致这个架构较难测试

---

3）微内核架构模式（microkernel architecture）

微核架构（microkernel architecture）又称为"插件架构"（plug-in architecture），指的是软件的内核相对较小，主要功能和业务逻辑都通过插件实现。

• 内核（core）通常只包含系统运行的最小功能。
• 插件则是互相独立的。
  • 插件之间的通信，应该减少到最低，避免出现互相依赖的问题。

3.1 构成

微内核架构模式由两种类型的架构组件组成：核心系统（core system）和插件模块（plug-in modules）。

• 插件模块：独立组件，包含专门的处理、附加功能和自定义代码，旨在增强或扩展核心系统以产生附加业务功能。
  • 通常，插件模块应该独立于其他插件模块，当然也可以设计需要其他插件存在的插件。
  • 重要的是将插件之间的通信保持在最低限度，以避免出现依赖性问题。
• 核心系统：需要知道哪些插件模块可用以及如何获取它们。
  • 实现这一点的一种常见方法是通过某种插件注册表。
    • 此注册表包含有关每个插件模块的信息，包括其名称、数据协定和远程访问协议详细信息（取决于插件如何连接到核心系统）。
• 插件模块可以通过多种方式连接到核心系统，包括 OSGi（开放服务网关倡议）、消息传递、Web 服务，甚至直接点对点绑定（即对象实例化）。

2.2 特性分析（优劣评估）

• 优点：

  • 良好的功能延伸性（extensibility），需要什么功能，开发一个插件即可
  • 功能之间是隔离的，插件可以独立的加载和卸载，使得它比较容易部署
  • 可定制性高，适应不同的开发需要
  • 可以渐进式地开发，逐步增加功能
    
    

• 缺点：

  • 扩展性（scalability）差，内核通常是一个独立单元，不容易做成分布式
  • 开发难度相对较高，因为涉及到插件与内核的通信，以及内部的插件登记机制

---

4）微服务架构（microservices architecture）

微服务架构（microservices architecture）是服务导向架构（service-oriented architecture，缩写 SOA）的升级。

• 每一个服务就是一个独立的部署单元（separately deployed unit）。
• 这些单元都是分布式的，互相解耦，通过远程通信协议（比如REST、SOAP）联系。

4.1 核心概念

• 服务组件（service component）

  服务组件包含一个或多个模块（例如 Java 类），它们表示单一用途的功能或大型业务应用程序的独立部分。
  • 例如，为特定城市或城镇提供天气，股票交易配置或确定汽车保险费率
    
    

• 分布式架构（distributed architecture）

  架构中的所有组件彼此完全解耦，并通过某种远程访问协议（例如，JMS、AMQP、REST、SOAP、 RMI 等）。

4.2 构成

最常见和最流行的主要有三种拓扑结构：基于 API REST 的拓扑结构、基于应用程序 REST 的拓扑结构和集中式消息传递拓扑结构。

• 基于 API REST 的拓扑（API REST-based topology）

  • 服务组件通常使用基于 REST 的接口进行访问，该接口通过单独部署的基于 Web 的 API 层实现。
  • 例如，雅虎、谷歌和亚马逊的基于云的 RESTful Web 服务（云服务）。
    

• 基于应用程序 REST 的拓扑（application REST-based topology）

  服务通过传统的网络协议或者应用协议提供，背后通常是一个多功能的应用程序，常见于企业内部。

  • 客户端请求是通过传统的基于 Web（web-based）或胖客户端的业务应用程序屏幕（fat-client business application screens），而不是通过简单的 API 层接收的。
  • 这种拓扑对于复杂度相对较低的中小型企业应用程序很常见。
    

• 集中式消息传递拓扑（centralized messaging topology）

  采用消息代理（message broker），可以实现消息队列、负载均衡、统一日志和异常处理，缺点是会出现单点失败，消息代理可能要做成集群。

  • 此拓扑使用轻量级集中式消息代理（例如 ActiveMQ、HornetQ 等）而不是使用 REST 进行远程访问。
  • 通常用于较大的业务应用程序或需要对用户界面和服务组件之间的传输层进行更复杂控制的应用程序。
  • 与前面讨论的基于 REST 的简单拓扑相比，此拓扑的优势在于高级排队机制、异步消息传递、监控、错误处理以及更好的整体负载平衡和可扩展性。
    

4.3 特性分析（优劣评估）

• 优点：

  • 扩展性好，各个服务之间低耦合
  • 容易部署，软件从单一可部署单元，被拆成了多个服务，每个服务都是可部署单元
  • 容易开发，每个组件都可以进行持续集成式的开发，可以做到实时部署，不间断地升级
  • 易于测试，可以单独测试每一个服务
    
    

• 缺点：

  • 由于强调互相独立和低耦合，服务可能会拆分得很细。这导致系统依赖大量的微服务，变得很凌乱和笨重，性能也会不佳
  • 一旦服务之间需要通信（即一个服务要用到另一个服务），整个架构就会变得复杂。
    • 典型的例子就是一些通用的 Utility 类，一种解决方案是把它们拷贝到每一个服务中去，用冗余换取架构的简单性
  • 分布式的本质使得这种架构很难实现原子性操作，交易回滚会比较困难

---

5）云结构（cloud architecture）

云结构（或者叫space-based pattern）主要解决扩展性和并发的问题，是最容易扩展的架构。

• 它的高扩展性，主要原因是没使用中央数据库，而是把数据都复制到内存中，变成可复制的内存数据单元。然后，业务处理能力封装成一个个处理单元（prcessing unit）。
  • 访问量增加，就新建处理单元；访问量减少，就关闭处理单元。
  • 由于没有中央数据库，所以扩展性的最大瓶颈消失了。
  • 由于每个处理单元的数据都在内存里，最好要进行数据持久化。

5.1 构成

此架构模式中有两个主要组件：处理单元（processing unit）和虚拟化中间件（virtualized middleware）。

• 处理单元组件（processing-unit component）：实现业务逻辑。

  • 处理单元通常包含应用程序模块（application modules），以及内存数据网格（in-memory data grid）和用于故障转移的可选异步持久存储（optional asynchronous persistence store）。
  • 它还包含一个复制引擎（data-replication engine.），虚拟化中间件使用该引擎将一个处理单元所做的数据更改复制到其他活动处理单元。
    

• 虚拟化中间件组件（virtualized-middleware component）：负责通信、保持sessions、数据复制、分布式处理、处理单元的部署。

  • 它包含控制数据同步和请求处理各个方面的组件，包括：
    • 消息中间件（Messaging Grid）：管理用户请求和session，当一个请求进来以后，决定分配给哪一个处理单元。
    • 数据中间件（Data Grid）：将数据复制到每一个处理单元，即数据同步。保证某个处理单元都得到同样的数据。
    • 处理中间件（Processing Grid）：可选，如果一个请求涉及不同类型的处理单元，该中间件负责协调处理单元。
    • 部署中间件（Deployment Manager）：负责处理单元的启动和关闭，监控负载和响应时间，当负载增加，就新启动处理单元，负载减少，就关闭处理单元。

5.2 特性分析（优劣评估）

• 优点：

  • 高负载，高扩展性
  • 动态部署
    
    

• 缺点：

  • 实现复杂，成本较高
  • 主要适合网站类应用，不合适大量数据吞吐的大型数据库应用
  • 较难测试

---

6）总结对比

架构	整体敏捷性（Overall agility）	易于部署（Ease of deployment）	可测性（Testability）	表现（Performance）	可扩展性（Scalability）	易于开发（Ease of development）
分层架构（Layered Architecture）	低	低	高	低	低	低
事件驱动架构（Event-Driven Architecture）	高	高	低	高	高	低
微内核架构模式（microkernel architecture）	高	高	高	高	低	低
微服务架构（microservices architecture）	高	高	高	低	高	高
云结构（cloud architecture）	高	高	低	高	高	低

---

【部分内容参考自】

• 《Software Architecture Patterns》：https://www.oreilly.com/content/software-architecture-patterns/
• 软件架构入门：http://www.ruanyifeng.com/blog/2016/09/software-architecture.html