通过架构训练营的学习，从 4 方面获得了收获：什么架构，架构解决哪些问题，如何做好架构，怎么成为架构师。

1-什么是架构

一、架构基本概念

1. 常见概念

• 系统：有关联的个体组成，可根据某种规则运行，系统能力超越个体能力。

• 子系统：有关联的个体组成，大系统中的一部分。 

• 模块：针对系统逻辑拆分，职责分离。

• 组件：针对系统物理拆分，单元复用。

• 框架：实现了特定的软件组件规范，提供了符合规范要求的软件产品。

• 架构：软件系统的“基础结构”，实现这些结构的准则，和对这些结构的描述。

2. 4R 架构概念

• Rank：顶层结构，架构是分层的，自顶向下逐步细化。

• Role：组成角色，系统包含了哪些角色。

• Relation：角色关系。

• Rule：运作规则，角色如何协作完成系统功能。

二、架构设计方法论

1. 常见的架构设计方法论

【面向模式】

• 核心思想

• 应用经过验证的成熟架构模式，例如 MVC、Reactor 等。

• 核心问题

• 不知道什么时候用哪个模式。

• 太庞大，且比较理论化，看起来比较累。

【面向风险】

• 核心思想

• 根据系统风险大小来设计软件架构。

• 核心问题

• 风险是一种概率预判，不好把握。

• 建模部分的内容本质是面向对象设计的建模过程

【领域驱动】

• 核心思想

• 通过领域建模来完成架构设计和代码设计。

• 核心问题

• 只关注业务，不关注存储和计算。

• 是可扩展架构的设计技巧，不是架构方法论。

• 兼顾架构设计和方案设计，容易混淆。

2. 架构设计体系

【编程领域】

• 指导思想：面向对象，面向过程

• 设计原则：SOLID，DRY

• 成熟模式：设计模式，重构

• 实施流程：软件工程，敏捷开发

现实：面向 Github，面向 Stackoverflow

【架构领域】

• 指导思想：面向模式，面向风险，领域驱动，面向复杂度

• 设计原则：架构设计三原则 

• 成熟模式：高性能架构，高可用架构，可扩展架构

• 实施流程：架构设计四步骤

现实：面向大厂，面向老板，面向新技术

三、架构图分类

1. 4+1 架构视图

• 场景视图：用户角度看系统需要实现的需求，对应 UML 的用例图。

• 逻辑视图：系统提供给用户的功能，对应 UML 的类图和状态图。

• 处理视图：系统的处理过程，对应 UML 的时序图和活动图。

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

• 物理视图：系统工程师角度看系统的物理组成，对应 UML 的部署图。

2. 新架构图分类

【业务架构】

• 定义：按业务划分，描述系统对用户提供了什么业务功能，类似 4+1 视图的场景视图。

• 场景：规划/汇报/培训业务。

• 技巧：通过不同的颜色来标识业务状态。

【系统架构】

• 定义：按模块划分，又叫后端架构，或技术架构。

• 场景：整体架构设计，架构培训。

• 技巧：不同颜色标识不同角色，连接线表示关系。

【应用架构】

• 定义：按应用划分，描述后端系统由哪些应用组成。技术组件的应用架构跟系统架构相同，但是一些复杂的业务中台系统，则不相同。

• 场景：项目开发测试，部署发布，子域架构设计。

• 技巧：不同颜色标识不同角色，连接线表示关系。

【部署架构】

• 定义：按组件划分，描述后端系统具体是如何部署的，对应的 4+1 视图的物理视图。

• 场景：总体架构设计，运维规划和优化。

• 技巧：用图标代替区块。

【系统序列图】

• 定义：属于动态架构图，描述了系统的运行规则，对应的 4+1 视图的运行视图。

• 场景：核心功能有必要画系统序列图。

2-架构解决哪些问题

一、架构设计本质

1. 架构设计逻辑

• 本质：架构设计是为了降低软件系统的复杂度。

• 思路：通过分析系统需求找到系统复杂的地方，然后设计方案。

• 模式：复杂度来源包括高性能，高可用，可扩展，安全，成本等。

