云原生时代|分布式系统设计知识图谱（内含22个知识点）

咱们身处于一个充斥着分布式系统解决方案的计算机时代，不管是支付宝、微信这样顶级流量产品、仍是区块链、IOT等热门概念、抑或如火如荼的容器生态技术如Kubernetes，其背后的技术架构核心都离不开分布式系统。

为何要懂分布式架构

系统学习分布式架构设计对于技术人的成长很是关键，对于云原生开发者而言如何设计出符合云原生设计哲学的应用每每离不开分布式系统知识与方法论的运用。如何设计出高弹性、可配置、可分布、高性能、高容错、更安全、更韧性、快交付的原生应用每每是衡量开发者水准的重要参考。

而后而分布式系统是一个很大的概念，从架构设计、研发流程、运维部署、工程效率等多个角度均有很深的知识能够挖掘，学习成本和难道相对较大。近期整理了过去阅读过的一些和分布式相关书刊和文章，加上本身作分布式开发的一些的心得分享给你们，本文做为开篇，整体上给出知识概览，后续将分篇结合代码实践来进行阐述。起草仓促，水平有限，欢迎你们一块儿学习指正。

分布式系统大图

1、设计

网关模式，Gateway

功能

• 请求路由，客户端直接调用 Gateway，Gateway 负责路由转发到注册服务上
• 服务注册，后端服务将 API 注册，Gateway 负责路由

• 负载均衡，支持多种负载策略

  • round robin
  • 随机均衡算法
  • 多权重负载
  • session 粘连
  • 其它
• 安全特性，支持 HTTPS，帐户鉴权，及其它安全特性支持
• 灰度发布，能够针对服务版本或者租户等特性作灰度发布
• API 聚合，将多个后端接口聚合，减小客户端调用次数
• API 编排，经过编排来串接多个 API 完成特定业务

设计要点

• 可用性，必须保证高可用
• 扩展性，能够灵活扩展以支持特定业务好比特定业务流控
• 高性能，一般使用异步 IO 模型框架实现，好比 Java netty，Go Channel
• 安全，如加密通讯，鉴权，DDOS 防护等

• 运维

  • 应用监控，包括容量，性能，异常检测等
  • 弹性伸缩，具有高弹性能力，以低成本应对高峰值

• 架构

  • 与业务解耦合，提供扩展扩展机制好比 Plugin，Serverless 的思路支持后端业务
  • 服务隔离，能够按照后端服务划分网关，作到不一样服务使用不一样网关
  • 网关部署靠近后端，保证网络损耗最小，性能最佳

边车模式，Sidecar

价值

• 分离控制与逻辑，分离业务逻辑与路由，流控，熔断，幂等，服务发现，鉴权等控制组件

• 适用场景

  • 老系统改造扩展，Sidebar 进程与服务进程部署在同一个节点，经过网络协议通信
  • 多语言混合分布式系统扩展
  • 应用程序由多方提供

设计要点

• 标准服务协议，Sidebar 到 Service，Sidebar 到 Sidebar 协议尽量与语言解耦
• 聚合控制逻辑好比流控，熔断，幂等，重试，减小业务逻辑
• 不要使用对服务侵入的方式进行进程间通信如信号量，共享内存，优先使用本地网络通信的方式好比 TPCP 或者 HTTP

服务网格，Service Mesh

新一代微服务架构，本质是服务间通讯的基础设施层。

特色

• 应用间通信中间层
• 轻量级网络代理
• 解耦应用程序
• 应用程序无感知

主流框架

• Istio
• Linkerd

分布式锁

解决方案

• Redis分布式锁，SETNX key value PX expiretime

  • value 生成，最好全局惟一好比TraceID，可使用/dev/urandom生成
  • expiretime单位是毫秒，过时锁自动释放 ，锁持有者保证过时时间内争抢资源完成计算
• 悲观锁，先获取锁，再进行操做，吞吐量底
• 乐观锁，使用版本号方式实现，吞吐量高，可能出现锁异常，适用于多读状况
• CAS，修改共享数据源的场景能够代替分布式锁

设计要点

• 排他性，任意条件只有一个client能够获取锁
• 锁有自动释放方式，好比超时释放
• 锁必须高可用，且持久化
• 锁必须非阻塞且可重入
• 避免死锁，client最终必定能够获取锁，不存在异常状况锁没法释放的状况
• 集群容错性，集群部分机器故障，锁操做仍然可用

配置中心

• 静态配置，环境及软件启动配置
• 动态配置，运行时动态调整的配置如流控开关，熔断开关等

异步通信

• 请求响应式，发送方直接向接收方发送请求

  • 发送方主动轮询
  • 发送方注册一个回调函数，接收方处理完成后回调发送方

• 事件驱动设计（EDA）

  • 消息订阅，发送方发布消息，接收方订阅并消费消息
  • Broker 中间人，发送方向Broker发布消息，接收方向Broker订阅消息，彼此解耦,好比中间件RocketMQ

  • 事情驱动设计优点

    • 服务间依赖解除
    • 服务隔离程度高

幂等性

• 本质是一个操做，不管执行多少次，执行结果老是一致的

• 幂等核心是全局惟一ID，链路依据全局ID作幂等，依据业务复杂度能够选取多种实现方式

  • 数据库自增加ID
  • 本地生成uuid
  • Redis生产id
  • Twitter开源算法 Snowflake
• HTTP幂等性，除POST外，HEAD，GET，OPTIONS，DELETE，PUT均知足幂等

2、性能

分布式缓存

• 缓存更新模式

  • Cache Aside，经常使用模式，应用要维护缓存的失效，命中，更新等动做
  • Read/Write Through，缓存代理更新数据库操做，应用视角只有一份存储
  • Write Behind Cache，IO加速方式之一，更新操做只在内测完成，异步进行批量更新数据库

