架构体系化 - 架构体系化文字版 - 《Architect - 架构师之路》

什么是架构
架构的目的
- 应对软件复杂度/管理复杂度
架构的分类
架构的过程
- 业务架构过程(建模)
- 系统架构过程
架构的表达
架构的演进与规划
架构评估
- 权衡取舍

什么是架构

[维基百科定义]:架构=要素+结构+连接

软件架构是有关软件整体结构与组件的抽象描述，用于指导软件系统各个方⾯的设计

[IEEE定义]:架构=组件+关系+方法

架构是系统的基本结构，这种结构体现在组件内、系统彼此间的关系、系统与环境之间的关系，以及指导系统设计与演化的原则

[概括]架构是软件系统的顶层结构

架构的目的

应对软件复杂度/管理复杂度

什么是复杂
- 难以理解
  - 规模的增长（功能增多、数据增多、系统增多导致混乱、无序、边界不清晰等）
- 难以预测
  - 客户需求的变化/不确定性的环境等
复杂的来源
- 业务的复杂
  - 业务问题域很复杂
    比如12306的售票业务
  - 流程复杂
    比如医院的门诊的就诊流程
  - 建模的复杂
    把现实的业务概念映射为系统的业务模型较复杂
- 技术的复杂
  - 高并发
  - 高性能
  - 高可用
  - 可扩展
  - 一致性
  - 成本安全
  - 分布式
- 管理端复杂
  - 多团队协作沟通、项目管理等
    架构的分类
    业界有2种架构方法,一是RUP(Rational Unified Process, Rational公司提出的软件设计框架，后被IBM收购),二是TOGAF（开放组织提出的架构标准）
    业务架构
输出
- 领域与子域
- 功能逻辑架构
- 业务流程
- 业务模型
  应用架构
输出
- 应用分层架构
- 系统拓扑架构
  系统拓扑图是指由网络节点设备和通信介质构成的网络结构图，是表现实物的连接方式的一种图形
  数据架构
输出
- ER图
- 数据流向
  技术架构
输出
- 开发架构
- 部署架构
- 功能需求解决方案
- 系统建模方案
- 非功能性需求解决方案（3高/可扩展/一致性/通用性/安全性/稳定性等)

架构的过程

业务架构过程(建模)

UML建模法
输出用例模型、业务模型
8x Flow 业务建模法
ThoughtWorks中国区CTO徐昊、首席咨询师胡浩

系统架构过程
理清业务架构后，把业务架构转换为系统架构的过程，是应用架构、数据架构、技术架构的统一过程

软件设计原则
- 单一职责原则
  - 任何一个软件模块、组件、类、函数只负责完成一个职责（或者功能）
- 开闭原则
  - 软件实体（模块、类、方法等）应该“对扩展开放、对修改关闭
- 里氏替换原则
  - 子类对象能够替换程序中父类对象出现的任何地方，并且保证原来程序的逻辑行为不变及正确性不被破坏
- 接口隔离原则
  - 客户端(使用者/调用者)不应该被强迫依赖它不需要的接口（一组API接口、单个API接口或函数）
- 依赖反转原则
  - 软件模块应该多依赖抽象而不要依赖实现
- KISS原则
  Keep it Simple and Stupid
  - 尽量保持简单
- YAGNI原则
  You Ain’t Gonna Need It
  - 不要去设计当前用不到的功能，有设计但不能过度设计
- DRY原则
  - 不要重复你自己,遵循复用性
- 最小知识原则(迪米特法则)
  Each unit should have only limited knowledge about other units: only units “closely” related to the current unit. Or: Each unit should only talk to its friends; Don’t talk to strangers.
  - 不该有直接依赖关系的类之间，不要有依赖；有依赖关系的类之间，尽量只依赖必要的接口
- 高内聚低耦合原则
  - 一个类的内部是高内聚的,与外部类的关系是低耦合的,即使两个类有依赖关系，一个类的代码改动也不会或者很少导致依赖类的代码改动
    常规复杂度解决方案