• 方法：分库分表，缓存，集群，分片，微服务，DDD，异地多活等。

2. 复杂度模型

• 业务复杂度：业务数量多，业务流程长，业务之间关系复杂。

• 质量复杂度：高性能，高可用，成本，安全等质量属性。

二、架构复杂度分析

1. 可扩展

【概念】

• 可扩展：系统适应变化的能力，包含可理解和可复用两个部分。

• 可伸缩：系统通过增加更多资源来提升性能的能力。

【解决可理解】

• 拆分形态

• 架构层面：微服务，分层。

• 代码层面：模块，插件，package，class。

• 拆分粒度

• 内部复杂度：可用参与人来衡量，3 人负责一个。

• 外部复杂度：可用业务流程涉及对象数量来衡量，一次请求由 5 个子系统参与。

• 先粗后细原则：把握不准，就先拆少一点，后面发现问题再继续拆分。

【解决可复用】

• 预测变化

• 时间跨度：只预测 2 年内的可能变化。例 - 接入微信支付，预测接入支付宝合适，预测接入数字钱包没必要。

• 变化方式：例 - 数据库种类变化。

• 封装变化

• 预测变化：3 次法则，预测没有把握就不要封装，等到需要的时候重构即可。

• 封装模型：规则引擎，微内核，抽象层，设计模式。 

2. 高性能

【单机高性能】

• 计算高性能

• 进程

• 多进程：进程通信。

• 多线程：线程互斥。

• 网络

• PPC / TPC：常量连接，海量请求。

• Reactor：海量连接，海量请求。

• 缓存

• 本地缓存：ehcache / oscache。

• 独立缓存：Redis。

• 存储高性能

• 存储模型

• B+Tree：读多写少，可变。

• LSM：写多读少，不可变。

【集群高性能】

• 任务分配

• 概念：将任务分配给多个服务器执行。

• 案例

• DNS / GSLB / CDN。

• Nginx / F5 / LVS。

• Memcached<sdk，代码配置，一致性 hash。

• 方式

• 运行形态：服务器<本身也是集群>，sdk。

• 配置获取：配置文件，配置中心<zk>。

• 分配规则：随机/轮询/权重，hash/负载，路由/sharding。

• 任务分解

• 概念：将服务器拆分为不同角色，不同服务器处理不同的业务。

• 任务拆分

• 任务分类：例 - 读写分离。

• 任务分段：例 - 数据库分表。

• 方式

• 运行形态：例 - 服务器<本身也是集群>，sdk。

• 配置获取：例 - 配置文件，配置中心<zk>。

• 分配规则：例 - 随机/轮询/权重，hash/负载，路由/sharding。

3. 高可用

【计算高可用】

• 任务分配

• 状态检测

• 同“集群高性能 - 任务分配"

• 任务分解

• 状态检测

• 同“集群高性能 - 任务分解"

【存储高可用】

• 数据复制

• 复制格式：命令，数据，文件

• 复制方式：同步，异步，半同步，多数同步

• 状态决策

• 独裁

• 协商

• 民主  

4. 低成本

• 要点

• 先设计架构方案，再看如何降低成本。

• 加机器是综合成本最低的架构设计方式。UNIX 哲学经济原则：宁花机器一分，不花程序员一秒。

• 案例

• 互联网超大规模集群，降低大量服务器。

• 2B 项目，节省费用增加利润；

• 优化

• 引入缓存

• 虚拟化，容器化

• 性能调优

• 采用高性能硬件

• 采用开源方案

• 创新

• NoSQL VS SQL

• SQL VS 倒排索引

• Hadoop VS MySQL

• Facebook HHVM

• 云计算/k8s 弹性集群

5. 安全性

• 要点

• 架构设计只能解决架构安全，不能解决业务安全。 

• 架构安全

• 网络隔离：防火墙

• 流量清洗：运营商服务

• 机房切换：多机房

• 业务安全

• 业务漏洞：保底限制，例：限购

• 安全漏洞：安全框架，规避 xss，SQL 注入等漏洞，例：OWASP

• 内鬼破坏：权限管控，例：Shiro，Spring Security

6. 可测试性

