软件架构

首先来看看Wikipedia对软件架构的定义：

软件架构是有关软件整体结构与组件的抽象描述，用于指导大型系统各个方面的设计

本文的目的是成为一个更好的软件架构师。软件架构一般需要由软件架构师来设计。软件架构师是指那些制定高级设计决策，并确定技术标准（包括软件编程标准、工具和平台）的软件专家。软件架构师一般需要掌握以下10项技能：

• 设计

• 了解基本的设计模式

• 深入理解设计模式跟反模式

• 了解质量度量

• 学习并理解不同的技术栈

• 分析并理解使用的模式

• 保持好奇心，关注用户群

• 决策

• 分清主次

• 认清自己的能力

• 评估多种选择

• 简化

• 多方位观察解决方案

• 退一步，重新审视方案

• 分而治之

• 重构并非坏事

• 编程

• 开发人员不接受只说不做的软件架构师

• 了解开发人员的挑战和需求

• 记录

• 保持代码整洁

• 尽量生成文档

• 尽可能多记必需的东西，内容要尽可能少

• 需要了解更多的架构框架

• 沟通

• 学习如何表达你的观点

• 尽量多去做演讲

• 在不同的层级之间使用不同的沟通技巧

• 经常沟通

• 保持透明

• 要一直做好演讲的准备

• 估算

• 了解基本的项目管理原则

• 评估不了解的架构

• 平衡

• 提高质量是有代价的

• 解决矛盾

• 冲突管理

• 咨询与辅导

• 有远见

• 建立实践社区

• 进行公开会议

• 市场

• 激励并说明

• 为自己的想法而奋斗并保持执着

• 寻找盟友

• 重复并相信你的想法

架构属性

性能：指吞吐量、延迟等

可伸缩性：指系统是否能缩容或者扩容

可用性：指系统能够连续运行多长时间，一般用几个9来表示

安全性：指保证信息不会被泄露

可见性：指可调试、可仲裁、可监控、可测试的能力

可靠性：指去中心化、同城多机房，异地备份、功能可降级等

运维友好性：指健康检查、避免单点、自动恢复等

可扩展性：指可以横向扩展，添加新能力

简单性：指可理解、分层设计等降低软件复杂度的技术

架构视图

架构视图是从某一视角或某一点上看到的系统所做的简化描述，描述中涵盖了系统的某一特定方面，而省略了与此方面无关的实体。架构视图通常采用“分而治之”的方法，从不同视角分别设计，为软件架构的理解、交流和归档提供了方便。

软件架构一般来说组织成视图，如同在建筑学中的不同种类的蓝图，常见的视图有：

• 功能/逻辑视图

• 代码视图

• 开发/结构视图

• 线程视图

• 物理视图

下面我们来看看两个比较常见的视图模型。

"4+1" 模型



该模型主要包含五个主要的视图：

• 逻辑视图（Logical View）：静态信息；主要关注功能性需求，使用面向对象的方法，用类图来显示它们的逻辑关系：关联、使用、组合、继承等等；对于数据驱动程序高的应用程序，可以使用E-R图

• 开发视图（Development View）：静态信息；关注软件开发环境下实际模块的组织。可以用模块和子系统图来表达，显示“输入”和“输出”的关系。需要考虑开发难度、软件管理、重用性、通用性等；是各种活动的基础，如：需求分配、成本评估和计划、项目进度监控、软件重用性、移植性和安全性。推荐使用分层的风格来定义子系统层，每层都需要有良好的职责定义。可以使用组件图来描述

• 处理视图（Process View）：动态信息；描述逻辑架构元素之间的交互关系，考虑一些非功能性的需求，如性能、可用性等，解决并发性、分布性、系统完整性、容错性的问题。可以使用序列图、通信图、活动图等来描述

• 物理视图（Physical View）：静态信息；主要关注系统非功能性需求，如可用性、可靠性、性能和可伸缩性等。可以使用部署图等来描述

• 场景（Scenarios）：也称用例视图，“4+1”视图模型中的4个视图都是围绕着用例视图为核心的。用例视图是一种需求分析技术，通常采用用例图进行描述。用例视图确认了以下信息：

• 系统边界

• 系统用户

• 功能和场景

C4模型

C4模型的灵感来自UML跟“4+1”模型。



C4主要包含四个主要的视图：

• System Context Diagram：系统上下文图，显示了正在构建的软件系统与用户及其他软件系统之间的关系。主要受众是所有人，包括技术和非技术人员

• Container Diagram：容器图，展现了软件系统的整体形态、职责划分以及容器间的交互方式。主要受众是团队内部或外部的开发人员跟运维人员

• Component Diagram：组件图，描述了系统由哪些组件/服务组成，厘清了组件之间的关系和依赖，告诉开发者怎么去做代码的组织和构建。主要受众是内部开发人员

• Code：代码，使用类图，具体的代码细节。主要受众是内部开发人员

可以看出，"4+1“模型并没有系统上下文图，不方便查看与其他系统之间的关系；而C4模型没有动态的处理视图，只能展示系统的静态视图。因此，实际应用时可以将"4+1"模型跟C4模型组合使用，对不同的系统跟不同的受众采用不同的视图去描述你正在构建的软件系统。

常见架构

MVC（Model View Controller）

Model：模型，处理业务逻辑

Controller：控制器，与Model交互并将数据传给View

View：视图，渲染视图并将用户操作传递给Controller

优点：

• 分层，结构清晰，耦合性低

• 相比于松散的组织代码而言，MVC提高了系统的可维护性、可扩展性跟可复用性

缺点：

• 没有告诉你如何设计你的领域模型，架构最后可能会混乱不堪

