Debug客栈

Recent content on Debug客栈

马上订阅 Debug客栈 RSS 更新: https://blog.debuginn.com/index.xml

Phoenix框架 从0到1设计业务并发框架 怎么组织设计一个框架

2024年3月18日 20:00
Featured image of post Phoenix框架 从0到1设计业务并发框架 怎么组织设计一个框架

上篇文章主要讲了设计 Phoenix 框架前的遇到的问题和设计框架的思路 《 Phoenix 框架 从0到1设计业务并发框架 小米商城产品站革新之路》，本篇文章主要讲一下如何设计框架的。

不死鸟并发框架，是自动构建有向图按照深度进行构建并发组并进行并发调用结果的框架。

产品站业务静态接口与动态接口都需要调用大量的后台服务进行获取数据进行业务编排，而各个并发调用之间又相互存在依赖，采用并发组设计拆解依赖，同时并发控制调用，BO to DTO 采用统一的 Transfer 层进行设计，开发人员只需要关系定义每次调用事件的 Task 和 Transfer 代码逻辑的书写，直接返回业务数据。

分层设计

名词解释

  • PhoenixFramework 不死鸟（凤凰）框架，此业务并发框架的名称；
  • Task 在业务并发中定义一次调用，可以是 HTTP、DUBBO 或者是 Redis 获取、MySQL 读库操作；
  • Transfer 在业务定义中是一个子业务模块的转换逻辑将 BO 数据转换为 DTO 数据；

Task 与 Trans 注解

怎么定义 Task

在框架设计之初，我们内部有两种方案，一种是继承抽象类实现的方式，Task 通过继承实现 PhoenixTask 类实现定义 Task，另外一种是采用注解的方式，将每个 Task 都定义成具有强约束的 Task ，并且把详细的描述信息在注解中定义，给开发人员一目了然的设计思路。

经过内部讨论，我们选择了 Java 优秀的语言特性，注解的方式声明定义 Task ，这样的定义使得代码简洁明了，也有利于通过 Spring Bean 收集工具来收集我们的定义。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

/**
 * PhoenixTask
 * 任务注解
 *
 * @author debuginn
 */
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
public @interface PhoenixTask {
 String taskName(); // 任务名称 
 String[] beforeTaskName() default {}; // 前置任务 
 String[] filterPlatform() default {}; // 过滤渠道，黑名单 
 String[] taskBoName(); // 任务生成的 BO 数据 用来校验冲突 
}

PhoenixTask 注解定义非常简单：

  • taskName用来标识任务名称，采用枚举，强制约束命名的唯一；
  • beforeTaskName前置任务，前面讲到每个任务都是一次事件，区分前置任务是需要在并发调用的时候等待结果的返回，之后用来作为此 Task 调用的前置参数；
  • filterPlatform 过滤渠道，也就是黑名单的功能，但请求渠道在 Task 中声明了黑名单，在并发执行的时候就自动屏蔽掉执行；
  • taskBoName任务转化为 BO 的数据，通过接口调用或者中间件获取数据，转化为 Transfer 层使用的数据，在框架层做数据参数校验；

怎么定义 Trans

Trans 是 Transfer 的简称，同样和 Task 设计一样，也是采用注解的方式定义：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

/**
 * PhoenixTrans
 * 业务编排注解
 *
 * @author debuginn
 */
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
public @interface PhoenixTrans {
 String transName(); // 业务编排块名称...
剩余内容已隐藏
查看完整文章以阅读更多
查看完整文章