• 要点

• 软件系统在测试环境下能否方便的支持测试各种场景的能力。

• 是否各类场景，在测试环境都能验证。

• 架构可测试

• 全链路压测

• 行为可手动触发：手动切换主备，触发选举

• 应用可测试

• 变量可修复：MySQL SET

• 状态可见：MySQL SHOW

• 行为可手动触发：管理后台停用某个队列

7. 可维护性

• 要点

• 软件系统支持定位问题，修复问题的能力。

• 架构可维护

• 全链路跟踪

• 维护操作

• 降级

• 下线

• 切换

• 应用可维护

• 变量可修复：MySQL SET

• 状态可见：MySQL SHOW

• 行为可手动触发：管理后台停用某个队列

8. 可观测性

• 要点

• 软件系统对外展现内部状态的能力。

• 是可测试性和可维护性的基础。

• 本质上是应用输出信息，运维平台/管理平台聚合展现信息。

• 信息输出

• 日志

• API

• 命令行

• 信息展现

• 运维平台

• 管理平台：消息队列管理（上线，停用，清空，消费状态）

3-如何做好架构设计

一、架构设计原则

1. 设计三原则

【要点】

设计原则，是指导我们做出更好的设计，而不是可用的设计。

架构设计时，需要考虑项目当前的实际情况。 

• 合适原则：设计出来的架构要满足当时的业务需要，符合团队和技术的能力水平 。

• 业务：业务量级，发展速度，发展形态。

• 团队：团队规模，能力水平，投入的资源。

• 技术：已有技术体系，当前技术能力，技术成熟度。

• 简单原则：先按照简单的方式来设计架构，然后不断地在实际应用过程中迭代优化，这样成本更低，而且简单的架构在迭代也更方便。

• 演化原则：当业务发生变化时，架构要扩展、重构，甚至重写。

架构设计三原则：合适，简单，演化，其中：合适 > 简单 > 演化。

【合适】

合适优于业界领先。合适自己业务规模和团队资源的架构才是更好的。

• 资源：将军难打无兵之仗，资源决定了架构能做到什么程度。

• 时间：罗马不是一天建成的，业界领先的架构需要通过时间慢慢积累演化和发展起来的。

• 业务：业务发展带来技术发展。

【简单】

简单优于复杂。复杂度涉及内部复杂度，外部复杂度。内部和外部复杂度需要取得平衡，考验架构师的能力。

• 可靠性：越复杂越不可靠，拆得越细，依赖方越多或依赖链路越长，越不可靠。

• 可扩展：越复杂越难扩展，拆得越细，扩展时需要修改的服务越多。

• 故障处理效率：越复杂越难处理。

【演化】

演化优于一步到位。软件系统，会随着业务和技术的发展来不段演进，不同阶段的形态和能力都不一样，很难一开始就预见到后面的业务和技术的发展，一步设计到位。

• 创造：满足当前业务需求。

• 迭代优化：修改去留。

• 重构重写：量变引起质变。

2. 案例总结

【案例一：华为三网合一项目】

• 目标高大上，但是没有落地手段，项目太复杂，时间太长，导致项目交付不了。

• 设计参与的人太多，导致效率不高。

违背了简单设计原则。

【案例二：UC 亿级用户平台项目】

• 十几个人，拆分成 40 多个子系统，项目拆分太细，导致服务排查问题困难，同时开发对接的工作量比较大。

• 运行效率和理论上的服务拆分虽然没问题，但是维护困难，导致架构质量一般。

• 团队资源不足，同时没有基础设施支撑。不符合团队当前的技术要求。

违背了合适，简单，演进三个原则。

二、架构设计阶段

1. 概览

2. 前期

【主要任务】

• 澄清不确定性

• 明确利益干系人的诉求：时间，成本，范围，质量。

• 消除冲突的诉求

• 差异需求：按影响力，点对点沟通。

• 冲突需求：开会讨论 + 领导拍板。

• 诉求优先级排序。

• 识别复杂度

• 识别核心场景。

• 明确或者预评估质量需求。

• 识别复杂度。

【工作模式】

• 与业务方交流。

