10.*如何做架构设计

0）基础概念：

系统与子系统：

• 关联：一群有关联的个体

• 规则：个体之间按照规则运作

• 能力：系统能力超越个体能力

• 分层：自顶向下逐层分解

• 子系统的定义和系统定义是一样的，只是观察的角度有差异。一个系统可能是另外一个更大系统的子系统。

• 举例：微信系统和微信的支付系统

• 顶层的理解(L0~L4)：一个系统的架构，只包括顶层这一个层级的架构，而不包括下属子系统层级的架构。所以微信架构，就是指微信系统这个层级的架构。当然，微信的子系统，比如支付系统，也有它自己的架构，同样只包括顶层。

模块与组件：

• 拆分角度不同
  • 从业务逻辑的角度“模块”，主要目的是职责分离；
  • 从物理部署的角度“组件”，主要目的是单元复用。

架构与框架：

• 框架关注的是“规范”（框），架构关注的是“结构”（构）。
• 架构设计的主要目的：
  • 解决软件系统复杂度带来的问题，从而设计相对应的解决方案。

1）架构设计原则：

• 概括：
  • 合适优于业界领先
  • 简单优于复杂
  • 演化优于一步到位

2) 复杂度来源：

高性能：系统运行效率高，体验好

• 核心思想：水平和垂直两个方向扩展
• 垂直维度主要是针对单台计算机，通过升级软、硬件能力实现性能提升
• 水平维度则主要针对集群系统，利用合理的任务分配与任务分解实现性能的提升。
• 垂直维度具体措施：
  • 增大内存减少I/O操作
  • 更换为固态硬盘（SSD）提升I/O访问速度
  • 使用RAID增加I/O吞吐能力
  • 置换服务器获得更多的处理器或分配更多的虚拟核
  • 升级网络接口或增加网络接口
• 水平维度具体措施：
  • 功能分解：基于功能将系统分解为更小的子系统
  • 多实例副本：同一组件重复部署到多台不同的服务器
  • 数据分割：在每台机器上都只部署一部分数据

高可用：系统无中断运行

• 核心思想：服务与数据的冗余备份与失效转移
• 计算高可用
• 存储高可用
• 高可用状态决策

可扩展：系统对业务需求、环境变化的适应能力，从而快速响应变化、降低影响

• 核心思想：按照流程、服务、功能拆分
• 正确预测变化
  • 从业务维度：对业务深入理解，对可预计的业务变化进行预测
  • 从技术维度：利用扩展性好的技术，实现对变化的封装
• 完美应对变化
  • 提炼出“变化层”和“稳定层”
  • 提炼出“抽象层”和“实现层”
• 拆分模式：
  • 面向流程拆分：分层架构
  • 面向服务拆分：SOA、微服务
  • 面向功能拆分: 微内核架构

其他考量：低成本、安全、规模

3) 4+1 视图

1. 逻辑视图
2. 处理视图
3. 开发视图
4. 物理视图
5. 场景视图

4) 4R 架构：

• Rank：顶层结构，架构是分层的
• Role：组成角色，系统包含哪些角色
• Relation：角色关系，角色之间的关系
• Rule：运作规则，角色如何协作完成系统功能
• 补充说明：

  • Rank：它是指软件架构是分层的（L0~L4），对应“系统”和“子系统”的分层关系。无论是架构设计还是画架构图，都应该采取“自顶向下，逐步细化”。

  • Role：架构设计最重要的工作之一就是将系统拆分为多个角色。最常见的微服务拆分其实就是将整体复杂的业务系统按照业务领域的方式，拆分为多个微服务，每个微服务就是系统的一个角色。

  • Relation：任何关系最后都需要代码来实现，包括连接方式（HTTP、TCP、UDP 和串口等）、数据协议（JSON、XML 和二进制等）以及具体的接口。

  • Rule：系统角色之间如何协作来完成系统功能，系统能力不是个体之和，而是通过协作产生新能力。在架构设计的时候，核心的业务场景都需要设计 Rule。

5) 4R 架构设计如何画：

1. 明确 Rank：也就是说，不要事无巨细地把一个大系统的方方面面都在一张架构图中展现出来，而应该明确你要阐述的系统所属的级别（L0～L4），然后只描述这个级别的架构信息。
2. 画出 Role：从不同的角度来分解系统，看看系统包含哪些角色，角色对应架构图中的区块、图标和节点等。
3. 画出 Relation：有了角色后，画出角色之间的关系，对应架构图中角色之间的连接线，不同的连接线可以代表不同的关系。
4. 最后画出 Rule：挑选核心场景，画出系统角色之间如何协作来完成某项具体的业务功能，对应系统序列图。

