阿里巴巴中台战略思想和架构 读书笔记

这是一篇关于阿里巴巴中台战略思想和架构 读书笔记的思维导图

阿里巴巴中台战略思想和架构实现

• 中台战略背景
  • “烟囱式”架构弊端
    • 重复的功能建设和维护带来的重复投资
    • 打通“烟囱式”系统间交互的集成和协作成本高昂
    • 不利于业务的沉淀和持续发展
  • 业务支持一直是企业信息中心的组织职能
    • 转变技术部门作为“业务支持”的职能位置
    • 开发对业务的下一步发展有自己的理解和看法
    • 对业务流程如何进一步优化以便更好的提升业务
    • 对企业现有的业务提出创新的想法
  • 架构改造目标
    • 框架路线必须满足至少10年的集团业务发展要求
• 中台基础-共享服务体系
  • 面向服务架构SOA-服务重用
    • 基于共享服务体系建设服务中心
  • 服务需要不断的业务滋养
  • 共享服务体系是培育业务创新的土壤
    • 培养服务中心特定领域的专家
    • 培养这些熟悉领域专家的业务创新能力
  • 赋予业务快速创新和试错能力
    • 小的前端团队优势
      • 团队协同效率最高
      • 对商机的把握更加敏锐
      • 调整方向更加快捷
      • 一旦发现正确目标，全力投入扩大战果
  • 为真正发挥大数据威力做好准备
    • 大数据项目落地存在的问题
      • 数据分布广、格式不统一、不标准
      • 缺少能基于数据有业务建模能力的专家
    • 共享服务体系的解决方法
      • 各个业务领域中心对业务数据进行了很好的规整和沉淀
      • 共享服务体系能帮忙企业培养技术+业务的大数据人才
  • 改变组织阵型会带来组织效能的提升
    • 大多数企业信息部门存在的问题
      • 停留在“业务支持”等偏事务性工作
      • 使个人能力得不到持续的提升
      • 员工的积极性与创造力被逐渐消磨
    • 共享服务体系组织优越性
      • 员工对自己擅长和感兴趣的服务中心持续运营优化
      • 员工的业务理解和专业技能使业务中心的业务能力逐步完善和提升
      • 对员工的工作积极性和创新意识的提升创造一个良好氛围
      • 服务中心的业务架构师（业务发展的领路者、核心业务的通用性与公用性的捍卫者）
• 分布式服务框架
  • 早期淘宝All-In-One框架存在的问题
    • 项目团队间协同成本高，业务响应越来越慢
    • 应用复杂度已超出人的认知负载
    • 错误难于隔离
    • 数据库的连接能力很难扩展
    • 应用扩展成本高
  • 淘宝平台服务化改造
    • 降低不同模块开发团队间的协同成本，业务响应更迅捷
    • 大大降低系统间的耦合度以及整体复杂度，各个开发团队可专注于各自的业务模块
    • 避免了个别模块的错误给整体带来的影响
    • 业务拆分后解决了对单数据库集群连接数的能力依赖
    • 做到针对性的业务能力扩展，减少不必要的资源浪费
  • 中心化与去中心化的服务框架对比
    • SOA架构的主要特性
      • 面向服务的分布式计算
      • 服务间松散耦合
      • 支持服务的组装
      • 服务注册和自动发现
      • 以服务契约方式定义服务交互方式
    • 中心化解决的根本诉求
      • 实现异构系统之间的交互
      • “烟囱式”架构的各个系统所采用的技术平台、框架、开发语言各异
      • ESB框架避免了因服务提供者接口变化需要服务调用者都修改的现象
      • ESB架构降低了系统间的耦合，更方便、高效的实现新系统的集成
    • 去中心化分布式服务架构解决的问题
      • 避免中心点带来的平台能力难扩展性问题
      • 避免中心点的潜在雪崩问题
      • 服务提供者与服务调用者之间无需任何服务路由中介
    • 两套服务框架的对比
      • 服务调用方式的不同带来的业务影响和扩展成本
      • 雪崩效应束缚了中心化服务框架的拓展能力
  • 阿里巴巴分布式服务框架HSF
    • HSF框架的主要组件
      • 服务提供者
      • 服务调用者
      • 地址服务器
      • 配置服务器
      • Diamond服务器（配置中心）
    • HSF主要组件交互
      • 服务节点对配置服务器列表的获取
      • 服务的注册发布
      • 服务的订阅
      • 服务规则的推送
      • 服务交互
    • HSF框架的实现
      • 采用Netty+Hessian数据序列化协议实现服务交互
      • 容错机制
        • 自动重试（我们未开启，需要服务端保证幂等）
        • 服务故障机器摘除
      • 线性扩展
  • 微服务
    • 微服务的典型特征
      • 分布式服务组成的系统
      • 按照业务而不是技术来划分组织
      • 做有生命的产品而不是项目
      • 智能化服务端点与傻瓜式服务编排
      • 自动化运维
      • 系统容错
      • 服务快速演化
    • 微服务与传统SOA的差异
      • 分布式服务组成的系统
      • 按照业务而不是技术来划分组织
      • 做有生命的产品而不是项目
      • 智能化服务端点与傻瓜式服务编排
      • 自动化运维和系统容错
    • 构建微服务架构遇到的问题
      • 微服务化的应用架构如何有效的进行服务管控
      • 分布式事务难题
      • 自动化运维和平台稳定性
      • 微服务的服务设计
      • 原有组织架构是否满足微服务架构持续发展的需要
