阿里的中台战略思想与架构相关核心内容解析

发展史

基础概况

• 首要问题阿里巴巴03年成立淘宝事业部,后来08年成立天猫事业部,此时淘宝技术团队同时支持着淘宝和天猫的业务,这样的组织架构导致淘宝业务优先级先于天猫,影响了天猫的业务发展。
• 另一个问题最初淘宝和天猫电商系统是完全独立的两套体系,两套电商平台都包含了商品、交易、评价、支付、物流等功能

于是乎共享事业部诞生,阿里巴巴”厚平台、薄应用”架构形态。

通用业务沉淀到了之共享事业部,包含了用户中心、商品中心、交易中心、评价等十几个中心。

为阿里各种前台业务提供着相应服务中心最专业、文档的业务服务

烟囱式发展

三套电商体系各自应用独立开发和运维

为什么会有这样的建设模式？

开发团队考虑到电商模式不同,所以需要独立建设
新的业务团队认为在之前的电商平台基础上改造支持新模式会有太多技术和业务历史包袱

因此三座烟囱分别树立支撑阿里集团最核心的电商平台业务

烟囱系统建设的弊端有以下三点。

• 重复功能建设和维护带来重复投资
• 打通烟囱式系统间交互的集成和协作成本高昂
• 不利于业务的沉淀和持续发展

希望提供更多功能或更好的体验服务要求时,在现实中就会出现两种情况

• 不管从kpi考核角度,还是从认知上认为服务封装任务已经完成,有新业务场景只能告知,母亲仅能提供这样的服务
• 服务提供者团队拥有不错做事的态度,也愿意改造服务以满足新业务的需求,但受限服务设计通用性和业务前瞻性不足,造成满足新业务需求要做大改造
• IT系统建设中实现的业务得不到沉淀和持续发展

IT信息部门在现有的模式下已经被更高的领导层定位成了业务支持的部门,是一个花钱的成本中心;

造成这样处境的原因？

因为IT信息部门的人员不懂业务;在业务系统具体流程、操作、数据模型方面IT人员比业务部门更懂
但是真正的懂业务指能对业务下一步发展有着自己的理解和看法;对业务流程如何进一步优化能更好的提升业务,甚至对企业现有的业务提出创新的想法;为企业带来新的业务增长点

构建中台基础

服务重用

SOA目前业界被验证的真正赋予企业业务快速响应和创新的科学架构,包括如今比较火的微服务概念
也只是SOA方法经过演变后的另一种呈现方式而已

SOA落地,通过搭建企业的ESB(企业服务总线),使各个系统以服务封装或服务调用的方式实现不同系统间的业务交互;

但是很多公司并没有真正发挥出SOA理念最核心价值,松耦合的服务带来业务的复用,通过服务编排助力业务的快速响应和创新

基于贡献服务体系建设的服务中心,原生就将相关的业务领域的业务功能和数据做了很好的统一,你就会发现前端构建的业务实际上也就没有实现系统业务互通的诉求

不断的业务滋养

“烟囱式”系统以及SOA项目制的建设方式导致前面所说的第三个弊端:业务得不到沉淀和持续发展,从而造成服务不能真正成为可重用的组件,为业务的快速响应、支持业务的快速创新带来业务价值

SOA项目是一种项目集成建设方式,很容易造成服务提供者面对业务提出更多要求时, 考核指标、工作回报都不能得到很好的体现
服务提供者主观上没有太大积极性满足新的业务需求,再加上当初服务设计的功能扩展性和业务前瞻性不足,导致有心无力满足新的需求
结果这些服务无法再进行功能扩展,继而成为企业”业务稳定”运行的服务

“业务稳定性”?

服务不需要”业务稳定”,而需不停的滋养,只有在滋养中才能从最初仅能提供呢单薄的业务功能服务逐渐成为It资产,而服务所需的滋养来自新业务不断进行服务的接入

如果追求业务稳定,一定程度就是固步自封, 逼着其他系统去建设同样的”轮子”,当越来越多的系统采用自建轮子满足自身系统,那这个服务慢慢就少有人问津,逐渐离开历史舞台

培育业务创新

企业真正的创新一定来自企业内部,如果在其他企业身上证明是好的创新搬到这家企业身上,可能效果完全不一样
而且这样的做法失去了创新中的”新”字,一个新事物货模式产生可以称其为创新,同样干这事的第二个很难再用创新形容