6) 常见架构图：

1. 架构划分

2. 架构绘画要点

7) 互联网的标准技术架构：

8) 架构设计流程：

1. 识别复杂度
2. 设计备选方案
3. 评估和选择备选方案
4. 详细方案设计

9）扩展：

1. 架构师如何学习新的工具

1. 如何技术选型

   • Q :“PPT 架构师”的口头禅是“细节不讨论”，一个优秀的架构师，需要对细节有多少考虑呢？

   • A：华仔学习 Elasticsearch 具体的做法是：

     1. 搭建一个单机伪集群，搭建完成后看看安装路径下的文件和目录，看看配置文件有哪些配置项，不同的配置项会有什么样的影响。
     2. 执行常用的操作，例如创建索引，插入、删除、查询文档，查看一下各种输出。
     3. 研究其基本原理，例如索引、分片、副本等，研究的时候要多思考，例如索引应该如何建，分片数量和副本数量对系统有什么影响等。
     4. 和其他类似系统对比，例如 Solr、Sphinx，研究其优点、缺点、适用场景。
     5. 模拟一个案例看看怎么应用。例如，假设我用 Elasticsearch 来存储淘宝的商品信息，我应该如何设计索引和分片。
     6. 查看业界使用的案例，思考一下别人为何这么用；看看别人测试的结果，大概了解性能范围。
     7. 如果某部分特别有兴趣或者很关键，可能去看源码，例如 Elasticsearch 的选举算法。如果确定要引入，会进行性能和可用性测试。
     8. 不建议拿到一个系统一开始就去读源码，效率太低，而且效果也不好。

2. 基本能力：

   • 架构师的沟通能力非常重要，既要说得动老板，让老板支持自己的设计决定；
   • 又要镇得住技术人员，让技术人员信服自己的设计选择；
   • 同时还要能够理解业务，结合业务不同发展阶段设计合适的架构，所以也要参与产品和项目决策

3. 基于设计方法论：

   • 架构师是基于完善的架构设计方法论的指导来进行架构设计，
   • 而技术专家更多的是基于经验进行架构设计。
   • 简单来说，即使是同样一个方案，初级架构师能够清晰地阐述架构设计的理由和原因，而技术专家可能就是因为自己曾经这样做过，或者看到别人这样做过而选择设计方案。

2. 架构师职责：

• 确定层级
• 拆解角色
• 定义关系
• 设计规则

3. 架构文档内容：

• 指明层级
• 描述角色
• 定义关系
• 展现规则

4. 如何学习架构：

• 自顶向下学习
• 角色有哪些
• 角色关系如何
• 运作规则是什么

参考资料：

• 架构脑图：https://zhimap.com/mmap/6159a37f642c480e984e9ad5d97e2489
• 高性能网络模型：https://unixism.net/2019/04/linux-applications-performance-introduction/

形象举例:

搬砖的：“头，我们要造什么？”；（做什么系统？）

工程师：“龙之梦商城”；（XXX系统，比如微博系统）

搬砖的：“图纸画出来了嘛？”；（架构是怎么设计的？）

工程师：“一楼主要以女性消费为主体、二楼以大众娱乐为主体、三楼以美食为主体”；（相当于微博系统中的各个子系统，比如评论子系统、动态子系统、消息子系统）

搬砖的：“头，说人话”；

工程师：“一楼有卖衣服、化妆品的，二楼有唱歌、看电影的，三楼有吃的”；（【模块】按照逻辑区分，比如存储数据模块、搜索模块、消息推送模块）

搬砖的：“有没有很知名的店啊？”；

工程师：“有的，一楼有香奈儿、优衣库...、二楼有好乐迪、万达影院....、三楼有海底捞、避风塘.....”；（【组件】按照物理区分，存储数据模块对应Mysql、搜索模块对应ElasticSearch、 消息推送模块对应Kafka）

搬砖的：“对了，头，商城大门有啥需要叮嘱的施工规范不？或有啥简化施工工艺的新技术嘛？”；（有框架的可以用吗？）

工程师猛吸了一口烟，把烟头扔在地上，用皮鞋左右撵了两下，缓缓从嘴里崩出四个字。

“老样子吧”。（Spring全家桶甩起来）