- 高性能
  - 读写
    - 缓存系统
      - 缓存一致性(缓存与DB不一致)
        
        缓存更新策略（CacheAside）
      - 缓存命中率低(影响性能)
        
        提升过期时间、优化更新策略
      - 缓存序列化与反序列化
        
        读写需要用一致的序列化方式
      - 缓存击穿(热Key失效)
        
        缓存永不过期
      - 缓存热点(缓存节点负载过高)
        
        热Key监控、热Key切分、本地缓存
      - 缓存穿透(Key不存在)
        
        缓存空数据、布隆过滤器
      - 缓存雪崩(多Key同时失效)
        
        设置不同的过期时间、多级缓存、异步刷缓存
      - 缓存抖动(网络抖动)
        
        多级缓存、有限重试、冗余请求
    - 数据镜像
      - 数据同步(主从同步)
      - 数据一致性(一主多从)
      - 读写分离
    - 数据分片(分库分表)
      - 分区策略
      - 数据访问层(中间件框架/中间件代理)
      - 数据一致性
    - CQRS
      - 服务读写分离
    - NoSQL
      - 全文搜索引擎(ES)
      - 列式数据库(HBase)
    - 异步化
      - 线程池/Future
      - 事件溯源
      - 消息中间件
    - 批量
      - 批量读
      - 批量写
    - 负载均衡
      - DNS（地域级别均衡）
      - 硬件负载均衡(F5)
      - 四层负载均衡（LVS）
      - 七层负载均衡(Nginx)
      - 网关系统
    - 边缘计算
      - IOT设备(门禁系统/共享单车)
  - 计算
    - Reactor模式
    - 无锁数据结构
    - 单写原则
    - 面向CPU缓存行（MESI）
- 高可用
  - 理论
    - CAP
      - 分布式系统只能同时满足CAP中的2个要素
    - BASE
      - 基本可用(Base Available)
      - 软状态（Soft State)
      - 最终一致性（Eventually Consistency)
  - 业务高可用
    - 服务集群
      - 同城异区(同城多机房)
      - 跨城异地(跨城多机房)
      - 跨国异地(跨国多机房)
  - 存储高可用
    - 数据副本
      - 主备复制(读写都走主、副本不提供服务)
      - 主从复制（主写从读、读写都走主)
      - 主主复制(异地多活架构)
  - 服务高可用
    - 服务拆分
      - 按功能领域拆分服务
      - 按稳定服务与变化服务拆分
        减少频繁变更带来的风险，提高服务可用性
      - 按可靠性拆分(核心与非核心)
    - 服务容错
      - 幂等设计
      - 异步设计
      - 重试设计
      - 补偿设计
      - 隔离设计
      - 限流限频
      - 降级设计
      - 熔断设计
- 一致性
  - 多副本一致性/跨系统一致性
    - 缓存在一致性
      - 优化更新策略
    - 主从同步延迟
      - 强制读主
    - 异步同步
      - 轮询+接口反查
      - MQ消息+接口反查
      - 定时任务+接口反查
  - 事物一致性
    - 流程中断问题
      - 本地事物/回滚处理
      - 分布式事物/两阶段处理
      - 重试
      - 失败补偿
      - 本地消息表
      - MQ事务消息
      - 对账
    - 并发/重复请求问题
      - 并发锁/分布式锁
      - 幂等机制(UK/Token/状态机)
    - 接口/消息乱序问题
      - 状态机
      - 全局有序队列
    - 业务逻辑问题
      - 业务对账
      - 业务补偿
        重做某业务流程、如果无法成功则进入兜底流程或应急流程。
        比如先收到了下单的邮件，过一会又收到了没有库存的致歉的邮件。
- 可扩展
  - 资源可扩展(伸缩性（Scalability)
    系统能够通过增加（或减少）⾃身资源规模的方式增强（或减少）自⼰计算事务的能力。在⽹站架构中，通常是指利用集群的方式增加服务器数量，从⽽提高系统的整体事务吞吐能⼒。
    - 水平扩展(指服务和数据的水平复制)
      - 服务无状态-扩容
      - DB一主多从
    - 垂直扩展(指拆分服务或数据)
      - 按领域拆分服务
      - 按功能拆分数据库
  - 代码设计可扩展(Expandability)
    对现有系统影响最⼩的情况下，系统功能可持续扩展或提升的能⼒。表现在系统基础设施稳定不需要经常变更，应⽤之间较少耦合，对需求变更可以敏捷响应。它是系统架构设计层面的开闭原则，对扩展开放，对修改封闭。也就说，当系统新增⼀个功能时，不需要对现有系统的结构和代码进⾏修改
    - 多态设计
    - 依赖注入
    - 面向接口而非实现编程
    - 装饰模式
    - 策略模式
    - 模板模式
    - 责任链模式
    - 状态模式
    - 拆分稳定服务与变化服务