各个行业都在进行跨界创新, 互联网公司做汽车, 家用电器厂商去做手机, 但这样创新存在不确定因素, 存在的风险是一般企业不能承受的,也非常态化创新

从小开始学习基础知识,更多知识点的掌握
随着掌握知识点的增多, 我们开始有意识将一些知识点组合在一起,解决一些复杂的问题
将相关知识点串成知识线,随着知识领域的继续积累,更全面地了解这一知识领域,从而成为这个领域的专家

以下举例

共享业务事业部的”交易中心”对于不同业务中交易场景的支持;1688和淘宝还有天猫都有各自负责交易流程的业务架构师
当然也对各自电商模式下的交易业务十分擅长,包括后面的聚划算和咸鱼交易相关负责人
而”交易中心”的业务人员或架构师来自不同的业务模式下所有交易相关需求,这样的阵型使得负责”交易中心”相关人员更容易扩展到线和面的维度全面掌控交易业务

在整合交易流程(下单、收款、退款等),出现个别业务的结果不一致,也就是技术上没有错误和异常,但个别业务的结果不一致

• 比如用户买了航旅产品,在会员中心添加了相关的积分,但商品进行退款操作后,因为航旅部门、交易中心、用户中心协作的问题,导致积分没有从用户账号扣减回来
• 又比如个别商铺营销活动发生调整,应用逻辑Bug,导致用户所下主订单总金额与该主订单中子订单商品金额不同

所以又开发了BCP(Bussiness Check Platform 业务校验保障平台),使用业务规则方式, 通过BCP平台对交易进行业务和逻辑上的校验

该平台也在双十一期到了非常重要的作用

点、线、面组合上,点感知不到的问题,最终在线和面的平台上,更容易发现这些问题的本质, 通过专业的技能解决这些问题,为企业带来实实在在的业务价值

赋予业务快速创新和试错能力

多年前,企业规划好了
实施MES(生产制造系统): 很好地为企业带来生产制造的管控和效率的提升
建设OA系统: 就能很好地提升企业内部办公效率
实施CRM平台: 很好解决客户关系管理的问题,能够吸引新客户、保留老客户以及将已有客户转为忠实客户,增加市场份额

企业在互联网时代与同行业竞争对手产生差异化竞争力,业务试错是一个非常重要的能力
只有先人一步,唯快不破,才能帮助企业抢占商业先机的制高点, 互联网时代的竞争只有第一、没有第二

业务创新如同创业–样，一旦成功，给企业带来的回报可能是超出预期的,但也意味着有失败的风险。
在传统企业中，–定是需要申请预算和立项来落实业务创新的想法，传统“烟囱式”的系统建设方式对项目投人的资金和资源自然不会少。
在要申请大量资源而且项目还有失败的可能性的情况下，有业务创新想法的人在考虑到失败带来的影响时，–定会权衡其中的利弊
大多数人会选择退缩,只有少部分有魄力的人顶着巨大的压力走上了业务创新之道。

试想一下如果之前有一个好的业务想法，从头到尾建设所需的资源投人可能是20个人、4个月的时间，还有可能建设的系统达不到预期的市场效果，那这样一个典型的业务试错的成本是非常高昂的，任何一个企业都很难支持这样的试错方式

如果企业打造了很好的业务中台, 可以让3个人基于中台提供的核心服务在2周时间内就建设一个业务系统并推向市场
看看市场的反馈来决定是否加大对这个新业务的投入,我想任何一家公司都很乐意做这样的投入和尝试的

阿里巴巴如今的“大中台、小前端”战略

中台阵型中小前端的特征

• 团队协同效率最高: 几十人、上百人完成的任务,几个人之间协同成本最低
• 对商机的把握更加敏锐: 小前端必须过人的敏锐捕捉市场商机的能力,生于忧患死于安乐
• 调整方向更加快捷: 船大掉头难,投入200人和10人去完成一个任务,如果任务方向有错误,调整花费的时间和资源一定远超过10个人的团队
• 一旦发现正确目标,全力投入扩大战果: 一旦前端找到正确攻击目标,中台会集中炮火摧毁目标

这类型的战略架构,在阿里巴巴也是如此,投入了包括产品经理、运营、开发的十几名员工
进行基于淘宝和天猫商品的团购平台建设聚划算,最终这个团购平台一个半月后就成功上线

