大家好，我是mikechen。

架构设计是架构师进阶的必备技能，而且阿里等大厂面试都会重点考察你的架构设计能力，本篇我就全面来给大家详解架构设计@mikechen

本篇已收于mikechen创作的《阿里架构师进阶专题合集》里面。

什么是架构设计

架构设计指的是：围绕着软件系统，对它的架构，进行定义、文档编写、维护和改进、并验证实现等，把这一系列活动组合起来，就是我们所说的架构设计。

如下图所示：

架构设计只是系统设计里面的一个阶段，但是架构设计却是应用建设里面的最核心环节。

为什么需要架构设计？

1. 需求让技术变复杂：做一个博客和做一个谷歌，技术复杂度不是一个等级，需要提前架构设计来整体把控；
2. 人员让技术复杂：软件开发通过是一个团队，成员水平不一样，如何有效地协作是一个很大的考验；
3. 技术本身复杂：软件项目使用的编程语言、框架、数据库、人工智能、大数据等技术，都有学习成本；
4. 要让软件稳定运行也复杂：软件开发完成上线后，充满了各种不确定性，比如云服务商可能宕机，比如明星发个微博可能造成系统瘫痪，又比如有人删库跑路了；

正因为存在以上这几个原因，我们需要架构设计去降低这些复杂性。

1. 降低开发成本：复杂系统拆分成多个相对简单的服务，使得普通程序员都可以完成，降低了人力成本；
2. 帮助组织人员高效协作：通过抽象和拆分，让开发人员可以独立完成功能模块；
3. 组织好各种技术：选择合适的编程语言、协议、框架、组件等，最高效地实现需求目标；
4. 保障服务稳定运行：利用成熟的架构方案，例如负载均衡、限流、降级、熔断等，保障服务的高可用；

架构设计六大原则

1.单一职责原则

对于类来说，一个类应该只负责一项职责，这就是单一职责原则，非常清晰。

单一职责原则的核心就是控制类的粒度大小、将对象解耦、提高其内聚性。

通常情况下， 我们应当遵守单一职责原则 。

2.接口隔离原则

接口隔离原则要求程序员尽量将臃肿庞大的接口拆分成更小的和更具体的接口，让接口中只包含客户感兴趣的方法。

客户端不应该依赖它不需要的接 口，即一个类对另一个类的依赖，应该建立在最小的接口上。

接口隔离原则和单一职责都是为了提高类的内聚性、降低它们之间的耦合性，体现了封装的思想。

但两者是不同的，主要就是2点：

• 单一职责原则主要是约束类，它针对的是程序中的实现和细节；
• 接口隔离原则主要约束接口，主要针对抽象和程序整体框架的构建。

3.依赖倒置原则

由于在软件设计中细节具有多变性，而抽象层则相对稳定，因此以抽象为基础搭建起来的架构要比以细节为基础搭建起来的架构要稳定得多。

备注：这里的抽象指的是接口或者抽象类，而细节是指具体的实现类。

所以，依赖倒置原则的核心就是要我们面向接口或者抽象编程，而不是面向细节编程(实现类编程)，这样程序可维护性高很多啊。

依赖倒置原则主要就是2点：

1）高层模块不应该依赖底层模块，二者都应该依赖其抽象；

2）抽象不应该依赖细节，细节应该依赖抽象。

4.里氏替换原则

里氏替换原则告诉我们，当使用继承时候，类 B 继承类 A 时，除添加新的方法完成新增功能外，尽量不要修改父类方法预期的行为。

里氏替换原则的重点在不影响原功能，而不是不覆盖原方法。

子类尽量不要重写父类的方法，这就是里氏替换原则的核心精髓。

5.开闭原则

开闭原则是编程中最基础、最重要的设计原则。

比如：软件中的对象（类、模块、函数等）应该对于扩展是开放的，对于修改是封闭的。

