业务中台的架构案例(业务中台是中台体系)

java8

帖子摘要：业务中台目标  目标   整体目标高内聚、低耦合便于开发和维护。五个方向性能、可用性、扩展性、伸缩性、安全性。  原因   单体架构的大泥球会导致业务迭代困难、无法针对性伸缩、故障没有隔离等问题需要向......
; @, X" o+ f3 G* H3 \- Y3 x
大家好，欢迎来到Java吧（www.java8.com），交流、学习Java技术、获取Java资源无任何套路，今天说一说：“业务中台的架构案例”

: I( W' z' m# T+ z% ~
9 c) ]0 X) K$ c2 o- ]        
               
4 G* p. z1 ]& `4 e4 M5 l                    
2 b* @0 o! O2 |2 o' \) H" J                        
* q+ v: p& U; `6 D2 |! h                    
                    业务中台目标
9 [+ Y7 c, m* t% V6 W. V0 a

目标

  

整体目标高内聚、低耦合便于开发和维护。

五个方向性能、可用性、扩展性、伸缩性、安全性。

原因
$ @  b$ U! Q/ V& w
  

单体架构的大泥球会导致业务迭代困难、无法针对性伸缩、故障没有隔离等问题需要向微服务方向演进。

演进过程中为了复用、抽象需要沉淀中台能力。

业务中台不仅仅需要关注功能性需求更需要关注5个方向的非功能性需求才能高效稳健的支持业务的发展否则极容易演化成分布式单体。

实现方式

" `. a6 c: X1 Q- x  |0 \% g  

战略上
+ O( ^1 J! J  n   

横向分层分散关注、松散耦合。
      

应用层提供具体业务的API和视图和用户直接交互。

服务层提供业务编排和业务原子能力。

数据层提供存储服务如数据库、缓存、搜索引擎、文件。

纵向分割通常按照不同业务划分专人做专事、不同等级保障。

分布式部署包括服务应用、静态资源、数据存储、计算、配置、锁、文件的分布式。由于通常需要避免单点需要在C和A之间权衡。

战术上
   

集群。负载均衡和失效转移提供并发特效和可用性。

缓存。在数据热点不均匀、数据有一定有效期的情况下使用。

异步。堆积消息避开故障时刻提高可用性、减少rt、削峰。

冗余。包括集群备份、冷热备份、灾备数据中心。

自动化。发布过程、代码管理、安全监测、监控、失效转移恢复、降级、分配资源都可以自动化。

安全措施。密码、验证码、加密、过滤、风控等。

…
3 C, w" e. ~+ }7 ]- e8 l
/ T6 y6 W, i* |" ^

战术上的几种方式可能组合使用
5 _% R& L# `' u7 k9 ?: h7 n
4 {: ~6 H% k8 M/ h! u
详细理论内容可参考大型网站架构

1 W# m# C( G- R" c' c: C
3 `2 `7 u- k8 P$ d具体案例
1 ]# o" X; `/ {5 F  g( V
结合电商商品中台、交易中台、春晚红包的工作经历梳理使用场景


0 I: S' B" t+ k6 b8 L7 C) G性能
缓存
[ol]

分布式缓存。主流的redis的3种集群是电商商品中心各种场景的缓存主力。
  [ol]

主从redis。client 路由。
2 ]; \1 `# M- F( I( {    [ol]

一致性hash路由。商品主库上的缓存用于商详等商品单查。已经成功支持过200+ redis实例抗500w+ qps。

多副本路由。上一条的二级缓存存放热点数据防止单redis和主库单分片被打挂。50个 redis实例可抗100w+ qps。[/ol]

codis。proxy路由。用于C端列表大流量的批量查询通常多集群部署。单集群256主从server+100proxy可抗近千万qps并且可以通过节点的方式最多支持到3000w qps。、

redis cluster。前两者的替代品扩容更加方便。集群规模受限建议最多200 server和2T内存可以通过多集群分片的方式扩展集群的规模。[/ol]

本地缓存。主流Caffeine用于列表场景大内存56G实例抗突发热点保护分布式缓存。

线程缓存。ThreadLocal用于aop带出上下文如商品B端编辑在aop中校验商品状态并把商品数据带到业务逻辑中修改减少查库的次数。[/ol]
异步
[ol]

消息队列。
6 ~' [' l& x) A0 Q0 o3 e  [ol]

消息中间件。春晚红包抢红包实时链路db只记录中奖流水后续发奖通过kafka异步。抢红包需要支持600w tps下游发奖等无法支持并且异步也可以减少用户等待时间能再次摇奖。

事件驱动。用户下单后的预约流程需要商家接单接单等待时间较长。实现为用户申请落库后直接放回后续通知商家流程通过可靠领域事件驱动商家接单之后回调。[/ol]

rpc异步。商品列表聚合素材、标签等数据使用异步dubbo并行调用减少列表渲染时间。

线程池。商品列表的缓存回写通过线程池异步减少为命中缓存时用户请求等待的时间。[/ol]
集群
[ol]

服务层k8s实例的集群化。商品列表场景单机房上千实例可抗300w+ qps并在10ms内返回。单机压力大会导致cpu飙升的长尾。

缓存的集群化。商品列表的缓存集群抗300w+ qps的批量查询流量并保证rt在1ms左右。

持久化存储的集群化。
  [ol]

mysql。
( K7 f2 n. ]  W  Q2 I    [ol]

商品256库256表可以支持百万qps的查询日常流量下商详场景的redis雪崩也可以基本支持业务。

春晚预热的全局预算累计拆分到32个库可支持几十万的写入。[/ol]

hbase。商品列表缓存下的持久化存储支持百万qps的查询。[/ol] [/ol]
代码优化
; d: {, }, c1 B; C( c6 U" M[ol]

多线程。春晚红包下单回滚库存、限购等资源时并行回滚减少用户等待时间。

资源复用。下单页对大ab参数的解析只做一次后续都使用解析后的对象。解析大json有可能占用机器将近一半的cpu耗时。

GC调优。
  [ol]

更换gc方式。商品敏感数据服务由于需要使用本地缓存gc压力大上游50ms经常超时。使用zgc通过损失一定cpu获得1-2ms的gc时间极大的降低了上游的超时率。

调整其他gc参数。[/ol] [/ol]
0 j5 ?9 i' K$ U1 x存储优化
[ol]

存储选型。商品操作日志这种写多读少的场景使用hbase这种追加式的存储做到毫秒级写入。

索引调优。
  [ol]

添加索引减少每次扫描的数据行数从而降低响应时间。
    [ol]

商品的sku包含删除和未删除的sku热门商品修改频繁删除的sku较多导致每次可能需要查到上万sku但实际生效的只有几十上百个。添加商品Id+SKU状态的索引解决这一问题。[/ol]

添加查询条件引导优化器走扫描数据量少的索引。
    [ol]

春晚红包的索引优化。[/ol] [/ol] [/ol]
2 C  c6 Z0 B! e, [: q3 L可用性

分布式场景判断是否可用的一般方式超时
$ o5 E$ a5 @: ]# k( M2 d
6 [4 o2 z' `' w+ I4 t8 Q
集群
1 w: G3 _* @" k[ol]

服务层的无状态化k8s集群。可负载均衡+重试做到失效转移。
. w. b) K" ?% u  [ol]