• 共享服务中心构建原则
  • 淘宝共享服务中心概貌
    • 用户中心
    • 商品中心
    • 交易中心
    • 商铺中心
  • 什么是服务中心
    • 服务中心一定是不断发展的
    • 服务中心中的服务形态多样性
      • 依赖于接口的服务
      • 依赖于工具的服务
      • 依赖于数据的服务
    • 一个服务中心可以进一步划分吗？
  • 服务中心的划分原则
    • 服务中心的设计和评估维度
      • 设计层面：业务和系统建模遵循面向对象的基本原则
      • 运营层面：业务中心是一个完整的业务模型，要有业务运营和数据整合的价值
      • 工程层面：评估业务层对服务中心在数据库、业务以及运营上的需求和技术上需要的投入
    • 基本原则
      • 高内聚、低耦合原则
      • 数据完整性原则
      • 业务可运营性原则
      • 渐进性的建设原则
• 数据库线性拓展
  • 数据库瓶颈阻碍业务的持续发展
    • 数据库垂直拆分
      • 服务中心拥有各自独立的数据库（高频服务中心存在单机瓶颈）
    • 数据库的读写分离
      • 主库处理事务性的增删改操作，从库专门负责查询操作
      • 主库中的数据变更同步到从库集群
      • 优点
        • 拓展了数据库对数据读的处理能力，整体上大大的提高数据库读写能力
      • 缺点
        • 主库的写入能力无法拓展
        • 单表数据库庞大带来的性能问题
    • 分库分表
      • 将同一张表中不同数据采用水平分区的方式拆分到不同的数据库中
      • 被拆分的表数据尽可能的平均分配到不同的数据库中，避免拆分不均匀，出现新的单表过大问题
      • 优点
        • 确保单个数据库中保存的数据量在单机中能提供良好读写性能
      • 需要解决的问题
        • 跨库表聚合、join、事务、数据统计、排序等问题
        • 运维管控提出了更高的要求
  • 数据库分库分表的实践
    • 分布式数据层框架
      • Cobar
        • https://github.com/alibaba/cobar
      • tddl
      • drds
• 异步化与缓存原则
  • 业务流程异步化
    • 消息中间件
  • 数据库事务异步化
    • 大事务拆分成小事务
    • 小事务之间使用消息中间件通知机制
  • 事务与柔性事务
    • 事务ACID理论(原子性、一致性、隔离性和持久性)：强一致性模型
    • CAP理论(一致性、可用性、分区容错性)：分布式系统最多满足2项
    • BASE理论(基本可用、柔性状态、最终一致性)：分布式系统牺牲强一致性获得高可用性
    • 柔性事务解决分布式事务问题
      • 引入日志和补偿机制
      • 可靠消息传递
      • 实现无锁
  • 大促秒杀活动催生缓存技术的高度可用
    • 分布式缓存产品Tair、Redis
    • 本地缓存+缓存服务器+数据库架构
    • 秒杀独立隔离部署
