正文 

当前位置： 首页 > java > java教程

业务中台的架构案例

娟宝宝萌萌哒 娟宝宝萌萌哒     2023-04-16     698

关键词：

文章目录

业务中台目标

  • 目标：
    • 整体目标：高内聚、低耦合，便于开发和维护。
    • 五个方向：性能、可用性、扩展性、伸缩性、安全性。
  • 原因：
    • 单体架构的大泥球会导致业务迭代困难、无法针对性伸缩、故障没有隔离等问题，需要向微服务方向演进。
    • 演进过程中为了复用、抽象，需要沉淀中台能力。
    • 业务中台不仅仅需要关注功能性需求，更需要关注5个方向的非功能性需求，才能高效稳健的支持业务的发展，否则极容易演化成分布式单体。
  • 实现方式：
    • 战略上：
      • 横向分层：分散关注、松散耦合。
        • 应用层：提供具体业务的API和视图，和用户直接交互。
        • 服务层：提供业务编排和业务原子能力。
        • 数据层：提供存储服务，如数据库、缓存、搜索引擎、文件。
      • 纵向分割：通常按照不同业务划分，专人做专事、不同等级保障。
      • 分布式部署：包括服务应用、静态资源、数据存储、计算、配置、锁、文件的分布式。由于通常需要避免单点，需要在C和A之间权衡。
    • 战术上（几种方式可能组合使用）：
      • 集群。负载均衡和失效转移提供并发特效和可用性。
      • 缓存。在数据热点不均匀、数据有一定有效期的情况下使用。
      • 异步。堆积消息避开故障时刻提高可用性、减少rt、削峰。
      • 冗余。包括集群备份、冷热备份、灾备数据中心。
      • 自动化。发布过程、代码管理、安全监测、监控、失效转移恢复、降级、分配资源都可以自动化。
      • 安全措施。密码、验证码、加密、过滤、风控等。
      • …

详细理论内容可参考：大型网站架构

具体案例

结合电商商品中台、交易中台、春晚红包的工作经历梳理使用场景

性能

缓存

  1. 分布式缓存。主流的redis的3种集群，是电商商品中心各种场景的缓存主力。
    1. 主从redis。client 路由。
      1. 一致性hash路由。商品主库上的缓存，用于商详等商品单查。已经成功支持过200+ redis实例，抗500w+ qps。
      2. 多副本路由。上一条的二级缓存，存放热点数据，防止单redis和主库单分片被打挂。50个 redis实例可抗100w+ qps。
    2. codis。proxy路由。用于C端列表大流量的批量查询，通常多集群部署。单集群256主从server+100proxy可抗近千万qps，并且可以通过节点的方式最多支持到3000w qps。、
    3. redis cluster。前两者的替代品，扩容更加方便。集群规模受限，建议最多200 server和2T内存，可以通过多集群分片的方式扩展集群的规模。
  2. 本地缓存。主流Caffeine，用于列表场景大内存（56G）实例抗突发热点，保护分布式缓存。
  3. 线程缓存。ThreadLocal，用于aop带出上下文，如商品B端编辑在aop中校验商品状态，并把商品数据带到业务逻辑中修改，减少查库的次数。

异步

  1. 消息队列。
    1. 消息中间件。春晚红包抢红包实时链路db只记录中奖流水，后续发奖通过kafka异步。抢红包需要支持600w tps，下游发奖等无法支持，并且异步也可以减少用户等待时间能再次摇奖。
    2. 事件驱动。用户下单后的预约流程需要商家接单，接单等待时间较长。实现为用户申请落库后直接放回，后续通知商家流程通过可靠领域事件驱动，商家接单之后回调。
  2. rpc异步。商品列表聚合素材、标签等数据使用异步dubbo，并行调用减少列表渲染时间。
  3. 线程池。商品列表的缓存回写通过线程池异步，减少为命中缓存时用户请求等待的时间。

