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