• 打造数字化运营能力
  • 业务服务化带来的问题
    • 服务调用关系复杂，问题很难定位，出了问题甚至没人承认
    • 负责的服务被谁调用？调用场景和数据是合理调用？
    • 调用趋势怎么样？瞬间峰值多少？当前应用的服务容量怎么样？
    • 当前业务流程设计中，我依赖了哪些服务，哪些应用？
    • 整体依赖情况怎么样？
    • 接口出现性能问题，是哪个环节造成的？
    • 负责的服务中，哪些服务出错率较高？哪些可能存在瓶颈？
  • 分布式服务调用链跟踪平台
    • 每次请求全局唯一ID，traceId
    • 服务调用实时监控
    • 生成运行异常等情况监控告警
    • 业务指标监控告警
    • 用户某一次调用链全流程日志查询与异常排查
• 打造平台稳定性能力
  • 限流降级
    • 限流依赖评估当前服务实例的最大容量
    • 当前资源的使用情况实时监控（指标收集）
      • CPU：流量增加时，CPU使用率一般会正相关上升
      • 响应时间RT：服务端RT变慢，也是限流需要考虑的重要因素
    • 平台级限流拦截点在前端接入层Nginx
    • 应用级限流框架Sentinel:授权、限流、降级、监控
    • 流量预测算法
  • 流量调度平台
    • 背景
      • 个别服务器出现问题(单点故障)给整个调用链路带来更大的影响
      • 需要根据机器的实时服务能力来分配机器实时流量
    • 实现原理
      • 收集服务器的运行指标和业务指标
      • 流量调度平台根据设置的决策算法和规则对线上服务器进行下线等操作
      • 系统指标：CPU、LOAD等
      • 业务指标：HTTP响应时间、QPS、TOMCAT线程池等
  • 业务开关
    • 配置中心
  • 容量压测及评估规划
    • 充分的性能测试
    • 测试环境模拟测试的系统最大负载能力缺陷：1）测试环境简单：2）线下环境中的测试结果与线上环境没有对比关系
    • 系统容量压测和评估的自动化平台
      • 生成环境上的流量模型引流到压测服务器上，获得服务实例单机最大处理能力
      • 容量压测是将生产的真实流量引流到压测目标服务器上
      • 通过分布式服务框架对服务路由权重的支持，逐步增加压测服务器的生成流量
      • 压测服务器的运行检测，达到阈值水位后自动停止压测
      • 容量规划平台：服务的单机QPS+服务器机型处理能力差异分析 推测 需要部署的服务器资源
  • 全链路压测平台
    • 主要对零点峰值流量进行评估，以及对网站承压能力进行测试
    • 全链路压测平台同时处理正常流量和测试流量
    • 基础数据抽取
      • 以线上数据为数据源，进行采样、过滤、脱敏
      • 数据量与线上数据保持同一个数量级
      • 在数据库的sequence_id进行区间隔离
    • 链路和模型构造
      • 同一条链路需要构造海量的参数集合，代表不同的用户行为
      • 压测的业务模型：链路范围、链路的访问量级、链路的参数集合、基础数据的特性
    • 链路验证
      • 有上百条链路，每一条链路都需要确认全流程引擎跑通
      • 自动化完成对压测链路的验证
    • 业务改造
      • 压测链路的重复执行
      • 下游写流量的拦截
      • 防止污染统计报表和线上推荐算法
    • 数据平台
      • 重要模块：数据的准备、链路的构造、模型的构造
    • 流量平台
      • 全链路压测的CPU
      • 全链路压测操控中心：压测的配置和操控、数据的监控、压测引擎集群的管控
      • 压测引擎：控制台统一管控，部署在外网CDN，进行登录、session同步，发送各种协议的压测请求、状态统计
    • 影子表
      • 同一个数据库的实例上创建同样结构的影子表进行数据的隔离
    • 中间件改造
      • 链路上带上特定的压测参数，并保证全流程的传递
    • 安全机制
      • 安全的监控和保护，建立非法流量的监控机制；正常与压测数据防止错乱；压测引擎白名单，防止非法访问
      • 对安全流量的安全过滤：压测流量放松安全策略
  • 业务一致性平台
    • 因远程调用失败、数据保持失败等系统异常或业务逻辑bug导致数据不一致
    • 实时业务审计平台的目标
      • 高实时性地发现业务脏数据或错误逻辑实现
      • 方便接入各种业务规则，通过脚本(Groovy)规则编写的方式快速接入
      • 整合订正工具，形成规范的脏数据订正流程
      • 业务上线的实时监控，新上线的业务可以很方便的进行校验
    • 实现：事件模式把业务数据变化触发的消息转换为对应的业务类型事件