其他同类型的团购平台投入的研发资源是阿里投入资源的几十倍,上线时间也是延误好几倍
造成这样的差异原因就是精心沉淀和打造的用户中心、商品中心、交易中心、评价中心等服务能力在其中扮演了非常重要的角色

发挥大数据威力

• 数据分布广、格式不统一、不标准
  各个业务系统的会员数据分别存储不同的平台,不同的数据模型,造成相关业务数据模型和标准不统一,成为大数据抽取和同步带来复杂工作
  数据层访问的打通、数据权限的控制、数据格式的转换、数据清洗、数据同步等也是不小的开支
• 缺少能基于数据有业务建模能力的专家
  大数据平台难落地或让企业真正带来价值最大障碍,是哪些对大数据能力和算法有很深入了解的开发对企业的业务没有深入的了解
  从而导致企业花费了巨资搭建的大数据平台苦于没有适合的应用场景,空凭一身武艺而无用武之地

对于数据分布广、格式不统一、不标准 ？

如果在相关业务领域(用户、商品、交易等业务)在业务和数据层做很好的融合,这样业务数据做到了规整
对进行的大数据项目实施提供完整、工整、有质量的业务数据

对于缺少能基于数据有业务建模能力的专家？

这类懂数据采集、懂数学算法、懂数学软件、懂数据分析、懂预测分析、懂市场应用、懂决策分析等人都是难寻的
企业需要自我培养,从外部寻找可遇不可求
而共享服务体系很好帮助企业培育这类人才,这些人员自身用用不错的技术功底同时逐渐提升业务上的能力,这样的人才算“数据科学家”

阿里指数(大数据应用)09年中台共享事业部建立,将阿里几大电商平台的用户、商品、交易等业务沉淀为了几大服务中心
基于各服务中心的数据,很快构建了阿里指数平台(大数据平台)
可以从各个维度(用户、区域、行业等)展现出各种业务指数,为集团和商家的业务决策和营销策略提供了最有力的支持

改变组织阵型带来的组织效能提升

以往IT部门员工,一个项目上线后就投入到下一个项目工作中,对员工在业务或专业能力上很难得到持续积累和沉淀
如果打造中台共享服务体系,新的项目会基于中台共享服务体系建设,让员工在各自擅长和感兴趣的业务领域中持续发展
员工的业务理解和专业技能也能随着对应的能力服务中心所提供业务能力的逐渐完善而同步提升
对员工工作积极性和创新意识的提升将会创造一个很好的氛围

但这样流水线方式的弊端对于不同角色人员的技能提升出现发展瓶颈
做了3年的开发人员可能跟做了5年的开发人员在开发能力上没有太大的区别
这样又造成了

• 一类工作积极性没有之前那么高
• 另一类看到外面公司有更好的工作机会选择跳槽

淘宝服务化历程

• 项目团队间协同成本高、业务响应越来越慢
  jar包冲突、代码不一致
• 应用复杂度已超出人的认知负载
  没有一个人能完全清楚每一个功能和业务流程的细节
• 错误难于隔离
  基于运营的需要,每天都有新版本发布,淘宝历史中发生过几起事故,因为非核心功能设计不合理,代码质量差引起这个淘宝平台的业务受到全面影响
• 数据库连接能力难扩展
  早期所有所有业务能都在一个WAR,所有数据也保存在同一数据库集群中,而数据库集群连接数量有上线,平台也已经因为过高的数据库连接处于一个非常不稳定的状态
• 应用扩展成本高
  一个包含几百个功能的WAR所需要的初始和运行资源就不会太小,需要集群负载的时候,无法对单独几个功能模块进行服务能力扩展

选定SOA理念和思想

14个月的时间内将原来单一的应用模式改造成为机遇SOA理念的分布式服务架构

• 降低不同模块开发团队的协同成本
  分别负责不同功能的开发团队只要保证对外服务接口定义不发生变化,内部业务如何调整都不影响其他模块
• 大大降低系统间耦合度和整体复杂度
• 避免个别模块的错误带给整体影响
• 业务拆分后解放了对单数据库集群连接数的能力依赖
• 针对性业务能力扩容,减少不必要的资源浪费

中心化与去中心化服务框架

接下来的改造10年无需进行兴师动众的底层架构改造

去中心化不是SOA架构,以下是SOA的主要特性