dubbo调用支持配置retry属性也可二次开发健康度lb从而使得请求最终落到下游的正常实例上。[/ol]

存储层的数据备份。可失效转移。
  [ol]

单主写入
$ M6 X# j; }9 @" f) x    [ol]

同步备份。mysql同步复制

异步备份。mysql异步复制redis主从复制

半同步备份。商品库采用mysql半同步复制主备同步复制主从异步复制主到灾备异步复制是C和A的折中。[/ol]

无主写入。
" i# ^9 }8 d% M% V6 {2 r; \$ H: z6 O8 Q    [ol]

商品中心的缓存采用单机房三集群同步时串行写入异常时跨集群降权重试。[/ol] [/ol] [/ol]
0 L$ _9 d2 y' o2 u多活
[ol]

同城双活异地、跨云多活。
' Q. _" _5 n3 g; [  [ol]

商品中心、交易中心等核心服务均部署两个以上的机房同时提供服务并且定期做切流量演练。[/ol] [/ol]
/ {) X/ p- ]" x" q$ H+ _风险识别
+ n. s9 G5 n% P3 o; t" W3 K- C[ol]

热点流量。
, i' j' m; o8 q6 |6 V  [ol]

业务识别。热点商品通过定时任务拉秒杀服务获取并刷到多副本缓存中用于商品详情页和下单避免数据库被打崩。

系统识别。
; H8 s6 P1 o; O1 U/ D: A    [ol]

