# 前言：

这是我的架构设计学习专栏的第一篇文章，此专栏用于存放我的架构设计学习笔记，内容一部分源于网上免费资料，一部分源于gpt和我自己的理解。专栏目前免费，欢迎订阅此专栏和关注我，随着专栏内容的增多，我可能会收费，所以建议喜欢本专栏的盆友尽早订阅。

这是我的架构设计专栏地址：https://www.nowcoder.com/creation/manager/columnDetail/0ybvLm

我还有另外一个八股专栏，感兴趣的也可以订阅一下：https://www.nowcoder.com/creation/manager/columnDetail/j8ZZk0

1.  什么是架构

架构是经过系统性地思考, 权衡利弊之后在现有资源约束下的最合理决策, 最终明确的系统骨架。包括子系统, 模块, 组件. 以及他们之间协作关系, 约束规范, 指导原则。并由它来指导团队中的每个人思想层面上的一致。涉及四方面：

● 系统性思考的合理决策：比如技术选型、解决方案等。

● 明确的系统骨架：明确系统有哪些部分组成。

● 系统协作关系：各个组成部分如何协作来实现业务请求。

● 约束规范和指导原则：保证系统有序，高效、稳定运行。

因此架构师具备能力：理解业务，全局把控，选择合适技术，解决关键问题、指导研发落地实施。

2.  如果没有架构设计或设计不合理

如果没有架构设计，说明你的系统不够复杂。随着业务的增长，系统由单体应用渐进演化为分布式和微服务化。

系统整体的复杂性越来越高，技术团队可能从一个团队变成多个专业化团队。假如没有架构设计，系统定会是一个无序失控的状态，带来的问题：

3.  架构的分类

1.业务架构

业务架构是一家企业最重要的顶层设计，它主要是涉及到业务的流程，规则，边界等。如果业务架构规划设计的不合理，直接影响的就是业务的实际运转。以我们最常提的电商为例，电商业务主要由商品、仓储、订单、支付、用户、客服、购物车等业务模块组成，通过规划好用户在自己app内的业务流程，从而可以确定好各个业务模块之间如何交互。好的顶层设计有利于整体业务运转的高效，以及好的用户体验和企业人员人均价值的提升。

2.应用架构

应用架构是系统设计中很重要的一环。它主要关注的是子系统/子应用之间的关系，也包括子系统设计（尤其是交互设计），开发，部署等。

比如，国内某电商网站的应用包括网页端应用，移动端应用，后端应用，后端应用又会被拆分为若干个业务应用。通过设计好子系统/子应用本身以及他们之间的关系，企业可以更好的管理好自身的应用程序和系统，提高用户体验，降低开发人员维护/沟通协作成本，提高企业运作效率。

3.技术架构

技术架构所关注的点比较广，主要涉及到企业的技术的基础设施以及技术平台，包括软件、硬件、网络、安全、存储等。

4.数据架构

数据是企业生产活动所产生的资源，一定程度上可以说明企业运转到了怎样的程度。数据架构关注点则是企业数据的存储、处理、分析以及共享等。

4.架构设计的目的（3高+其他）

软件架构设计的目的是为了满足软件系统的需求并实现其目标。具体而言，软件架构设计有以下几个目标：

● 高并发：指系统能够处理大量同时发生的用户请求或事务。这要求系统具有良好的资源管理机制、合理的负载均衡策略、以及有效的请求派发和处理流程。高并发是评估系统在面对大规模用户访问时稳定性和承载能力的关键指标。

● 高性能：指系统响应速度快，处理效率高，能够在最短的时间内完成尽可能多的工作。高性能的实现通常涉及到算法优化、硬件升级、以及软件层面的性能调优（如使用缓存、减少IO操作、优化数据库查询等）。

● 高可用：指系统具备较高的在线时间和可用性，即使面临硬件故障、软件错误或其它不可预见的情况，也能保证服务的稳定性和连续性。高可用的实现通常包括冗余设计、故障转移、及时的数据备份和恢复等措施。

● 高扩展性：软件架构设计需要考虑系统的扩展性，即能够方便地增加新功能模块或修改已有模块，以应对需求的变化。良好的软件架构可以支持系统的快速演化和扩展，减少对现有功能的影响。

● 可维护性：软件架构设计要考虑到系统的可维护性，使得开发人员能够方便地理解和修改系统的各个部分。清晰的模块划分和良好的组织方式可以降低开发和维护的难度，减少引入错误的可能性。

● 安全性：软件架构设计要考虑系统的安全需求，确保系统的数据和功能受到充分的保护，防止未授权的访问和恶意攻击。通过合理的身份验证、权限控制和数据加密等措施，提高系统的安全性。

三高的常见实现策略

架构设计的“三高”是高并发、高性能和高可用，实现策略包括负载均衡、缓存技术和冗余设计等。这些策略旨在提升系统在面对大规模用户请求时的稳定性、响应速度以及持续运行的能力。具体如下：