• 面向服务的分布式计算
• 服务间松散耦合
• 支持服务的组装
• 服务注册和自动发现
• 以服务契约方式定义服务交互方式

但SOA一定基于ESB总线的方式,互联网新兴的去中心化分布式服务框架同样遵循了以上对SOA架构的特征定义

去中心化分布式服务架构解决的问题?

互联网中的”去中心化”,因为用户群体是整个互联网公众,所以为了能够更多用户访问持续扩展能力负载,选择去中心化分布式服务架构框架
同时”雪崩”效应也束缚了中心化服务框架的扩展能力

具体的服务框架细节请路由到以下地址

Dubbo解析

淘宝共享服务中心

• 各个服务中心怎么建设？
• 需要几个服务中心？服务中心的边界是什么? 有没有划分的原则和方法论?
• 服务中心应该多大合适?对应的组织团队和流程怎么保障?
• 服务中心的服务数量应该有多少?粒度应该多大?

淘宝服务中心概貌

• 用户中心(UIC)
  用户数据、存储和服务接口
• 商品中心(IC)
  • 商品描述:类目体系、SPU、SKU等
  • 商品发布投放能力
  • 商品管理能力
  • 商品巡检能力: 太长时间没有管理,要从活跃库删除,否则浪费计算和存储资源给买家糟糕的用户体验
  • 商品数据分析能力: 运营小二要日常运营、营销活动、类目调整都需要数据支持
  • 商品评价能力
• 交易中心(TC)
• 店铺中心(SC)

服务划分原则

建设考量的三个重要方面

设计层面: 主要遵循面向对象的分析和设计方法、即业务和系统建模遵循面向对象的基本原则
运营层面: 完整的业务模型,要有数据运营和业务整合的价值
工程层面: 共享服务的架构师基于分布式架构

基本原则

• 高内聚、低耦合原则
• 数据完整性原则:
• 业务可运营性原则
• 渐进性的建设原则

异步化与缓存原则

当淘宝平台由原来单一的War应用方式转换成以共享服务中心为核心的服务化架构
在分布式服务架构中,需要服务器之间进行多次服务交互才能完成
每个服务所修改的数据也都是按照业务维度划分的各个数据集群

业务流程异步化

目前淘宝的订单创建流程需要调用200个服务,服务调用时间都控制在20ms内返回结果,整个订单创建的时间也会超过4s
对于今天互联网时代的客户来说已经超过了忍耐极限

这样的调用链路,也会给服务会话处理现场带来长时间的资源占用,对于服务器整个系统吞吐量带来巨大影响

只要有设计经验的都会想到以异步化方式将交易创建过程中,对有严格调用顺序的保持顺序执行;

各个主流程采用投递消息,如何保证这些服务在一次订单请求中同时成功或失败?

数据库事务异步化

以上用一个互联网金融p2p平台进行交易系统改造中的客户还款场景为例
该步骤仅仅示意了主要的核心功能,没有考虑逾期还款、平台管理费、借／扣款人相隔的积分和会员等级变化等业务逻辑
这也是一个典型的要求事务一致性的场景,稍微数据不一致带来的后果都可能是成百上千的金额差异
所以整个扣款功能逻辑代码都是在一个大事务,通过数据库的事务特性来实现复杂的业务一致性

以还款为例,每一位借贷人进行还款操作至少会引起500条还款详单(修改详单状态)+500次借款人修改(扣款)+500名首款热账户表修改(收款)
这导致最后一条的最后几个小时平台接收到密集的还款请求,使得数据库持续高水位运行

解决核心问题的办法?
数据库事务的异步化,将大事务拆成小事务,降低数据库资源被较长时间事务锁占用而造成的数据库瓶颈
就能大大提升平台的处理吞吐量和实务操作的响应时间

以上是异步化后基于消息的还款实现流程

• 用户在平台点击了”还款”按钮后,生成一条还款启动消息,发送到消息服务上
• 还款开始程序接收到此消息后,首先执行”找到未还款的计划”,并同时进行”写入还款请求”和发送’还款计划计算消息’到消息服务商
• “还款计算”接收到还款计划计算消息后,进行还款总额的计算,并同时进行占款和发起支付流程的消息到消息服务上
• “还款计划分派”接收到支付流程的消息后,在给平台的账号转账同时,发送分期支付消息
  500次还款计划处理的操作拆分成500个不同的事务