商品列表使用caffeine本地缓存通过tiny-lfu识别热点并缓存到本地保护分布式缓存。

商品详情、下单服务使用改造之后的sentinel发现db访问热点并刷到多副本缓存。[/ol] [/ol] [/ol]
分级
; s( q' ?& d* q% ]( t[ol]

高优先级的服务占用更好的硬件资源部署在不同的宿主机上甚至异地容灾。
  [ol]

商品服务独立宿主机和其他服务隔离并做多机房部署和异地灾备。[/ol]

高优先级的场景和其他场景隔离避免被影响。
  [ol]

商品详情的缓存使用独立的redis集群和其他缓存独立。

电商核心的盈利部门广告从单独的商品集群查询商品。[/ol] [/ol]
异步
& x' |% A- |# b( b; v0 F0 `5 k[ol]

方式同上一节中的mq,dubbo。
# U& r2 }6 ~5 F" p' t& S0 R  [ol]

下单流程生成交易快照使用mq+异步dubbo双通道不影响核心的下单链路。[/ol] [/ol]
限流
% J3 l+ h( X5 M" f[ol]

保证有效流量不超过自身的处理能力。分为集群限流和单机限流。几种限流算法。
: S4 `* ^% }* w, X2 d% F  [ol]

集群限流。用存储如redis计数适合流量小、精度高的场景如1w qps左右。

单机限流。本地内存限流适用于流量大精度不高的场景。
    [ol]

商品服务均使用单机限流 。dubbo在filter中用sentinel的滑动窗口每个窗口默认0.5s。[/ol] [/ol] [/ol]
熔断
[ol]

抛弃下游请求。下单页服务对下游的所有依赖如果超过50%会被mesh层熔断。[/ol]
) Z* ^/ v. B: c8 Z* v降级
[ol]

强依赖降级
  

无损降级。如读容灾存储。
    [ol]

交易支付流程如果查询账号服务失败则从容灾的redis中获取账户信息。账号信息每次查询账号服务后更新由于账户变更不频繁读容灾存储基本等于无损降级。[/ol]

有损降级。如异步补偿写。
    [ol]

交易下单流程中如果限购服务异常可以降级成读历史订单后补偿扣限购而不是同步扣限购。可能造成超卖。[/ol]

弱依赖降级可以失败
  

缩短超时时间。交易下单页对于历史留资等若依赖超时时间设置成200ms而不是框架默认的1s

支持丢弃请求。以上的留资服务可以手动降级不去请求。 [/ol]
重试
: M( |+ r6 @' O% Q, R' n7 }3 w[ol]

需要注意
6 s* K) U$ R  {% e; m5 \" I  [ol]

下游保证幂等。

重试的错误类型。网络超时可以重试业务异常需要具体问题具体分析有些异常重试没有意义。
! c' \2 q5 W# h# w$ _    [ol]

某分布式事务组件的思路是一阶段提交二阶段无限重试但是二阶段调下游的入参有问题被拦截无限重试卡住。[/ol]

重试次数限制。过多的重试会造成读或写扩散打挂下游。[/ol] [/ol]
( e! r$ W" R5 U4 p% k# i规范流程
2 v' M+ Z; q) T[ol]

版本管理。分布式服务场景下分支开发、主干发布。
4 e! Z" ]' ]" i  m# l/ F  [ol]

大多数互联网公司的做法开发分支本地调试测试分支发布到测试环境主干分支发布到生产环境

测试分支可以建设泳道减少需求之间的影响但是也可能遗漏多个需求同时修改触发的bug[/ol]

自动化发布、自动化测试。
  [ol]

整个公司使用发布平台发布减少人工操作失误的概率。[/ol]

预发布、灰度发布。
$ J( @0 k9 L0 T& f) L" c  O# [  [ol]

公司所有上线必须走预发验证之后滚动发布。[/ol] [/ol]
0 ]7 l- M, \8 n, Q# `监控告警
[ol]

监控+告警人工介入。如cat可以监控应用并通过电话消息等多种方式触达开发人员及时介入线上故障。[/ol]
$ T: ~2 M" G7 ]' }0 k/ Z; O7 F8 q扩展性
领域建模
[ol]

通过DDD战略层面拆分各个业务域
  [ol]

交易中台拆分成商品、营销、交易、履约、结算5个业务域大多数需求可以闭环在各个业务域内。[/ol]

DDD战术层面搭建微服务。
  [ol]

使用六边形框架搭建微服务。
    [ol]

交易中台的服务使用DDD构建切下游接口的时候只需要对rpc适配层少量代码改动无须修改领域逻辑。[/ol]

领域模型的通用性必要时可分离为业务子域或者基础设施子域。
/ c) e5 w1 `: v) p4 u$ L8 }    [ol]

商品中心的商品扩展属性通过k-v形式存储shema通过groovy脚本校验可以做到不发版迭代业务。已经迭代过数十个需求。

商品详情装修组件也设计为通用的组件+schema+数据的形式支持业务动态配置详情页。

商品消息通过配置化每个业务可以单独订阅感兴趣的组合如只关心商品和SKU的消息。

通用的能力如商品黑名单、商品店铺协议、商品操作日志、计数能力单独抽业务子域其他业务可以复用。[/ol] [/ol] [/ol]
微服务
[ol]

通过微服务分解业务模块。是DDD的技术实现。

微服务之间可以通过多种方式交互
/ L7 L9 ~6 t9 A" R" y' F" M  [ol]

同步的rpc、http调用。

异步的消息中间件、异步rpc。[/ol]

微服务之间的交互协议也是可扩展的
1 a/ j6 a/ w8 D! Y: Q( t" `  [ol]

json, hessianthrift等序列化方式

hbase等nosql存储[/ol] [/ol]
* Q! t" g3 J+ o开放平台
[ol]

注重对外部开发者的扩展性。
% q& A0 t5 _4 s8 ~  [ol]

交易中台会定义一套三方下单的接口并公开在开平文档中供应商提供url和key接入。[/ol] [/ol]
8 e7 t8 t4 D, @4 z# ~伸缩性
分割
[ol]

水平方向按照业务处理流程分离比如API层、编排层、原子能力层、中间件层、存储层。
5 v2 l/ x3 C6 l! Z( \2 W1 w3 ~$ D  [ol]

交易中台的服务层无状态可以快速扩容。有状态的存储层相对伸缩性较差。[/ol]

垂直方向
  [ol]

按照业务模块分离。
    [ol]

交易中台新建设预约能力和正向、履约独立不用再对现有流程进行修改。

商品中心的库存服务单独拆分和商品数据动静分离。商品可以往大流量支持场景使用缓存伸缩库存往小流量写场景堆存储伸缩。[/ol]

按照数据冷热程度分离。
    [ol]

商品库会hive表捞删除1年的商品通过kafka推给业务删除商品库的相关数据并存储到hbase中hbase提供只读能力。[/ol] [/ol] [/ol]
集群
5 u* p7 h  Q9 W; \& I# w[ol]

服务层的无状态化k8s集群。可扩容支持大促流量负载均衡业务无感知。
  [ol]

双11等大促时商品中台需要两倍以上的k8s实例做压测和保障可扩容并依赖dubbo的负载均衡支持业务。[/ol]

有状态的存储集群可以扩容并通过2种方法识别到数据在哪个分片上。
2 _3 D) C& I3 m$ n0 T2 I" U  [ol]

元数据服务器。
. F" P: q( T5 |7 B/ C+ ?5 H/ u    [ol]

商品中心使用hbase依赖meta节点获取rowkey的分布扩容无须业务感知。

redis cluster的槽迁移依赖槽的路有扩容同样无须业务感知[/ol]

路由算法。商品中心客户端路由缓存使用一致性hash扩容通过平台配置业务无须修改代码[/ol] [/ol]
安全性
6 H3 J$ r- i% ~+ e校验
[ol]

字符串强校验。不拼接字符串作为sql入参
2 N: F7 Q. V% T# a0 Q2 i  [ol]

下单流程对手机号会进行正则校验防止sql注入。[/ol] [/ol]
加密
[ol]

单向hash加密MD5、SHA对称加密DES、RC非对称加密RSA等。
  [ol]

订单的用户信息属于用户隐私需要通过AES加密之后存储在DB防止泄漏。[/ol] [/ol]
风控
[ol]

规则引擎+统计模型识别黑产。
9 d" ?$ G. x+ y8 C  [ol]

交易中台下单前过风控拦截下单后、支付前后通知风控分析用户行为。[/ol] [/ol]
. z+ v. d- u% B0 T# r* D3 E" t               
               
               
$ {5 u* ?- l& [7 \; D本文来源csdn，由Java吧转载发布，观点不代表Java吧的立场，转载请标明来源出处：https://www.java8.com