常见架构设计模式

架构模式是一个通用的、可重用的解决方案，用于在给定上下文中的软件体系结构中经常出现的问题。架构模式与软件设计模式类似，但具有更广泛的范围[维基百科]

MVC架构

分层架构
分层思想是工业领域通用的准则

分层1.png 分层3.png

微内核架构(插件化)
微内核架构分为内核管理以及插件模块。内核管理包括插件管理、插件加载、插件通信以及业务隔离。查检模块是封装变化的业务逻辑，支持灵活快速的扩展。整体来说微内核架构最核心的思想是隔离易变与不变

微内核架构.png

事件驱动架构

事件驱动架构.png

整洁架构(洋葱架构)

洋葱架构.png

六边形架构

六边形架构.png

微服务架构

微服务V1.png

可扩展架构(组合上述架构模式)

组合架构.png

架构的表达

架构对象

架构的对象往往是现实世界的投影，或者说是对于现实世界的一个抽象，如面向对象里把事物抽象成类，或者通过一些业务的概念、系统、模块等去代表

架构意图
架构师对于系统的主观设计判断,体现在要做什么

架构视角
从⼀个或多个⻆度对软件体系架构的各个⽅面进⾏关注，它反映了了软件架构的⼀个或多个利益相关者的不同关注层面
架构视图它与架构视角有关，去做架构表达的时候你得去从不同的视角去看。你可以从老板的视角去看、可以从客户的视角去看、可以从这个产品的视角去看、可以从工程师和评委的视角去看，不同的视角得出的架构视图是不一样的

架构视图
架构对象（物）+架构意图（⼈）+架构视⻆（⻆度）决定架构视图
比如架构五视图(逻辑架构图、开发架构图、运行架构图、物理架构图、数据架构图）

架构的演进与规划

问题分析
原则
- 对于未来整体性、⻓期性、基本性问题的思考
方式
- 空间视角：宏观/中观/微观
- 时间视角：过去/现在/未来
- 技术视角：质量/效率/成本
  设定目标
原则
- 定性->（粗）定量->定量（Smart）
- 阶段里程碑事件
方式
- 解决现有问题->抽象需求->理想情况（愿景）
- 从质量/效率/成本/体验/收⼊维度设定
  对标学习
原则
- Learn from the best
- 识别盲区、发现差距
方式
- 公司内/行业内/跨行业
- 类比迁移+系统思考（看现象->看结构->看因果）
  构建全景
原则
- 对规划进⾏系统性描述，执⾏者清楚自⼰的位置
方式
- 输出全景图(脑图/架构图)
  聚焦执行
原则
- 设计全⾯、长远的行动方案
方式
- 执⾏计划:里程碑、优先级、人⼒排布
- 风险评估:技术风险与管理风险
- 贯彻执⾏:定期总结、阶段性check、及时调整
  架构评估
  权衡取舍
  参考材料1：http://www.360doc.com/content/21/0728/07/29297912_988490505.shtml
灵活性
- 系统方案是否具备很好的灵活性(能低成本应对业务未来变化的不确定性)
可扩展/可维护性
- 开发架构是否满足软件设计原则
- 如果采用了某架构模式是否遵循最佳实践
开发效率
资源消耗
- 开发资源(开发人员/开发时间)
- 硬件资源(服务器数量、存储空间)
- 单机资源(CPU/内存/网卡宽带/磁盘/电力资源)
- 上下游依赖资源(DB消耗/中间件资源消耗)
复用性
性能
- 不同方案的性能对比(QPS/TPS/RPS)
延迟与吞吐量
- 在延迟可接受的前提下，追求最大的吞吐量
可用性与一致性
- 系统方案是否能最佳平衡可用性与一致性(CAP理论)
稳定性

架构体系化文字版

什么是架构

[维基百科定义]:架构=要素+结构+连接

[IEEE定义]:架构=组件+关系+方法

[概括]架构是软件系统的顶层结构

架构的目的

应对软件复杂度/管理复杂度

架构的分类

业务架构

应用架构

数据架构

技术架构

架构的过程

业务架构过程(建模)

系统架构过程

软件设计原则

常规复杂度解决方案

常见架构设计模式

架构的表达

架构对象

架构意图

架构视角

架构视图

架构的演进与规划

问题分析

设定目标

对标学习

构建全景

聚焦执行

架构评估

权衡取舍