• “还款计划处理”程序在接收到每一个还款详单支付请求的消息后,进行详单查找,计算还款详单,最后同时进行从借款人账户中扣占款及发送还款详单处理的请求消息
• 最后”还款详单”接收到”详单处理”请求的消息后,一次进行给还款人账户加钱,更新详单表信息等操作

事务与柔性事务

不管业务流程的异步化还是数据库事务异步化,都面临一个如何保证业务事务一致性的问题
基于CAP(放弃分区容忍性、放弃可用性、放弃一致性)和BASE(基本可用、柔性状态、最终一致性)

对于实现高可用,认为

高可用 = 系统构建在多机 = 分布式系统
高性能 = 分布式系统的副产品

传统分布式事务

按照业务领域:用户中心、交易中心的不同被拆分到不同的数据库后,在某些业务场景(比如订单创建)下,必然会出现同一个事物上下文,需要协调多个资源(数据库)以保证业务的事务一致性,对于这样的场景,业界在就有基于两阶段提交方式实现的分布式事务

X/Open组织为基于两阶段提交协议的分布式事务系统提供了标准的系统参考模型(X/open事务模型)

X/open定义了两个标准接口:

• Tx接口用于应用程序向事务管理器发起事务、提交事务和回滚事务
• Xa接口形成了事务管理器和资源管理器之间的沟通桥梁,用于事务管理器将资源管理器(如数据库、消息队列等)加入事务、并控制两阶段提交

这样的传统分布式事务造成了

• 单机锁 = 时间消耗(微秒级)
• 跨多机锁 = 时间消耗(毫秒级) = 1000倍单机时间消耗

柔性事务

• 引入日志和补偿机制
  参与者节点重做或回滚需记录redo/undo日志,当事务重试、回滚时,可以根据这些日志最终将数据恢复到一致状态
• 可靠消息传递
  多次消息投递直到答应完成
• 实现无锁
  数据库性能和吞吐率瓶颈在于强事务锁,但是放弃锁是一个思路,放弃锁不意味着放弃隔离性,如果隔离性没有保障必然带来大量的数据脏读、幻读等问题
  • 避免事务进入回滚:部分业务出现异常,可以不回滚也满足业务的要求
  • 辅助业务变化明细:资金或商品库存增减处理,可采用记录这些增减变化的明细表,对秒杀很容易出现锁抢占,避免锁的方式是订单创建事务只是在”库存预减明细表”添加一条对应商品库存的预减记录
  • 乐观锁:悲观锁对数据访问极强排他性,也是产生数据处理瓶颈的重要原因,可采用数据版本方式做乐观锁
    

柔性事务在阿里巴巴的实践

消息分布式事务

典型的应用场景

淘宝下单和付款两个操作时几个主要业务步骤的执行示意
其中在下单这个分布式事务操作中包含了库存预减、创建交易订单、创建支付订单几个主要操作
核心就是通过MQ消息服务的方式实现了这几个操作的事务最终一致性。
在付款事务中，对扣款、创建扣款流水、实减库存、修改订单状态等进行了事务操作,其中也都是有MQ服务实现了整个分布式事务的事务一致性。

在订单创建或付款出现异常，比如实减库存失败、付款超时时，同样也会通过消息服务的方式
通知相关的服务进行订单状态的修改、支付宝中支付订单状态的更新及退款操作、预减库存回撤等相关操作，所有的这些操作可能由不同的服务完成相应操作，但整体保持事务性。

Tcc框架

支付宝的XTS分布式事务框架基于Base思想实现类似二阶段提交的分布式事务框架
上面的消息分布式事务只支撑正向补偿,XTS可同时支持正向和反向补偿

• Try阶段主要是对业务系统做检测及资源预留。
• Confirm阶段主要是对业务系统做确认提交，Try阶段执行成功并开始执行Confirm阶段时，默认Confirm阶段是不会出错的。即:只要Try成功，Confirm -定成功。
• Cancel阶段主要是在业务执行错误需要回滚的状态下，执行业务取消，预留资源释放。

这种模式概括如下

这种模式可以概括如下:

• 1 )支付宝的主体业务服务在执行过程中一般都会涉及一次或者多次的财务处理
• 2)业务服务与账务服务对业务处理的最终结果有同等的决定权，两者都能够使业务处理失败。
• 3)当一次业务处理中涉及超过两个参与者时，附加的参与者–般对业务处理的最终结果没有决定权，但它们会根据业务处理的最终结果完成自己的处理。
  例如很多业务在完成之后都涉及收费的处理，但一般收费不成功不会影响业务处理本身的结果。