集群

  1. 服务层k8s实例的集群化。商品列表场景单机房上千实例可抗300w+ qps，并在10ms内返回。单机压力大会导致cpu飙升的长尾。
  2. 缓存的集群化。商品列表的缓存集群抗300w+ qps的批量查询流量，并保证rt在1ms左右。
  3. 持久化存储的集群化。
    1. mysql。
      1. 商品256库256表，可以支持百万qps的查询，日常流量下商详场景的redis雪崩，也可以基本支持业务。
      2. 春晚预热的全局预算累计拆分到32个库，可支持几十万的写入。
    2. hbase。商品列表缓存下的持久化存储，支持百万qps的查询。

代码优化

  1. 多线程。春晚红包下单回滚库存、限购等资源时并行回滚，减少用户等待时间。
  2. 资源复用。下单页对大ab参数的解析只做一次，后续都使用解析后的对象。解析大json有可能占用机器将近一半的cpu耗时。
  3. GC调优。
    1. 更换gc方式。商品敏感数据服务由于需要使用本地缓存，gc压力大，上游50ms经常超时。使用zgc，通过损失一定cpu获得1-2ms的gc时间，极大的降低了上游的超时率。
    2. 调整其他gc参数。

存储优化

  1. 存储选型。商品操作日志这种写多读少的场景，使用hbase这种追加式的存储，做到毫秒级写入。
  2. 索引调优。
    1. 添加索引减少每次扫描的数据行数，从而降低响应时间。
      1. 商品的sku包含删除和未删除的sku，热门商品修改频繁，删除的sku较多，导致每次可能需要查到上万sku，但实际生效的只有几十上百个。添加商品Id+SKU状态的索引解决这一问题。
    2. 添加查询条件引导优化器走扫描数据量少的索引。
      1. 春晚红包的索引优化。

可用性

分布式场景判断是否可用的一般方式：超时

集群

  1. 服务层的无状态化k8s集群。可负载均衡+重试做到失效转移。
    1. dubbo调用支持配置retry属性，也可二次开发健康度lb，从而使得请求最终落到下游的正常实例上。
  2. 存储层的数据备份。可失效转移。
    1. 单主写入
      1. 同步备份。mysql同步复制
      2. 异步备份。mysql异步复制，redis主从复制
      3. 半同步备份。商品库采用mysql半同步复制，主备同步复制，主从异步复制，主到灾备异步复制，是C和A的折中。
    2. 无主写入。
      1. 商品中心的缓存采用单机房三集群，同步时串行写入，异常时跨集群降权重试。

多活

  1. 同城双活，异地、跨云多活。
    1. 商品中心、交易中心等核心服务均部署两个以上的机房，同时提供服务，并且定期做切流量演练。

风险识别

  1. 热点流量。
    1. 业务识别。热点商品通过定时任务拉秒杀服务获取，并刷到多副本缓存中，用于商品详情页和下单，避免数据库被打崩。
    2. 系统识别。
      1. 商品列表使用caffeine本地缓存，通过tiny-lfu识别热点并缓存到本地，保护分布式缓存。
      2. 商品详情、下单服务使用改造之后的sentinel，发现db访问热点，并刷到多副本缓存。

分级

  1. 高优先级的服务占用更好的硬件资源，部署在不同的宿主机上，甚至异地容灾。
    1. 商品服务独立宿主机，和其他服务隔离，并做多机房部署和异地灾备。
  2. 高优先级的场景和其他场景隔离，避免被影响。
    1. 商品详情的缓存使用独立的redis集群，和其他缓存独立。
    2. 电商核心的盈利部门广告从单独的商品集群查询商品。

异步

  1. 方式同上一节中的mq,dubbo。
    1. 下单流程生成交易快照使用mq+异步dubbo双通道，不影响核心的下单链路。