1.  高并发的实现策略

a.  池化技术：使用线程池、连接池等预分配和循环使用资源，减少创建和销毁的开销，提高复用性，从而应对大量并发请求。

b.  流量漏斗：通过网关和WAF拦截非法或低优先级的流量，减轻系统的并发压力，确保核心业务能够正常运行。

c.  负载均衡：通过集群化部署和负载均衡设备如LVS和Nginx，将流量均匀分配到多个服务器上，从而提高系统承载能力。

2.  高性能的实现策略

a.  异步处理：采用消息队列、事件驱动架构，将同步操作转换为异步，避免线程阻塞，提高系统吞吐量。

b.  硬件优化：升级硬件设施，如使用更快频率的CPU、更多核的CPU、更大的内存等，来直接提升系统处理能力。

c.  缓存技术：利用多级缓存（例如浏览器缓存、服务端本地内存缓存和服务端网络内存缓存）存储热点数据，减少数据库的读取压力，提高访问性能。

3.  高可用的实现策略

a.  故障转移：当主系统出现故障时，自动切换到备用系统，确保服务的连续性。

b.  备份恢复：定期对数据进行备份，一旦发生故障，能够迅速恢复到正常状态。

c.  冗余设计：通过部署多份相同的服务实例，保证其中一部分失败时，系统仍能继续提供服务。

5.业务特点

要明白业务的特点，比如活跃用户的数量，是电商场景还是政企场景？是对外的系统还是企业内部的系统。不同的场景在可用性、安全性、扩展性、成本方面的追求不同。比如ToC的应用，更强调用户体验，而ToB的应用更强调要解决企业问题。很多时候内部应用的接口可以不需要通过api网关只在应用内部做相对简单的控制即可，如果用户量不大，一般也不需要拆分服务，这样也可以降低维护成本。

6.  架构设计过程

一个新的业务系统构建过程大致如下：业务分析 -> 基础设计 -> 各系统详细方案设计

1.  业务分析

业务分析是整个设计的最前期工作，这个阶段需要确定业务系统要解决什么样的问题，以及业务系统的目标用户有哪些。在确定下来之后，产研会将要解决的问题拆分，成为用户在业务系统上的各种各样的操作，形成一系列的用户用例，产品经理再根据用户用例，输出前期需求。

这个阶段必须要完成的是业务架构确定，以及业务系统的功能架构

2.基础设计

业务分析之后，研发部门就能明确要做的事情有哪些，这时便进入研发阶段。此时研发侧架构同学要做的事情主要如下

1、根据产品需求、业务流程拆分业务领域，这时候可以使用DDD来拆分

2、根据领域内业务，确定业务应用有哪些

3、基础技术组件选择

做完这两件事情之后，整个业务系统大概有什么业务流程，有哪些业务应用，以及业务实体就可以确定下来了。

这个阶段要确定的主要是应用架构，技术架构。很多时候，技术组件在公司或者部门级别是有规范的，这时候根据规范选择即可。

3.各系统详细方案设计

在各个应用确定之后，对应的研发同学则需要做出各个应用的详细系统设计，一般来说，一份好的系统设计应该包含的内容如下:

1、设计背景

2、用户用例

3、核心业务流程的流程图或者时序图

4、数据库实体关系

5、风险评估

6、api接口列表

7、工作量评估

4.后续维护

在各个应用开发完之后，就是维护的工作，如果是一个运行时间很长的系统，不仅仅是满足业务的需求，还有很多技术指标需要满足。常见的还有监控、日志、安全、性能，可用性等方面的需求。如果业务量上涨，则还需要考虑系统如何去扩展，关于扩展，可以参考AFK原则。

7.  AFK拆分理论

AFK原则，即AKF拆分原则，是用于系统可扩展性设计的一种方法论，旨在通过增加机器来解决容量和可用性问题。它包括X轴、Y轴和Z轴的扩展方式，分别对应不同的系统扩展维度。以下是对这一原则的具体介绍：

1. X轴扩展

• 水平复制：X轴扩展通常是指直接水平复制应用进程来扩展系统。这意味着通过运行多个实例，并使用负载均衡来分发请求，可以有效地提升系统的吞吐量和容错能力。这种方式简单且实施迅速，适用于无状态服务的扩展。
• 主从备份：在数据库等有状态服务中，X轴扩展可以通过主从备份或主备切换来实现，其中主机负责读写操作，从机则提供读操作或作为备份，以应对主机故障时的数据恢复和高可用性需求。

1. Y轴扩展

是 微服务的拆分模式，就是基于不同的业务或功能拆分。

1. Z轴扩展

是数据层的扩展，业务量激增，承载业务的集群不足以承载过大的业务数据量，就进 行数据层面的扩充。Z轴扩展通常基于请求者或用户的独特需求进行系统划分，使得划分后的子系统相互隔离但又完整。例如，可以根据地理位置、用户属性或数据特征来分配服务资源，以满足特定群体的需求。