TXC的架构示意图

TXC两阶段提交实现。TXC也是基于两阶段提交理论实现，由TXC服务器负责整体的事务协调和管理
由部署在TXC客户端上的资源管理器组件实现各客户端与TXC服务器的事务注册、状态更新、提交等操作

一个标准的两阶段提交事务处理时序图

事务回滚的工作原理图

打造平台稳定性

限流和降级

限流的作用相当于电路上的保险丝，当过载的时候掐掉一些流量，让系统有能力集中资源以较快的速度处理平台处理能力范围内的业务请求。
也就是大促场景中，仅让1000万用户中的100万用户进入后端的处理流程中，将其余900万用户的请求通过队列排队或直接阻挡在平台处理单元之外的方式
保障平台能在处理能力范围内对100万的用户请求进行处理。

平台要具备限流的能力，首先需要对服务部署的能力有一个准确的评估，知道服务实例的部署量到底最大能满足多少业务请求的处理要求。
这就需要采用压力测试的方式对系统进行压测，但传统的压力测试方法都是采用模拟的数据
从实践的角度来看，这些压测的数据与在实际生产环境中所表现的指标还是有比较大的偏差

所以又得开发一套线上压测工具,能更方便和准确地对服务的容量进行评估,即获取该服务所能提供的最大处理能力

阿里巴巴是通过在Nginx上实现的扩展组件TMD(TaobaoMissileDefense,淘宝导弹防御系统)实现了接入层限流的主要工作
TMD系统可通过域名类限流、cookie限流、黑名单以及一些安全策略等很好地实现了在接人层的限流措施。

TMD系统包含了淘宝技术团队开发的开源模块nginxhttp-sysguard
主要用于当访问负载和内存达到一定的阀值之时，会执行相应的动作，
比如直接返回503，504或者其他URL请求返回代码
一直等到内存或者负载回到阀值的范围内，站点恢复可用。

在模块nginx-http-sysguard基础上，淘宝TMD系统给用户提供了可视化的配置管理界面，方便用户针对不同的业务场景实现不同的限流规则

如果有来自单台机器持续高频率访问淘宝平台上的一个URL页面
可在TMD中设置规则:访问频率大于180次/每秒，则进行IP访问频率限速或cookie访问频率限速。
正是有了TMD这样配置灵活、操作方便的规则配置界面，运维人员都可以针对所发现的异常请求以及实时的处理状态，设置出各种保护措施，保障平台
在面对大促秒杀或恶意攻击时，具有一定的自我保护能力，在平台接人层外部惊涛骇浪的访问洪流下，平台接人层内部保持稳定、健康的运行状态。

这套流控技术方案是可行的，实现起来也比较简单，但在实际应用场景中还是会发现不少问题以及功能的局限性,比如:

• 1)如果一个应用需要对100个接口进行限流，那么对应地也就需要配置100个advice和编写100 个拦截器，如果是成百.上千的应用呢?
• 2)限流阀值是硬编码形式(一般采用static值)，阀值修改繁琐，也没有统- -的管理和配置。
• 3)在某些情况下，当前服务的处理线程池被占满，导致该问题的原因可能不是来自服务调用上游，而是因为依赖的下游服务出现异常导致的，所以单单在服务端的限流手段太过单一，需要结合服务调用上下游进行更灵活的设置。
• 4)缺乏统一的监控平台，对当前的服务限流情况没有全局管控。
• 5)限流算法简单，当在双十一这种特殊场景，会看到毛刺现象，需要一种更平滑的限流算法。

因为此方案在实际应用中所暴露出的问题，所以有了限流平台Sentinel的出现。
为整个服务化体系的稳定运行行使着警戒任务，是对资源调用的控制平台
主要涵盖了授权、限流、降级、调用统计监控四大功能模块:

• 授权:通过配置白名单与黑名单的方式对HSF的接口和方法进行调用权限的控制;
• 限流:对特定资源进行调用的保护，防止资源的过度调用;
• 降级:判断依赖的资源的响应情况，当依赖的资源响应时间过长时进行自动降级，并且在指定的时间后自动恢复调用;
• 监控:提供了全面的运行状态监控，实时监控资源的调用情况(QPS、响.应时间、限流降级等信息)。