限流

  1. 保证有效流量不超过自身的处理能力。分为集群限流和单机限流。几种限流算法。
    1. 集群限流。用存储如redis计数，适合流量小、精度高的场景，如1w qps左右。
    2. 单机限流。本地内存限流，适用于流量大精度不高的场景。
      1. 商品服务均使用单机限流 。dubbo在filter中用sentinel的滑动窗口，每个窗口默认0.5s。

熔断

  1. 抛弃下游请求。下单页服务对下游的所有依赖如果超过50%，会被mesh层熔断。

降级

  1. 强依赖降级：
    • 无损降级。如读容灾存储。
      1. 交易支付流程如果查询账号服务失败，则从容灾的redis中获取账户信息。账号信息每次查询账号服务后更新，由于账户变更不频繁，读容灾存储基本等于无损降级。
    • 有损降级。如异步补偿写。
      1. 交易下单流程中如果限购服务异常，可以降级成读历史订单后补偿扣限购，而不是同步扣限购。可能造成超卖。
  2. 弱依赖降级：可以失败
    • 缩短超时时间。交易下单页对于历史留资等若依赖超时时间设置成200ms而不是框架默认的1s
    • 支持丢弃请求。以上的留资服务可以手动降级，不去请求。

重试

  1. 需要注意：
    1. 下游保证幂等。
    2. 重试的错误类型。网络超时可以重试，业务异常需要具体问题具体分析，有些异常重试没有意义。
      1. 某分布式事务组件的思路是一阶段提交，二阶段无限重试，但是二阶段调下游的入参有问题被拦截，无限重试卡住。
    3. 重试次数限制。过多的重试会造成读或写扩散，打挂下游。

规范流程

  1. 版本管理。分布式服务场景下，分支开发、主干发布。
    1. 大多数互联网公司的做法，开发分支本地调试，测试分支发布到测试环境，主干分支发布到生产环境
    2. 测试分支可以建设泳道，减少需求之间的影响，但是也可能遗漏多个需求同时修改触发的bug
  2. 自动化发布、自动化测试。
    1. 整个公司使用发布平台发布，减少人工操作失误的概率。
  3. 预发布、灰度发布。
    1. 公司所有上线必须走预发验证，之后滚动发布。

监控告警

  1. 监控+告警人工介入。如cat可以监控应用并通过电话消息等多种方式触达开发人员，及时介入线上故障。

扩展性

领域建模

  1. 通过DDD战略层面拆分各个业务域
    1. 交易中台拆分成商品、营销、交易、履约、结算5个业务域，大多数需求可以闭环在各个业务域内。
  2. DDD战术层面搭建微服务。
    1. 使用六边形框架搭建微服务。
      1. 交易中台的服务使用DDD构建，切下游模型、接口变更时只需要对rpc适配层进行少量代码改动，无须修改领域层。
    2. 领域模型的通用性，必要时可分离为业务子域或者基础设施子域。
      1. 商品中心的商品扩展属性通过k-v形式存储，shema通过groovy脚本校验，可以做到不发版迭代业务。已经迭代过数十个需求。
      2. 商品详情装修组件也设计为通用的组件+schema+数据的形式，支持业务动态配置详情页。
      3. 商品消息通过配置化每个业务可以单独订阅感兴趣的组合，如只关心商品和SKU的消息。
      4. 通用的能力，如商品黑名单、商品店铺协议、商品操作日志、计数能力单独抽业务子域，其他业务可以复用。

微服务

  1. 通过微服务分解业务模块。是DDD的技术实现。
  2. 微服务之间可以通过多种方式交互
    1. 同步的rpc、http调用。
    2. 异步的消息中间件、异步rpc。
  3. 微服务之间的交互协议也是可扩展的
    1. json, hessian，thrift等序列化方式
    2. hbase等nosql存储

扩展点

  1. 开放平台。注重对外部开发者的扩展性。
    1. 交易中台会定义一套三方下单的接口，并公开在开平文档中，saas根据供应商提供client_key路由到指定的url
  2. 中台扩展点。交易中台通过在编排层流程节点定义接口，业务侧实现接口的方式，将业务定制逻辑剥离。