• 与利益干系人交流。

【关键输出】

• 总体业务架构图。

• 核心场景流程。

3. 中期

【主要任务】

• 设计备选方案

• 头脑风暴：可选技术排列组合。

• 红线筛选：根据明确的约束限定，一票否定一些方案。

• 设计备选方案：

• 确定 Role 和 Releation，基于核心场景来设计 Rule。

• 数量 3～5 个为最佳。

• 方案有比较明显的差异。

• 常见困难

• 不知道哪些可用

• 原因：技术宽度不够。

• 技巧：平时多积累。

• 不知道能不能用

• 原因：学的太浅，或者是陷入细节。

• 技巧：记住关键指标 + 比较学习发 + 优缺点分析。

• 选择备选方案

• 360 度评估：

• 复杂度相关的维度：高性能，可扩展，可用性，成本，安全等。

• 团队技术储备。

• 明确选择标准：按评估维度的排序来筛选。

• 选择最终方案，并汇报。

【工作模式】

• 架构小组开会和写架构设计文档。

4. 后期

【主要任务】

• 细化架构

• 架构规范：提升架构落地效率

• 例：交互协议，数据格式，开发框架

• 针对 Role 和 Relation 的具体设计。

• 架构质量：提升架构落地质量

• 例：可测试性设计，可维护性设计，可观测性设计等。

• 整理架构文档

• 第一部分

• 业务背景：解决什么问题，带来什么价值？

• 约束限制：明确无需设计的相关条件或场景。

• 第二部分

• 总体架构设计：Rank，Role，Relation。

• 详细架构设计：Rule（包括具体架构规范）。

• 第三部分

• 架构质量设计：可维护性，可测试性，可运维性，成本，安全等。

• 架构演进规划：一期，二期……

【工作模式】

• 写架构设计文档。

• 给技术团队宣讲架构。

【关键输出】

• 完整的架构设计方案。

4-怎么成为架构师

一、架构师画像

1. 岗位定位

【能力要求】

• 既懂技术，又懂业务，是技术和业务之间的桥梁。

• 需要系统学习架构方法论和技术。

程序 = 翻译 + 逻辑 + 实现

架构 = 判断 + 取舍 + 创新

【职责和发展】

• 架构师职责：确定层级，拆解角色，定义关系，设计规则。

• 架构文档内容：指明层级，描述角色，定义关系，展现规则。

• 如何学习架构：自顶向下学习，角色有哪些，角色关系如何（跟外部系统是怎么交互的），运作规则（系统内部是怎么实现功能的，比如 Redis 如何 get 操作）。

2. 能力要求

• 判断能力：把握需求复杂度，准确的分析业务需求中隐含的复杂度问题（性能，高可用，扩展性，成本，安全，开放能力）

• 业务理解力：例 - 预测钱包营销短信的点击量 20w VS 1w VS 5000

• 技术能力

• 沟通能力

• 确定性思维：消除模糊，不确定的说法和信息，例如“大量用户”应该明确为“xx 万用户”。

• 拆解能力：有足够的技术深度或宽度，设计合适的架构来解决复杂度问题

• 技术深度

• 技术宽度

• 技术广度

• 创造性思维：通过排列组合创新，得到更多的方案。

• 取舍能力：挑选合适的落地方案，决策和取舍有正确的逻辑

• 设计理念

• 说服能力

• 决断能力：例 - 小游戏平台，Native VS H5。

• 系统性思考：有逻辑和推导过程，例如 “为什么不用 Native 而要用 H5”。

二、能力模型

1. 能力模型

• 技术：深度 + 宽度（同领域） + 广度（跨领域）。

• 业务：对业务的理解。

• 管理：团队管理 + 业务管理。

2. 成长路径

• 独立自主：掌握经验/套路 + 原理 + 完成，避免大而全 + 蜻蜓点水。

• 团队专家：掌握团队技术 + 深度 + 宽度 + 子业务，避免生搬硬套，需要自主判断。

• 领域专家：掌握领域技术 + 业界技术 + 方法论（风险驱动，领域驱动，面向复杂度） + 端到端业务，避免过分依赖过往成功经验。