互联网架构

关于互联网架构的思维导图， 互联网架构4高：据一致性 > 高可靠（高可用）> 高并发 > 高性能，一起来看、

互联网架构

• 看待互联网架构视角
  • 大型互联网公司架构演进史
  • 术与道，术：各种框架，道：理论和方法论
  • 功能性需求与非功能性需求
  • 组织架构与系统架构的关系（生产关系与生产力）
• 互联网架构4高概述
  • 据一致性 > 高可靠（高可用）> 高并发 > 高性能
  • 高并发” 与 “高性能” 的区别？
    • QPS 与 响应时间 的关系
  • 高可用 与 高可靠 的区别与联系？
    • 高可靠：减少出故障的次数 高可用：出了故障之后，减少修复时间
  • 技术理念与技术价值观
    • 不能脱离组织架构来谈业务架构和技术架构
    • 性能优化是个永无止境的事：从语言 -》编译器（解释器） -》 操作系统 -》 硬件资源
    • 技术栈一直在快速变化，永远追不上
    • 术业有专攻，不存在什么领域都精的架构师
    • 不存在包打天下的架构方法论、架构模式
    • T型人才
• 高并发
  • 高并发问题的互联网场景
  • 决高并发“读”的几个套路：
    • （1）动静分离 - 分布式文件系统与CDN
    • （2）主从
    • （3）在线/离线的分离（OLTP/OLAP的分离）
    • （4）缓存：本地缓存/中央缓存
    • （5）并发读：异步RPC
    • （6）重写轻读
  • 高并发”写“的几个套路
    • 1.数据分片 Mysql分库分表、ES的分布式索引、JDK7之前的ConcurrentHashMap、Kafka的Partition
    • 2.任务分片 CPU指令流水线、Map/Reduce、网络的1+N+M模型
    • 3. 异步 业务层面搞后台任务、异步RPC
    • 4. 批量 、Kafka的客户端批量写入、各种批量接口：KV，Mysql, 业务API、Mysql内核的多个小事务合并扣减（阿里修改的Mysql内核）
    • 5.串行化 + 异步IO Redis的单线程模型、C++开发里面多进程单线程
  • 数据库水平扩展的2大技术路线
    • 分布式数据库（Oceanbase/Tdsql/TiDB）
    • Mysql + 自己做分库分表
  • 架构设计2.0：大型分布式系统架构方法论与实践：现实世界不存在强一致，就好比物理学中没有永动机
• 高可用
  • 减少故障修复时间
  • 主要通过多副本进行容灾、Failover
• 高可靠
  • 减少故障发生次数
  • 可用手段非常多，包括但不限于下面： 容量规划与压测 限流、降级、熔断 容灾备份 完善的测试 灰度发布与回滚 变更管理 DevOps 完善的监控体系
• 高性能
• 行锁解决思路
  • 产品设计方向
  • 分批汇总处理
  • 多账号处理
• 微服务拆分方式
  • 按组织架构拆
  • 按领域模型拆（高内聚、低耦合）
  • 按读写分离拆
  • 按软件架构模式拆（高内聚、低耦合）
  • 按流量大小拆
  • 按技术复杂度拆
  • 引用GitHub前CTO的一篇文章：全面微服务是最大的架构错误！
• 常用业务架构模式与案例
  • 分层模式
    • 本质：分离“变”与“不变性” 越底层越不变，越上层越易变（类似房子：装修能经常变，但地基下面的柱子基本动不了） 越底层零部件越小，功能越单一；越上层，功能越多样 整个体系自底往上应该是一个倒三角
  • 管道-过滤器模式
    • （1）Java的Servlet规范，一个标准化的HttpRequest和HttpResponse对象，流 经各式各样的Filter，最后到达Servlet。作为一个开发者，只需要定制自己的 Filter，加入这个管道的链条上面就可以。 （2）大数据流行的Storm流式计算。 该模式的核心： （1）标准化的数据格式，每个系统见到同样的数据 （2）系统本身无状态
  • 状态机模式（协调者模式）
    • 核心：状态机存储了每条数 据的状态，根据状态来驱动 所有系统和流程
  • 业务切面
    • 例1：SSO单点登录 例2：统一权限管理
  • .规则引擎
    • 站在业务角度来看，规则其实是一个蛮抽象的词，形式很多样。 但站在技术角度来看，抽象出来，规则就是一条条的If..Then…语 句，如下所示： If x > 1 and y < 5 then z = 0 If x > 1 and y >= 5 then z = 1 If x < 1 or m = true then z = 0
  • 工作流引擎
