山东住房建设部网站,网站建设课程设计报告总结,北京网站建设分析论文,网站流量数据简介#xff1a;NBF是阿里巴巴供应链中台的基础技术团队打造的一个技术PaaS平台#xff0c;她提供了微服务FaaS框架#xff0c;低代码平台和中台基础设施等一系列的PaaS产品#xff0c;旨在帮助业务伙伴快速复用和扩展中台能力#xff0c;提升研发效能和对外的商业化输出。…简介NBF是阿里巴巴供应链中台的基础技术团队打造的一个技术PaaS平台她提供了微服务FaaS框架低代码平台和中台基础设施等一系列的PaaS产品旨在帮助业务伙伴快速复用和扩展中台能力提升研发效能和对外的商业化输出。事件中心就是NBF系列技术产品中的一员。本文首先介绍事件驱动架构的概念及适用场景然后会介绍事件中心产品的设计和实现。 作者 | 林晖 来源 | 阿里技术公众号
一 业务背景
电商平台供应链的业务场景非常复杂技术中台需要支持非常复杂且不断变化的业务需求构建了数量繁多且紧密耦合的业务链路为技术架构的维护带来了压力。
1 问题描述 上图是一个典型的业务架构A域是上游域B域和C域是下游域。A域在收到外部调用请求时首先同步调用B域的服务接口完成同步业务逻辑然后发送消息通知到MQ。C域异步消费消息后反向调用A域的接口查询详细信息完成异步业务逻辑。
这种架构的问题包括
A域强依赖B域的接口B域接口变动会导致A域调用失败而A域无法管控B域的接口变动C域收到消息后需要反查A域的接口对A域形成了双重依赖A域接口和消息格式的任何变动及不稳定性都会影响C域A域的消息和接口都是瞬时数据两者由于时间差可能不一致增加了C域处理的复杂度例如C域收到的消息是单据已创建调用接口时查到该单据已完结A域需要保证同步调用和消息通知的一致性包括MQ不可用等情况发生时的容灾处理
面对这些问题我们希望应用事件驱动架构的特性来解耦子域降低业务链路复杂度构建稳定并向前兼容的事件契约从而提升全域的稳定性。
2 事件驱动架构的应用过程
重新梳理全链路业务流和业务活动建立统一的标准语言定义标准的事件格式和通用基础字段各域定义包含完整业务语义、自闭包、多租户的领域事件开发并接入一套适应供应链业务特点的事件系统NBF事件中心
3 关于NBF
NBF[1] 是阿里巴巴供应链中台的基础技术团队打造的一个技术PaaS平台全称是New-Retail Business Factory她提供了微服务FaaS框架低代码平台和中台基础设施等一系列的PaaS产品旨在帮助业务伙伴快速复用和扩展中台能力提升研发效能和对外的商业化输出。事件中心就是NBF系列技术产品中的一员。
本文首先介绍事件驱动架构的概念及适用场景然后会介绍事件中心产品的设计和实现。
二 什么是事件驱动架构EDA
1 领域事件
很多同学会将事件和消息混淆。在业务系统中事件指的是领域事件而消息可以是任意数据或数据片段。领域事件的特点包括
与服务接口一样有完整的schema并保证schema向前兼容是业务流程的一部分由业务动作触发包含了完整或部分但有独立语义的业务状态变化事件消费者接收到事件后相应修改自身的业务状态并按需发出新的事件消费者需要保证所有事件最终消费成功否则会导致业务流程不完整事件需要持久化保存并长期归档方便业务同学查询、恢复中断的业务流程、重新发起业务流程等也方便风控及财务分析同学做离线分析。
2 事件驱动架构的概念
和很多架构名词类似事件驱动架构并没有一个明确的定义和能力范围。Martin Fowler在2017年的文章[2] 中描述了与事件驱动架构相关的一些主要模式。在本文中事件驱动架构的概念具象为由领域事件驱动的业务流技术架构。每一个领域事件都对应一个业务流中的具体活动如采购单建单而事件就是活动发生导致的结果如采购单建单完成事件事件内容就是活动导致的完整状态变化如采购单子单列表。
3 事件驱动架构的优点
在Fundamentals of Software Architecture[3] 以及Microservices Patterns[4]等书中描述了事件驱动架构的一些明显特点我们总结为以下几项
高度解耦广播能力纯异步调用Fire and Forget灵活扩展高处理性能
4 事件驱动架构能解决什么实际问题
下面我们举几个例子来描述事件驱动架构的解耦和广播能力如何帮助解决现实工作中的问题
解耦能力 在基于请求/响应方式的服务化架构中上游服务按照约定的RPC接口调用下游服务这样有一个比较严重的问题上游服务作为数据例如业务单据的生产者强依赖了作为数据消费方的下游服务所定义的接口导致上游服务自身无法沉淀接口和数据标准。 一种更合理的方案是依赖倒置由上游服务定义SPI下游服务实现SPI这样上游服务终于有机会沉淀出自身的接口和数据标准不再需要适配各个下游服务的接口而是由下游服务的开发者按照接口文档来做实现。但这种设计仍然无法解决运行时上游服务仍然依赖下游服务的问题下游服务的可用性、一致性、幂等性能力会直接影响上游服务的相关指标及实现方式需要上下游服务开发者一起对齐方案在出问题时一起解决。 使用事件驱动设计可以实现契约定义和运行时的全面解耦上游服务可以沉淀自己的事件契约在运行时无论是上游服务还是下游服务都只依赖事件Broker下游服务的可用性和一致性等问题由事件Broker来保障。
广播能力
在供应链中台这样复杂的微服务架构中关键的上游服务往往有多个下游服务上游服务一般需要顺序或并发调用所有的下游服务来完成一次完整的调用。 上游服务的开发者会面临多个难题
服务的可用性会被下游服务影响服务的RT自己无法控制下游服务之间的一致性如何保障如何实现一套可靠的重试机制
而下游服务的开发者也有自己的问题:
每接入一个上游服务都需要跟服务开发者排期谁来答疑什么时候联调什么时候上线上游流量如何做过滤高峰流量是否能抗得住如何满足上游服务的可用性及RT要求
使用事件驱动架构天然可以避免上述问题 上下游完全解耦上游服务只要保证将事件成功发送到Broker无论有几个下游消费者都不会影响自身的RT也不需要考虑下游服务之间的一致性下游服务在接入新的事件时只需要在事件管理服务中走完订阅审批流不需要等待事件发布者排期和联调通过事件Broker提供的事件过滤能力下游服务只需要消费与自身相关的事件流量例如天猫超市的计费服务只需要消费tenantId为天猫超市的采购单创建事件而不需要消费银泰租户的采购单创建事件通过事件Broker提供的事件存储能力和重投能力即使上游服务发送的事件流量超过了下游服务的处理能力也只会影响下游服务的消费延迟不会导致大量请求失败的情况。
5 事件驱动架构不适合什么场景
强依赖Response的场景例如单据查询、商品查询对全局处理延迟敏感的场景例如游戏、搜索要求服务之间保持强一致性的场景
三 事件中心的功能设计
作为面向中台的事件中间件事件中心集成了消息中间件MetaQRocketMQ初始使用体感也与MQ很像但事件中心有很多不同的功能设计
完善的权限控制支持事件契约定义以及运行时合法性校验支持大事件发送和消费10MB或更高支持长期的事件历史查询、事件索引查询如单据编号、sku、事件重投支持消费周期很长的事件如需要几个月才能完结的入库单所有事件及消费记录的完整归档以OpenAPI的形式开放了事件查询、事件重投等运维态的功能方便被其他系统集成。
四 事件中心的运行时架构
事件中心运行态主要由以下部分组成
1、事件中心服务/SDK
a) SDK包含事件收发的主要逻辑支持事务发送和普通发送支持事件校验、压缩、本地备份
b) Tunnel Service一层很薄的数据库代理服务支持按应用、事件、场景、IO维度的限流支持数据库快速灵活扩容
c) Index Service事件索引服务通过精卫DataX获取Binlog解析为索引后写入索引表Lindorm。
2、阿里中间件
a) DiamondNacos包含应用相关的全部配置信息如发送、订阅关系、事件定义、中间件配置等
b) SchedulerX调度SDK执行事件重新发送、重新消费、事务异常状态问询
c) MetaQ主要的事件收发管道
d) TDDLRDS事件内容及消费记录存储
e) 精卫用于生成索引、计算延迟等异步处理逻辑
f) Lindromserverless用于存放事件外部索引serverless模式支持按量付费和弹性扩容性能比较稳定。
下图为简化的运行时架构图图中蓝色线条表示事件的正常收发链路事务发送红色线条表示事件的异常处理链路。 1 事件发送与消费流程
事件结构 运行时的一条事件实例由三部分组成
1、事件ID全局唯一格式为“逻辑库编号_月内发送日期_uuid”例如01_11_f75ec4fb347c49c4bc3e93xxxxxxxx其中逻辑库编号用于逻辑库路由日期用于事件清理
2、事件Head包含事件元信息如trace信息、发送者信息、事件大小、MetaQ信息等参考示例 3、事件BodyJSON格式包含由用户已定义的事件内容事件内容要符合事件定义契约否则会被拒绝发送。
运行时的事件可能有多个消费方每个消费方会产生一条消费记录消费记录包含
事件ID消费信息消费状态、消费次数、下次消费时间等
事件发送流程
事件中心支持事务发送和非事务发送两种模式使用状态机驱动API设计与MetaQ的API基本一致。以下以事务发送为例介绍发送流程由于非事务发送的流程更简单所以不再详细介绍。
1事务发送状态机 2事务发送时序图 3异常状态事务问询 事件消费流程
事件消费流程也使用状态机驱动API相比MetaQ有一些不同
不需要再调用subscribe topic新增消费过滤器EventFilter支持按照租户、业务流、事件维度做过滤支持不同的事件使用不同的Listener消费
1事件消费状态机 2重试周期
事件进入消费失败状态后事件中心会周期调用用户Listener重新消费消费周期以5s起始指数增加最多重试15次最大为5 * 214 81920秒约22小时。
3事件消费时序图 2 事件存储
数据表
事件中心使用了32分库的TDDL按照HASH(事件ID)做分库每个库上有以下几张表
事件主表包含发送者信息、事件信息以及普通事件的事件体事件消费记录主表包含消费者信息、消费状态以及重新消费信息与事件主表通过事件ID关联大事件主表包含大事件体与事件主表通过事件ID关联事件天表表结构与事件主表相同存放消费完毕的事件消费记录天表大事件天表
事件生命周期
新写入的事件和消费记录会进入主表当事件写入超过1天且事件的所有消费方都消费成功后事件及所有消费记录会从主表移动到天表中当事件某个消费方需要重新消费之前消费成功的事件时事件及所有消费记录会从天表移回到主表中每天的某个时间事件清理服务会将7天前的那张天表清空例如今天是2月11号那么就会清空2月4号的所有天表。
3 外部索引
事件发送历史列表、事件索引查询和事件重投是事件中心运维平台的主要功能。其中索引查询功能的查询速度快、查询结果准确用户反馈一直比较好。 索引配置
用户在修改事件定义时可以为其中任意基础类型字段配置为“查询字段”事件中心会在运行时解析该字段的值并创建索引一个事件中的每个查询字段都会对应一条索引即使没有配置查询字段也会生成一条包含时间戳的索引用于已发送事件的排序和分页。 索引结构
事件中心的索引为KV结构使用Lindorm的宽表存储按使用场景分为两种类型
不包含查询字段的索引Key格式为 HASH(租户id_事件code)_env_发送时间差值_事件IDValue为事件ID、事件头包含查询字段的索引Key格式为 HASH(租户id_事件Code_字段路径_索引值)_env_发送时间差值_事件IDValue为事件ID、事件头
其中
发送时间差值 Long.MAX_VALUE - 发送时间毫秒数用于按发送时间倒序展示字段路径是json path格式例如 $.bizNo
查询性能
通过目前事件中心运维平台99%的查询都可以在毫秒级别返回结果Lindorm索引行数在十亿级别。
五 总结
本文介绍了事件驱动架构在供应链执行链路的应用背景和实践过程并介绍了NBF事件中心产品的设计和部分实现。目前事件中心每日事件发送量峰值在千万级别平稳度过了双11、双12、年货节等流量高峰。
原文链接
本文为阿里云原创内容未经允许不得转载。