• 共享服务中心对内对外协作共享
  • 服务化野蛮发展带来的问题
    • 服务的数量和业务覆盖范围越来越大，如何找到并快速接入我需要的服务
    • 应用和业务架构约分越细，服务越来越专业化，跨领域理解的成本越来越高
    • 服务安全控制层缺乏：防止恶意调用；杜绝错误调用方式；管理服务的依赖使用关系
    • 开发体验很不友好，产品在接入流程，开发使用手册建设非常之差
    • 整体服务体系缺乏一个统一的服务治理层
  • 共享服务平台的建设思路
    • 建设思路：服务消费者(业务开发者) -> 共享服务平台 -> 服务 -> 服务提供者
    • 实现服务共享条件
      • 要找到一个合适的服务化对象
      • 建设服务化对象的基础设置
      • 服务化实时阶段
      • 增强服务和服务的基础设施实现服务的精细治理
    • 怎么构建？
      • 确定服务化的对象是API
      • 建立共享服务的基础设施，实现API的服务封装
      • 服务化实施阶段
  • 共享服务平台与业务方协作
    • 把离线的服务能力在线化，建设一个丰富的服务市场，这需要业务方共同参与密切合作
  • 业务中台与前端应用协作
    • 业务中台对前端核心业务的紧密沟通机制，如各服务中心的架构师和运营定期参与前端的业务会议、重要项目的研讨会
    • 建立分歧升级制度：分歧争论时，按照业务的层级关系依次升级
    • 岗位轮转推动真正换位思考
    • 业务的持续沉淀与共建模式
  • 业务中台绩效考核
    • 服务稳定是重中之重，考核比重40%
    • 业务创新推动业务发展，创新项目允许一定数量的生产故障。考核比重25%
    • 服务接入量是衡量服务价值的重要考核，考核比重20%
    • 客服满意度促进服务的提升
  • 能力开发是构建生态的基础
• 该书之外的补充
  • 中台的划分
    • 业务中台
      • 书中讲到的商品中心、用户中心等
    • 数据中台
      • 打通并整合业务中台数据，对外提供公共数据产品和服务
    • 算法中台
      • 提供算法能力，帮助提供更加个性化的服务
    • 技术架构中台
      • 提供自建系统的技术支撑能力（快速搭建项目、快速迭代，持续交付等），探索新技术等
    • 运营保障中台
      • 项目发布生产后的运营保障能力，devops等
  • 基础设施
    • MQ
    • 存储
    • 注册中心
    • RPC中间件
    • 日志
    • 搜索
    • 监控告警
      • 数据的全链路跟踪
    • 大数据平台
    • AB实验、灰度放量
    • 任务调度
    • 数据安全
  • 中台要求
    • 抽象化
    • 配置化
    • 标准化
    • 插件化
    • 可隔离
  • 中台之后该如何发展？
    • 随着数据的收集和沉淀，大数据和AI肯定能得到大力发展
    • 中台之后如何发展？为新业务探索做到配置化？无代码化？
  • 书籍下载
    • 链接: https://pan.baidu.com/s/1V3goo3Ot1hsi0DP7dMTsxA 提取码: uyhb 复制这段内容后打开百度网盘手机App，操作更方便哦