• 建模
  • 现实世界与计算机世界
    • 计算机建模：现实问题 -> 计算机模型 （1）开发语言：所有逻辑，最终都映射成3种结构，顺序、选择、循环 （2）DB：所有数据，最终都映射成一张张2维关系表 （3）算法模型：LR，决策树，神经网络... （4）业务建模：UML 与 DDD
    • 自然语言建模 构造块：常用的几千个汉字（或者英语的10多万个单词）。 语法规则：主谓宾定状补。 构造块：加、减、乘、除、if-else、for、while…… 语法规则：程序员很熟悉，此处不再展开。 构造块：函数。 语法规则：整个系统描述成函数的层层调用 构造块：对象。 语法规则：整个系统描述成对象与对象之间的关系。 构造块：实体、值对象、领域服务、领域事件、聚合根、工厂 、仓库、限界上下文。 语法规则：“构造块”之间的联系 建模的粒度：由细到粗，逐层构建
    • 思考点之1：深刻理解专业名词 专业名词 实体/属性 Class、属性 表、字段 探讨个哲学问题，也是语言学问题：“概念”如何形成的？ 也即“实体”和“属性”的区分问题？ 例子1： 苹果和梨子的杂交问题 1棵小树苗，10年后，还是不是同1棵树？ 生物学上的物种命名？ 古希腊哲学：种加属差，属加种差
    • 思考点之2：重要信息显性化 很多时候会遇到这样的情况：一个函数写了几百行代码，里面的if-else写了很多，计 算各种业务规则。另一个人接手之后，分析了好几天，才把业务逻辑彻底理清楚。 这个问题从表面来看是代码写得不规范、要重构，把一个有几百行代码的函数拆成一 个个小的函数。从根本上来讲，就是“重要逻辑”隐藏在代码里面，没有“显性”地 表达出来。 显性化就是“命名”，“造新概念” 变量名字 函数名字 类名字 模块名字 微服务名字 设计的过程就是一个不断造新概念、不断命名的过程
  • 架构的4+1视图
    • 功能视图
      • 对于B端的复杂业务系统，往往会画用例图，但对于C端产品，往往直接 看交互设计稿或最终的UI原型图。
    • 逻辑视图
      • 系统的逻辑模块划分，数据结构、面向对象的设计方法论里面的类图、 状态图等。
    • 物理视图
      • 整个系统所在的机房、各类机器数目、机器配置和网络带宽等。
    • 开发视图
      • 代码所在的工程结构、目录结构、Jar包、动态链接库、静态链接库等。
    • 运行视图
      • 系统的多进程、多线程之间的同步。 除了4+1视图，还有一个常见的视图叫作“数据视图”，我称为5+1视图。这里涉及一个容易混淆的问题：逻辑视图和数据视图
  • 不机械套用任何一种软件方法论，取各家所长，结合实践, 形成一个实际可采纳的方法。
• 需求分析
  • 从整体上去看需求，不要一上来钻入细节：利益相关者分析、上下游分析
  • 领域知识的深刻理解，识别真需求 vs. 伪需求
  • 产品与技术的PK问题，需求的闭环性
  • 金字塔原理 - 需求的正交分解
  • 需求分析核心
    • 需求分析需要的不是计算机专业知识，而是”通识“，“哲学思维”：
    • （1）整体性/系统性看问题：点 -》线 -》 面 -》体
    • （2）看问题看本质：找到根因，识别真伪
    • （3）分清主次：主要矛盾 与 次要矛盾
    • （4）MECE原则：讲条理，讲逻辑