写点什么

总结

作者:Geek_f3e842
  • 2022 年 5 月 15 日
  • 本文字数:5196 字

    阅读完需:约 17 分钟

通过架构训练营的学习,从 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. 成长路径
  • 独立自主:掌握经验/套路 + 原理 + 完成,避免大而全 + 蜻蜓点水。

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

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


用户头像

Geek_f3e842

关注

还未添加个人签名 2021.01.23 加入

还未添加个人简介

评论

发布
暂无评论
总结_架构实战营_Geek_f3e842_InfoQ写作社区