前言
系统架构图是系统开发、维护和管理过程中不可或缺的工具，它可以帮助开发者更高效地进行系统设计和开发。
物理部署架构图
以下架构图是从物理部署的角度，以组件级别的颗粒度来分解系统的结构。这个系统的整体视图展示了从客户端到后端服务的完整流程，涉及使用的主要技术和框架，描述组件间的交互逻辑。不涉及功能模块、开发规范等更细节的层面。
- 服务级别：Web服务、数据库服务、任务队列服务
- 组件级别：图中显示了主要的系统组件，如Nginx、Django、数据库等。
一些观点
-
谨慎地引入组件。如无必要，勿增实体。为非必要的功能增加组件，不能带来实际收益，反而带来新的问题。
- 如果没有削峰填谷、解耦任务、支持异步需求，不要引入celery任务队列，因为会降低系统可用性（组件增多了，故障的可能性也变大了）。
-
不要超前设计
- 数据库读写变成瓶颈时，再考虑做主从同步，分库分表
-
不盲目选择新东西。微服务架构更新，但不一定比单体架构好。
- 业务体量不大、团队较小时，单体架构已经可以满足绝大需求，使用微服务反而会带来运维复杂度增高、技术门槛变高等问题。
分层架构图
整体架构是基于对用户请求流程的拆分。而选择用户请求流程的原因是因为这个流程是稳定的，不会随着公司业务的增长调整而变化。
因为架构的本质是系统中不变的那一部分，如此才能在公司业务增长和变更的时候，保持系统的稳定性和可扩展性。优秀的架构设计犹如一座建筑的地基和框架，虽然内部的装修和布局可能随时变化，但核心结构必须稳固可靠。
然后分层架构是将用户请求流程拆分成4层，每层负责不同的职责，分而治之，职责划分做到不遗漏不重叠。
- 展示层作为直接接触用户的第一层，它包含不同类型的客户端，像浏览器、桌面端、移动端。它负责处理用户输入和显示信息给用户。
- 业务层是最复杂多变的一层，包含各种业务功能。处理来自表现层的请求，执行相对具体的业务逻辑。
- 持久层是衔接了业务层和存储层，负责数据的持久化操作和管理。它将业务逻辑与具体的数据存储实现解耦，提供统一的数据访问接口。
- 存储层作为最底层，包含不同类型数据库。负责数据的物理存储和底层操作。它是整个系统的基础设施，是确保数据能够可靠、安全、高效地被存储和读取。
基于这样的分层设计是有许多优点：
分层本质是隔离关注点，这样就能让系统变得直观，容易理解，带来好处是。
- 降低开发复杂度。对应的问题只需在对应的层或者组件里解决，就只需考虑更少的逻辑，减少错乱的可能性。
- 其次是有利于分工和并行开发。一般展示层由前端负责，业务层由后端负责。分层后可以前后端并行开发，如果有多个后端，每个人负责不同的模块，让并行开发变得更容易。
- 还有一个点是可重用性更好，因为分层架构是自顶向下依赖的，低层组件可以被多个高层组件复用，就可以做到一次开发多次使用。比如说，业务层开发一个用户信息查询功能，可以在展示层的多端复用。
分层架构的另外一个优势是拓展性好。
- 因为分层之后，可以在每层中扩展组件，在组件中扩展功能。并且这个拓展的影响也会比较小，因为这个分层是自顶向下依赖的，也不会跨层依赖。就是说，只要展示层和业务层之间的接口不变，展示层的技术栈调整，不影响业务层。相同的，业务层的技术栈调整也不影响展示层。
- 并且呢，就是在业务层和存储层之间插入持久层，本质是一层抽象，如果没有这一层，那业务层需要直接sql去操作mysql数据库，当需要切换到其它数据库时（如Oracle），业务层相关代码就需要大量修改。引入持久层后，只需在持久层中增加相应数据库驱动就可以实现，而业务层无需做任何的修改。