• MVC与业务脱节，一旦业务复杂起来就可能很难维护

DDD（Domain Driven Design）

领域驱动设计（Domain-Driven Design，DDD）是一种通过将实现连接到持续进化的模型来满足复杂需求的软件开发方法。



DDD将软件架构设计分为战略部分和战术部分。战略部分的主要目的是识别并定义限界上下文，并且精炼核心领域；而战术部分指导你去设计、组织和实现领域服务。通俗地讲，如果应用到微服务中，那么战略部分就是指导你如何去划分服务，而战术部分则是指导你如何去组织代码。

具体还可查看：领域驱动设计（DDD）学习笔记

优点：

• 能够解决复杂的大型项目带来的可扩展性、性能、可理解性等问题

• 每个领域可以由专门的领域专家来负责，能够使领域模型更加通用

缺点：

• 比较复杂，不大适合小团队小项目

CQRS（Command Query Responsibility Segregation）



命令查询职责分离，CQRS架构的核心是将整个系统的架构分割为读和写两部分，从而方便对读写进行分开优化。CQRS本身只是一个读写分离的思想，实现方式可以多种多样。比如数据存储不分离，只在代码层面分离读写。

Command：会改变对象的状态，但不返回任何数据

Query：会返回数据，但不改变对象的状态

优点：

• 当读写模型差别较大时，能够方便分开优化

• 可以从数据驱动转到任务驱动以及事件驱动

缺点：

• 如果系统比较简单的话会加大系统复杂度

SOA（Service Oriented Architecture）

面向服务的架构（SOA）是一种IT战略，能将企业应用中的分散功能组织成基于标准的互操作服务；IT部门可快速地组合和重用这些服务，以满足业务需求



SOA的特点：

• 分布式：根据业务进行服务拆分

• 粗粒度

• 标准化的接口

• 可从企业外部访问

• 可复用

• 松耦合

• ESB：Enterprise Service Bus，企业服务总线，实现了服务接入、协议转换、内容路由等功能

优点：

• 服务可复用

• 服务间松耦合

缺点：

• 降低了系统的性能

Microservice

微服务是SOA发展出来的产物，它是一种更细粒度的SOA实现方式。

微服务是一种架构风格，不同的公司、不同的团队可能对微服务的理解会不一样，实现也会不一样。

一个微服务系统通常会有以下组件：

• 服务注册与发现

• API网关

• 分布式链路追踪

• 配置中心

• 分布式事务

优点：

• 模块化

• 服务间数据隔离

• 故障隔离

• 可伸缩性

• 技术栈的选择较灵活

• 团队规模较小

缺点：

• 难以保证不同服务之间的数据一致性

• 调试、查找问题变得困难

Hexagonal Architecture（六边形架构，Ports & Adapters Architecture）

六边形架构与传统的分层架构不同，对于六边形架构来说，业务逻辑处于核心地位，如果需要与外部系统交互，那么使用六边形架构需要定义相应的Port，通过Adapter实现了Port后再注入进来。

Ports: 接口或者抽象实现

Adapters：Ports的具体实现，对外部系统的封装

优点：

• 核心领域不依赖于具体的实现或使用的技术，Adapter修改不会影响核心业务逻辑

• 没有外部依赖，方便进行单元测试

缺点：

• 如果只是简单的CRUD应用使用六边形架构会加大复杂性，拖慢项目进度

• 业务比较简单的话也会加大复杂性

Onion Architecture



洋葱架构从六边形架构发展而来，在中间的核心业务逻辑里又引入了分层。对于洋葱架构来说，应用构建在领域模型上，里层定义接口，外层实现接口，只能外层调用里层，里层不能调用外层，并且里层感知不到外层的存在。

Domain Model：业务模型，对应DDD中的Entity、值对象等

Domain Service：核心业务逻辑

Application Service：应用的输入输出层

User Interface/Tests/Application：适配器层

优点：

• 各层职责清晰，提高了大型复杂项目的可维护性

• 结合DDD，使项目以领域模型为主

• 没有外部依赖，方便进行单元测试

缺点：

• 如果只是简单的CRUD应用使用六边形架构会加大复杂性，拖慢项目进度

• 业务比较简单的话也会加大复杂性

• 引入了DDD的思想，对技术人员的要求较高

Clean Architecture

这里为了理解Clean Architecture，首先需要了解EBI架构：

• Entity：业务对象

• Boundary：与外界的边界，对系统接口的建模

• Interactor：通过边界接受请求并操纵应用程序状态

Clean Architecture可以说是结合了EBI架构、六边形架构跟洋葱架构，主要由以下层组成：

• Entities：实体，封装了企业级的业务规则

• Use Cases：应用特有的业务规则

• Controllers/Gateways/Presenters：Adapters，具体实现

• Devices/DB/External Interfaces/UI：外部依赖

优点：

• 各层职责清晰，提高了大型复杂项目的可维护性

• 没有外部依赖，方便进行单元测试

缺点：

• 过于复杂，如果小型项目使用的话就过度设计了

• 陡峭的学习曲线，对开发人员要求过高

参考

4 + 1 Architectural View Model

C4 Model

List of System Quality Attibutes

List of software architecture styles and patterns

Architectural Pattern

Software Design Pattern

Microservices as an Evolutionary Architecture

What are our core values and practices for building software

More Testable Code with the Hexagonal Architecture

The Software Architecture Chronicles

The Clean Architecture

用于软件架构的 C4 模型

什么是架构模式和架构风格

What is a Software Architect?

架构蓝图--软件架构 "4+1" 视图模型

Reflecting architecture and domain in code

DDD, Hexagonal, Onion, Clean, CQRS, … How I put it all together

Reflecting architecture and domain in code