当软件需要变化时，尽量 通过扩展 软件实体的行为来实现变化，而 不是通过修改 已 有的代码来实现变化，这就是开闭原则的核心精髓。

6.迪米特法则

迪米特法则，就是一个对象应该对其他对象保持最少的了解，又叫最少知道原则，即一个类对自己依赖的类知道越少越好。

迪米特法则在于降低类之间的耦合，每个类尽量减少对其他类的依赖，尽量减少对外暴露的方法，使得功能模块独立且低耦合

架构设计模式

随着互联网的发展，软件架构从单体到分布式，到如今基础设施的变革，我们迎来了云原生时代。

随着分布式技术的成熟，微服务架构开始大行其道，在此基础上的边车服务和 servicemesh 也开始进入蓬勃发展期。

整体上架构设计模式，主要分为如下5类：

1.分层架构

分层架构，英文名layered architecture，是最常见的软件架构，也是事实上的软件标准架构。

分层架构将软件分成若干个水平层，每一层都有清晰的角色和分工，层与层之间通过接口通信。

分层架构，最常见的就是是四层结构，如下图所示：

第一层：表现层presentation：负责用户界面；

第二层：业务层business：负责实现业务逻辑；

第三层：持久层persistence：负责提供数据，比如：SQL 语句就放在这一层；

第四层：数据库database：负责保存数据，持久化重要的数据；

分层架构的优点

1）分工明确

不同技能的程序员可以分工，负责不同的层，天然适合大多数软件公司的组织架构。

2）降解系统复杂度

分层的核心目的还是为了降解系统复杂度，提高系统的健壮性和可维护性，这也就是为什么需要分层的原因。

分层架构的缺点

每一层都可以独立测试，其他层的接口通过模拟解决然而分层架构固然很好，但前提是分层合理。

扩展性差，增加需求必须依次扩展每一层，由于每一层内部是耦合的，扩展会很困难。

2.事件驱动架构

事件驱动架构，英文名Event Driven Architecture，是一个流行的分布式异步架构模式，可以用来设计规模很大的应用程序。

事件驱动架构是一种基于发布/订阅模式的消息异步通信的架构，你可以把它理解为架构层面的观察者模式。

事件驱动架构

通常，架构主要包含4种组件，如下图所示：

1）事件队列（event queue）

负责：接收事件的入口。

2）分发器（event mediator）

负责：将不同的事件分发到不同的业务逻辑单元。

是一个事件中枢处理单元，知道事件的处理流程，但不执行具体的事件业务处理逻辑，根据事件的特征对初始事件进行拆分编排为处理事件并进行分发。

3）事件通道（event channel）

负责：分发器与处理器之间的联系渠道。

是一组各自独立的组件，彼此之间没有依赖，自包含，不依赖于其他 Processor 的处理结果。

4）事件处理器（event processor）

负责：实现业务逻辑，处理完成后会发出事件，触发下一步操作。

事件驱动架构工作流程

第一步：客户端发送一个事件到事件队列event queues中，它用来将事件传送给event mediator；

第二步：Event mediator收到初始的事件后，会发送额外的一些异步事件给event channels来执行处理的每个步骤；

第三步：Event channels 既可以是消息队列，也可以是消息topic，大部分是消息topic，这样可以由多个消息处理器(event processor)处理同一个消息。

第四步：Event processors监听event channels,接收事件并处理一些业务逻辑。

事件驱动架构应用场景

典型的场景：比如在交易系统中，每个请求流程必须经过特定的步骤，如验证、订单、配送，以及通知买家等。

3.MVC架构

MVC架构是软件工程中的一种软件架构模式，它把软件系统分为三个基本的部分。

分别为：

• 模型Model
• 视图View
• 控制器Controller

主要为以上三大部分组成，如下图所示：

MVC架构优点

1）多个视图共享一个模型，大大提高代码的可重用性；