伸缩性

分割

  1. 水平方向：按照业务处理流程分离，比如API层、编排层、原子能力层、中间件层、存储层。
    1. 交易中台的服务层无状态，可以快速扩容。有状态的存储层相对伸缩性较差。
  2. 垂直方向：
    1. 按照业务模块分离。
      1. 交易中台新建设预约能力，和正向、履约独立，不用再对现有流程进行修改。
      2. 商品中心的库存服务单独拆分，和商品数据动静分离。商品可以往大流量支持场景，使用缓存伸缩，库存往小流量写场景堆存储伸缩。
    2. 按照数据冷热程度分离。
      1. 商品库会hive表捞删除1年的商品，通过kafka推给业务删除商品库的相关数据并存储到hbase中，hbase提供只读能力。

集群

  1. 服务层的无状态化k8s集群。可扩容支持大促流量，负载均衡业务无感知。
    1. 双11等大促时，商品中台需要两倍以上的k8s实例做压测和保障，可扩容并依赖dubbo的负载均衡支持业务。
  2. 有状态的存储集群可以扩容，并通过2种方法识别到数据在哪个分片上。
    1. 元数据服务器。
      1. 商品中心使用hbase，依赖meta节点获取rowkey的分布，扩容无须业务感知。
      2. redis cluster的槽迁移，依赖槽的路有扩容同样无须业务感知
    2. 路由算法。商品中心客户端路由缓存使用一致性hash，扩容通过平台配置，业务无须修改代码

安全性

校验

  1. 字符串强校验。不拼接字符串作为sql入参
    1. 下单流程对手机号会进行正则校验，防止sql注入。

加密

  1. 单向hash加密（MD5、SHA），对称加密（DES、RC），非对称加密（RSA）等。
    1. 订单的用户信息属于用户隐私，需要通过AES加密之后存储在DB，防止泄漏。

风控

  1. 规则引擎+统计模型识别黑产。
    1. 交易中台下单前过风控拦截，下单后、支付前后通知风控分析用户行为。

基于电商业务中台最佳实践：总体架构介绍与交易业务中台核心设计

架构总原则：大中台+小前台的架构思路业务中台采用领域驱动设计（DDD），在其上构建业务能力SAAS，持续不断进行迭代演进。平台化定位，进行了业务隔离设计，方便一套系统支撑不同玩法的业务类型和便于定制化扩展。前后... 查看详情

3.数据中台---数据中台建设与架构(代码片段)

...数据中台建设与架构3.1　持续让数据用起来的价值框架 业务数据化=>数据资产化=>资产服务化=>服务业务化3.2　数据中台建设方法论 1种战略行动 把用数据中台驱动业务发展定位为企业级战略，全局谋划。 在中台建设过... 查看详情

构建数据中台的组织架构

...的软件和其他技术的整体观点和方法。企业架构又细分为业务架构、应用架构、数据架构、技术架构几个方向。其中业务架构的定义是“定义业务战略和组织，关键业务流程及治理和标准”。因为数据中台其实就是组织为了... 查看详情

构建数据中台的组织架构

...的软件和其他技术的整体观点和方法。企业架构又细分为业务架构、应用架构、数据架构、技术架构几个方向。其中业务架构的定义是“定义业务战略和组织，关键业务流程及治理和标准”。因为数据中台其实就是组织为了... 查看详情

中台服务架构的一点思考

 中台服务架构的思想是伴随着企业规模不断扩大、业务多元化而形成的。如阿里巴巴将集团20多个核心业务中公共的、通用的业务以服务的方式沉淀到了共享业务事业部，这套共享服务体系为阿里巴巴集团的核心业务赋能，... 查看详情

中台方法论及案例收集

...略思想与架构实战》  阿里研究员玄难：如何做电商业务中台Thoughtworks中台思想盛宴的重要参与者ThoughtWorks，他们出品的文章深入浅出，属于必看系列。中台是个什么鬼 中台到底长啥样？中台的定义和王健一起&... 查看详情