Sentinel平台有两个基础概念:资源和策略，对特定的资源采取不同的控制策略，起到保障应用稳定性的作用。
Sentinel 提供了多个默认切入点，比如服务调用时，数据库、缓存等资源访问时，覆盖了大部分应用场景，保证对应用的低侵人性;
同时也支持硬编码或者自定义AOP的方式来支持特定的使用需求。

Sentinel不仅提供限流还提供降级

要实现服务降级，需要在应用或服务实现中，首先留下可供服务降级进行服务是否调用切换的逻辑。
一般在代码中采用static值的方式，作为业务逻辑分支的判断条件，通过对这些static值的修改，实现服务调用逻辑的变化。
同样可以通过Sentinel控制台提供的降级规则的配置功能，当对某个服务的方法响应时间一旦超过阀值后，就意味着调用的这个服务已经出现了处理性能的问题，则会自动切换到降级模式，降级持续的时间可自定义设置。

流量调度

业务开关

容量压测及评估规划

全链路压测平台

业务一致性平台

一个用户刚刚在双十一活动中下了一个订单，在下单的过程中使用了“扣减10元”的优惠券，并完成了付款操作
但因为某一个模块的逻辑中因为没有实现对优惠券的扣减，造成实际支付宝付款时并没有扣减这优惠的10元，从而造成多扣了用户的金额。
如果发生这样的情况，有可能在大量用户投诉之后，应用开发人员才从客户服务部门收到反馈,或许这已经是问题出现一个小时之后的事了。
面对这些业务与数据不--致的问题，业务稳定性保障迫在眉睫。要解决这个问题，就需要在实现业务处理的过程中，实时检测到业务不一致的问题
在消费者发现该问题之前系统就应该发出了报警，并且已转交相关技术人员处理。
也许在用户开始投诉的时候,这个问题就已经纠正过来,这样的话影响的用户范围就很小了。

在这样的背景下，实时业务审计平台(Business Check Platform，BCP) 应运而生，
这个平台采用规范与标准化业务规则的方式，统一。解决平台服务化后越来越凸显的业务-致性问题，解放业务人员那颗悬着的心。

BCP平台并不仅限于交易类业务，也适合其他对业务稳定性要求比较高的领域。
平台的目标是在每个上线的业务都能形成一对一的监控与检测,并形成一个规范的业务上线、订正流程。

BCP平台实现了以下4个主要目标:

• 1)高实时性地发现业务脏数据或错误逻辑实现，第一时间发现并及时通知技术保障人员，而不是等客户反馈。
• 2)方便地接人各种业务规则，通过脚本规则编写的方式，让各应用快速接人业务审计平台。
• 3)整合订正工具，形成规范的赃数据订正流程。
• 4)业务.上线的实时监控，新上线业务可以很方便地进行校验。

BCP平台功能定位

通过事件的类型和状态,从规则库中获取对应的业务规则,而不是所有的事件都需要跟规则库中所有的规则进行循环比对，
否则将会因为规则的逐渐增多给业务规则判断带来性能的影响

进人规则执行部分，BCP平台提供了Groovy脚本的规则编写方式，方便各应
用通过脚本实现快速地与BCP平台对接:

if (order.containsItemTag("tmc_tags")&order.getAttribute("promotion")!="bigMarkdown") {
	return "应为大促优惠,当前promotion: " + order.getAttribute("promotion");
}

以上示例代码实现了如果订单对象的ItemTag包含tmc_tags标签时,而且如果promotion的属性不等于bigMarkdown(大促优惠)
则认为数据为脏数据返回错误信息,BCP会将不满足系统中业务规则的结果保存到数据库中,方便相关人员随时查看
同时系统会给相关人员发出报警通知。

使用BCP平台实现业务稳定典型案例双流对账方案

• 单一系统内的对账
• 单链路不同系统间的对账
• 不同业务链路间的对账

某供应链平台的双流对账场景为例，这个场景中有两个Notify (消息服务)数据源，IPM是库存中心批次库存变更消息，PAC是菜鸟网关消息，PAC消息是先于IPM消息到达的
所以在这个方案中B C P在接收PAC的消息后并暂存人Tair(缓存服务器)中，等待IPM消息到达后根据消息中的关联ID去Tair中找PAC中对应的那条消息来做对账。
从而实现在不同业务链路间的对账操作。