异步处理

• Push模型，中心调度，复杂度高
• Pull模型，无中心调度，复杂度底
• Push+Pull模型

数据库扩展

• 数据库分片

  • 垂直分片

    • 字段拆分，将变化频率不一样的字段拆分到不一样表

  • 水平分片

    • 哈希算法来分，数据离散度高，下降热点可能性
    • 经过时间范围分片，保证数据连续性
    • 按照业务种类划分，好比数据分类，租户分离等

  • 分片设计要点

    • 分片要预留足够空间，避免从新分片
    • 分片聚合要并行去作
    • 业务尽量不去作跨分片的事务

3、容错

系统可用性

• MTTF, Mean Time To Failure，系统平均运行多长时间才发生故障，越长越好
• MTTR,Mean Time To Recover, 故障平均修复时间，越短越好
• 可用性计算公式， Availability= MTTF /（MTTF+MTTR）

服务降级

• 下降一致性

  • 强一致性，将全部的同步一致性，切换为最终一致性，提升吞吐量
  • 弱一致性，必要时候牺牲一致性换取服务总体可靠性

• 关闭次要服务

  • 不一样应用，关闭次要应用，释放物理资源
  • 相同应用，关闭应用次要功能，更多资源给到核心功能

• 简化服务功能

  • 如简化业务流程，减小通信数据等

服务限流

• 限流目的

  • SLA保证方式之一
  • 应对突发峰刺流量，必定程度节约容量规划成本
  • 租户隔离策略之一，避免某些用户占用其它用户的资源，致使服务大范围不可用

• 限流方式

  • 服务降级
  • 服务拒绝

• 解决方案

  • 服务权重划分，多租户环境将资源按权重划分，保证重要客户的资源
  • 服务延时处理，加入服务缓冲队列延缓服务压力，用于削峰
  • 服务弹性伸缩，依赖服务监控，弹性伸缩容

• 流控算法

  • 计数器

    • 单机或者集群保存某用户某时间段请求数，达到阈值则触发流控

  • 队列算法

    • FIFO队列

      • 请求速度波动，消费速度均匀，队列满则流控

    • 权重队列

      • 按服务划分优先级队列，不一样队列权重不一样

    • 队列算法设计关键：队列长度的预设很是关键

      • 队列太长，流控未生效，服务已经被打死
      • 队列过短，流控被频繁触发，体验差

  • 漏斗算法

    • 本质上是队列+限流器实现，限流器保证消费速度均匀类TCP sync backlog
    • 转发速度均匀

  • 令牌桶

    • 中间人已恒定速率向桶里发放令牌，服务请求拿到token则开始服务，不然不处理
    • 转发速度不均匀，流量小时积累，流量大时消费

  • 动态流控

    • 实时计算服务能力如QPS，对比服务RT若是RT过大，则减小QPS

• 设计要点

  • 手动开关，主动运维和应急使用
  • 监控通知，限流发生时干系人要清楚
  • 用户感知，如返回特定错误信息（错误code/错误提示）
  • 链路标识，RPC链路加入限流标识方便上下游业务识别限流场景作不一样处理

熔断设计

• 场景

  • 过载保护，系统负载太高状况为防止故障产生，而采起的一种保护措施
  • 防止应用程序不断尝试可能会失败的操做

• 三个状态

  • Closed，闭合状态，正常状态，系统须要一个基于时间线到错误计数器，若是错误累计达到阈值则切换至Open状态
  • Open，断开状态，全部对服务对请求当即返回错误，不用调用后端服务进行计算
  • Half-Open，半开状态，容许部分请求流量进入并处理，若是请求成功则按照某种策略切换到Closed状态

• 设计要点

  • 定义触发熔断的错误类型
  • 全部触发熔断的错误请求必需要有统一的日志输出
  • 熔断机制必须有服务诊断及自动恢复能力
  • 最好为熔断机制设置手动开关用于三种状态的切换
  • 熔断要切分业务，作到业务隔离熔断

补偿事务

• CAP

  • 一致性(Consistence)、可用性(Availability)、分区容忍性(Partition Tolerance)

• BASE

  • Basic Availabillity，基本可用
  • Soft State，软状态
  • Eventual Consistency，最终一致性
• Design For Failure
• Exponential Blackoff，指数级退避

4、DevOps

部署

• 基础设施

  • 云

    • 公有云
    • 私有云
    • 混合云

  • 容器技术

    • Docker
    • Kubernetes

• 部署策略

  • 停机部署
  • 滚动部署
  • 蓝绿部署
  • 灰度部署
  • A/B 测试

配置管理

• Ansible
• Puppet
• Shippable

监控

• Nagios
• DynaTrace

CI与CD

5、工程效率

敏捷管理

• Scrum

持续集成

• Jenkins
• CodeShip

持续交付

写在最后

分布式系统在阿里巴巴经济有着普遍的应用，以笔者所在的弹性技术团队为例，当业务足够规模化后，最终面临的技术问题都是经过践行分布式系统架构的设计理念和方法轮得以解决，能够说分布式系统架构的知识与方法论是当前互联网应用规模化后的通用解决方案。

学习分布式系统设计也不是一蹴而就，须要不断汲取理论知识，而后将理论不断付诸实践，最终经过一次次的调优来将知识的价值最大化。笔者最后的建议是先理论、后实践、重实践、不妥协，所谓纸上得来终觉浅，绝知此事要躬行，与君共勉。

---

本文做者：一绿舟

阅读原文

本文为云栖社区原创内容，未经容许不得转载。