业务中台系统架构：大中台+小前台电子商务系统搭建框架思维

...建行业有近十几年的服务经验，近年来的数据中台、业务中台等系统架构兴起，大多数企业在不清楚的中台背景的情况下就盲目追求，最后只会导致自身平台丢失原有的优势框架。在这里，我们来总结下业务架构... 查看详情

1.企业it架构转型之道：阿里巴巴中台战略思想与架构实战---阿里巴巴集团中台战略引发的思考(代码片段)

第1章阿里巴巴集团中台战略引发的思考1.1阿里巴巴共享业务事业部的发展史1.2企业信息中心发展的症结 在高层看来，IT信息部门定位成了业务支持的部门，是一个花钱的成本中心。造成这样的处境的原因是，IT信息部门的人不懂... 查看详情

数据中台02：数据中台架构

...务，把数据资产变为数据服务能力，服务于企业业务。数据安全管理、数据运营体系，保障数据中台可以长期健康、持续运转。1、数据汇聚数据汇聚是数据中台数据接入的入口，数据中台本身不产生数据，所... 查看详情

中台方法论及案例收集

 这两年可以讲基本翻遍互联网上各种主流的中台资料，有很多好的文章或书籍，我略作整理归纳，便于查阅，未来会持续更新。阿里巴巴中台缘起阿里，也是落地最好的案例，阿里系出品相关的文章必须... 查看详情

中台之中台的设计

...异化特点是什么？愿景的提炼需要充分收敛。确定并梳理业务范围即细粒度的业务架构梳理，抽取共性，识别中台产品的具体需求。由于中台是面向企业级的，设计的是企业的全业务线，而且是端到端的全流程。需要基于愿景结... 查看详情

中台：业务中台数据中台技术中台

...企业级能力复用平台为什么需要中台避免重复造轮子许多业务需求或功能需求高度类似、通用化程度很高，但是由于没有专门的团队负责规划和开发，大量的系统重复开发、重复建设，导致复用性低、效率低、产研资... 查看详情

数据中台：什么是数据中台

...企业数据管理都以传统的IT架构为基础。每当技术部门为业务部门解决问题时，需要从业务需求的探查、技术壁垒的打通等从上到下各个方面来建设新系统。每个系统的建成都自成一体，各自满足业务部门的需求。这种情况不仅... 查看详情

业务中台数据一致性方案(代码片段)

引言随着业务的发展，微服务架构逐渐成为当下业务中台的主流架构形式，它不但解决了各个应用之间的解耦问题，同时也解决了单体应用的性能问题实现可扩展可动态伸缩的能力。如下图所示，业务中台就是将... 查看详情

数据中台详解

文章目录什么是数据中台数据中台VS数据仓库数据中台的业务价值与技术价值数据中台建设与架构数据中台建设方法论数据中台架构数据汇聚联通：打破企业数据孤岛数据采集、汇聚的方法和工具数据交换数据体系建设数据... 查看详情

10张架构图详解数据中台，附全套数据中台ppt

...工、数据建模、然后分门别类地储存，再根据实际的业务场景，打造各类数据服务（含数据应用平台）从而实现对业务的赋能加速。但以上流 查看详情

国内最强数据中台架构，它排第一！

提起业务流量，除了全民抢票平台12306，当数阿里最有发言权。上到双十一千亿级流量洪峰，下到日均百万、千万交易量的平台，每个业务模块背后的高并发架构理念，无处不在。成熟的架构设计只是其一࿰... 查看详情

面试业务中台是什么？(代码片段)

文章目录前言什么是业务中台？什么时候需要业务中台？如何规划和建设业务中台？业务中台建设的关键要素业务中建设的核心技术前言什么是业务中台，企业需要业务中台吗？怎么规划和建设业务中台，... 查看详情