The Blog Logo
Innovating
Published on

架构基础知识

什么是架构

系统&子系统的概念

image-20230605225153126

样例：

image-20230605225251263

image-20230605225037840

模块可以是一个 module，一个package，一个服务

框架 vs 架构 概念

image-20230605225747112

MVC 又是框架又是架构，框架规定了 MVC是什么怎么交互（软件规范），如果按照MVC的框架去实现，那么架构就是MVC架构。

软件架构4R架构：

image-20230605230224033

角色可以是 service，子系统，组件

运动规则 -> 交互逻辑

架构应用

image-20230605231308882

如何画架构图

PPT画图

最底层的子系统会用类图画

架构图的分类

架构图的画法

4+1架构视图

逻辑视图 ：系统提供给用户的功能对应UML的class和state diagrams

处理视图：系统的处理过程，对应UML的sequence和activity diagrams

开发视图：程序员角度看系统的逻辑组成，对应UML的package diagrams

一般绘画逻辑视图和开发视图不会分开来画的

物理视图：系统工程师角度看系统的物理组成，对应UML的deployment diagrams

场景视图：用户角度看系统需要实现的需求，对应UML的use case diagrams

国内很少用4+1视图来描述架构

架构复杂度增加：1995年的系统大部分还是单体系统，现在分布式

绑定UML图：UML图画架构图存在问题

理解苦难：逻辑视图，开发视图，处理视图比较容易混淆。

image-20230605233523764

UML太丑了，除非是交给客户的标书

常见架构图介绍和画法

image-20230605233618894

为什么客户端和前端只要按模块划分？

一般客户端和前端是逻辑划分，只有模块。

业务架构

image-20230605234037046

高P：P10

业务架构图区块长短有什么意义：没有意义，让图好看。

客户端架构、前端架构

image-20230605234616401

系统架构

image-20230605234654508

三个角色，不同角色有关系。

为什么后端逻辑架构直接叫“系统架构”？

后端架构是最复杂。

image-20230605235022930

应用架构

image-20230605235315172

应用架构是系统架构的细化。应用架构可以指导开发，测试，运维。

部署架构

运维

image-20230605235601236

系统序列图

动态的架构图

image-20230605235804787

不能指导开发

系统序列图用UML序列图来华，核心功能需要画序列图。

本章节思维导图s

image-20230606000132134

什么是面向复杂度的架构设计

常见的架构设计方法论

image-20230606232253778

书籍（面向模式）

还没见过有人把这些书看完

image-20230606232413549

面向风险

image-20230606232846476

领域驱动 （整洁架构）

将领域本身的复杂度降低，实现软件的可理解，可扩展，做不出来高性能高可用的设计

image-20230606233352255

面向复杂度架构设计

为什么要做架构设计？提升开发效率，促进业务发展？为了高性能，高可用，可扩展？（可能会带来过度设计）

软件架构诞生背景：（并不是全行业的软件危机，而是大公司的）

​ 核心原因：软件系统规模增长

​ 核心特点：数据结构和算法不再是主要问题，整个系统的结构成为首要问题。

image-20230606235114191

架构设计环

image-20230606235449682

Saas是一种交付模式，不能说是一种架构

12306没有支付宝架构那么复杂，因为业务功能是比较固定的

如何做好架构设计

架构设计三原则: 合适原则，简单原则，演化原则

架构设计三原则

image-20230607001014706

合适原则

合适原则宣言：合适优于业界领先

image-20230607001352312

简单原则

简单宣言：简单优于复杂

奥卡姆剃刀：若无必要，勿增实体

复杂度：内部复杂度，外部复杂度；平衡点

image-20230607001906037

演化原则

软件系统和建筑本质的差异是什么？

  1. 软件系统是一个动态的系统，建筑是静态的
  2. 软件系统是可以演变的。（安卓系统的演变，人的演变）

演化原则：演化优于一步到位

image-20230607002239869

例子

三网合一，

image-20230607002520507

image-20230607002619987

  1. 即使是大公司，也不是有钱有人为所欲为，同样需要遵循架构三原则
  2. 目标高大上，如果没有能够落地的手段，就是空中楼阁
  3. 人多并不一定能够办大事，架构设计本质上是“精英设计”

4G时代实现了当初的项目目标。4G都是TD-LTE的制式。

违反了简单原则，

松鼠厂亿级用户平台

高瞻远瞩带来灾难

image-20230607003240605

何小鹏，现在小鹏汽车老板

image-20230607003345980

感悟 image-20230607003516398

1,2,3原则都违背

架构设计原则具体应用

  1. 设计出来的架构要满足当时的业务需求，符合团队和技术的能力水平（合适原则）
  2. 按照简单的方式来设计架构，然后不断地在实际应用过程中迭代优化（简单原则）
  3. 业务发生变化时，架构要扩展，重构，甚至重写（演化原则）

合适>简单>演化

架构设计环

image-20230607003940667

架构设计原则常见判断维度

image-20230607004056700

对于2B，按照合同一次性交付，架构设计不太要遵循演进原则（架构的重构）。如果要自己技术升级，再签合同就行。

实战-外包学生管理系统

如果没有理论，不知道如何落地。 没有理论，不会举一反三

需求介绍

学生管理

image-20230620003709554

课程管理

image-20230620003805534

考试管理

image-20230620003834238

权限管理

image-20230620003904677

架构设计分析

判断复杂度

高性能？

高可用？不要把核心数据丢了，关键时刻系统不要挂

可扩展？可理解性，可变化性

成本，安全？

备选方案1

image-20230620005045765

是微服务拆分的理念，但不是微服务的架构，微服务基础设施比较复杂，服务发现，负载均衡，API网关，CI/CD，日志，监控

备选方案2

image-20230620010108360

架构设计三原则：

合适原则：符合团队技术水平和积累；开发成本低，系统运维成本低

简单原则：不进行系统拆分，部署维护简单

演化原则：一次性交付，无需考虑太多后期演化；学校的学生数量不会发生很大变化，系统架构够用多年。

备选方案3

image-20230620010302890

Oracle

image-20230620010530512

实战-学生云平台管理

需求背景

image-20230620011809505

系统需求

image-20230620011957008

判断复杂度

image-20230620012111573

对于创业公司来说，真实情况

image-20230620012312381

备选方案1-单机房数据隔离

image-20230620012612293

微服务 可扩展 功能，性能伸缩

备选方案1-单机房服务数据双隔离

image-20230620012813954

双机房数据隔离

image-20230620012930890

双机房数据服务双隔离

image-20230620012955963

image-20230620013307538

image-20230620013348242

算钱，算时间。不要说现在是异地多活。