2）三个模块相互独立，改变其中一个不会影响其他两，所以依据这种设计模式，能构建良好的松耦合性的组件；

3）控制器提高了应用程序的灵活性和可控制性：控制器可以用来连接不同的模型和视图去完成用户的需求，这样控制器可以为构造应用程序提高强有力的手段。

MVC架构缺点

1）增加了系统结构和实现的复杂性

对于简单页面，严格遵循mvc，会增加结构的复杂性。

2）视图与控制器过于紧密的连接

视图与控制器是相互分离，但确实联系紧密的部件，视图没有控制器的存在，其应用是很有限的。

3）视图对模型数据的低效率访问

依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据，对未变化数据的不必要的频繁访问，也将损害操作性能。

4.微服务架构

最早一个系统业务量很小的时候，大部分Web工程的Java应用程序，打包为War包部署在一台服务器上。

比如：你正在构建一个在线商店系统，包含功能：用户、商品、下订单等功能，整体架构如下图所示：

随着业务访问量越来越大，单体应用就会出现巨大的瓶颈。

比如：

• 要修改一个地方就要将整个应用全部部署;
• 编译时间过长;
• 回归测试周期过长;
• 开发效率降低，因为所有业务都混在一起；

所以后期就会出现，按照业务为单位进行拆分，出现的微服务架构。

微服务优点

• 每个服务足够内聚，足够小，这样能聚焦一个指定的业务功能或业务需求；
• 开发效率提高，一个服务可能就是专一的只干一件事；
• 在开发阶段，或部署阶段都是独立的；
• 微服务能使用不同的语言开发；
• 微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果；
• 每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一数据库。

微服务缺点

• 分布式复杂性：在复杂程度上来说，微服务比单体建构要更为复杂些；
• 最终一致性：各个服务的团队，数据也是分散式治理，会出现不一致的问题；
• 运维复杂性：部署比单体项目复杂得多，运维更复杂；
• 测试复杂性：测试也会更复杂；

5.云架构

云架构，英文名cloud architecture，是指各项技术如何整合在一起以创建云，云是指能够抽象、汇集和共享整个网络中的可扩展资源的 IT 环境。

云被视为平台即服务（Pass），因为云提供商为用户提供了平台以及底层IT基础架构。

云架构主要解决扩展性和并发的问题，是最容易扩展的架构。

• 与传统的服务器相比，云平台可以将物理资源虚拟化为虚拟机资源池，灵活调用软硬件资源，实现对用户的按需访问；
• 而且在运行过程中根据用户并发量的不同，实时迁移虚拟机资源，一方面保证提供高质量的服务，另一方面最小化资源成本，提高CPU，内存等利用率；

这个模式主要分成两部分：

• 处理单元processing unit
• 虚拟中间件virtualized middleware

虚拟中间件又包含四个组件：

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

架构设计总结

架构设计要做好，需要大量的经验积累，不过我们可以站在巨人的肩膀上，基于成熟的架构设计方案改造，变成适合自己业务需求的架构。

1.分析需求

对产品的需求进行抽象，分析用例，了解各种用户角色和其使用的场景。

2.选择更适合的架构方案

首先选择成熟的架构设计方案，例如：微服务架构、前后端分离，还有就是要根据团队选择合适的开发语言和框架。

3.自顶向下层层细化

好的实践是自顶向下的，不过早陷入技术细节中，从整体到局部规划，设计好部署架构、分层和分模块、API设计、数据库设计等。

4.验证和优化架构设计方案

完整的架构设计方案，需要有多次的评审，充分收集各方面的反馈，反复修改后确定。

5.架构设计需要有高屋建瓴的眼光

不仅要有架构思想，还要有不同场景的架构实践，更要学习前人实践经验的总结。

架构设计是更像是一种内功，需要自我不断地修炼，以便应对各种场景下的挑战。

本篇已收于mikechen创作的《阿里架构师进阶专题合集》里面。