中台架构- 可扩展实现的方式

背景和价值
动态植入扩展点实现

背景和价值

从业务视角来看，中台架构要支持业务灵活扩展

业务流程可编排。使用企业级架构通用流程建模，领域模型设计等
审批流可编排
流程引擎
而流程引擎实现了将多个业务参与者之间按照某种预定义的规则进行流转，通常需要涉及到角色信息。
简单来说就是，流程引擎主要解决业务在不同角色之间的流转问题，如请假流程，审批流程，往往要经过多个角色。规则驱动角色流转。
能力可扩展/定制（微内核架构）
在电商交易与履约业务架构设计中，扩展点技术的核心价值是在不修改核心业务流程代码的前提下，通过 “预留扩展接口 + 动态加载扩展实现” 的方式，适配不同场景的差异化需求

在扩展点技术中，除了策略模式（Strategy Pattern），还有多种设计模式可用于实现不同场景的扩展需求。这些模式的核心目标都是在不修改核心流程的前提下，通过“预留扩展接口+动态加载实现” 支持业务差异化，但适用场景各有侧重。以下是常见的扩展点模式及电商履约场景中的应用示例：

1. 观察者模式（Observer Pattern）

核心思想：定义对象间的一对多依赖关系，当核心对象状态变化时，所有依赖它的“观察者”对象会被自动通知并更新。
扩展点应用：核心流程触发事件时，允许扩展模块“订阅”并执行自定义逻辑（无需核心流程知道具体观察者）。
电商场景示例：

订单创建成功后，需要触发多种后续操作（如通知仓库、发送短信给用户、同步至ERP系统、更新统计数据等）。
核心订单流程只需定义“订单创建完成事件”，各扩展模块（仓库通知模块、短信模块等）作为观察者订阅该事件，实现解耦。
新增需求（如订单创建后同步至财务系统）时，只需新增一个观察者订阅事件，无需修改订单创建核心代码。

2. 模板方法模式（Template Method Pattern）

核心思想：在父类中定义核心流程的骨架（模板），将流程中可变的步骤延迟到子类中实现（扩展点），确保核心流程稳定，同时允许子类定制部分逻辑。
扩展点应用：核心流程固定，仅部分环节需要差异化扩展（“钩子方法”作为扩展点）。
电商场景示例：

订单履约的通用流程为：校验订单合法性 → 扣减库存 → 生成物流单 → 通知用户，其中“扣减库存”和“生成物流单”在不同业务模式下有差异（如普通订单vs预售订单）。
父类AbstractFulfillmentTemplate定义流程骨架，将deductStock()和generateLogisticsOrder()声明为抽象方法（扩展点）。
子类NormalOrderFulfillment和PresaleOrderFulfillment分别实现各自的库存扣减和物流单生成逻辑，核心流程复用父类模板。

3. 装饰器模式（Decorator Pattern）

核心思想：动态地给对象添加额外功能，通过“包装”原有对象实现扩展，不改变原有对象的结构。
扩展点应用：在核心流程的基础上，按需叠加附加功能（如日志、监控、权限校验等横切关注点）。
电商场景示例：

订单支付流程的核心逻辑是“调用支付网关完成扣款”，但不同场景可能需要附加功能：生产环境需记录支付日志、风控场景需添加风险校验、VIP用户需优先处理。
核心支付类PaymentService实现基础扣款逻辑，扩展点通过装饰器实现：LogDecorator（包装支付服务添加日志）、RiskCheckDecorator（包装添加风控校验）。
调用时根据场景动态组合装饰器（如new RiskCheckDecorator(new LogDecorator(paymentService))），无需修改核心支付逻辑。

4. 适配器模式（Adapter Pattern）

核心思想：将一个类的接口转换成客户端期望的另一种接口，使原本因接口不兼容而无法协作的类可以一起工作。
扩展点应用：对接第三方系统（接口格式、协议不同）时，通过适配器作为扩展点适配核心流程。
电商场景示例：

订单履约需对接多个物流商（顺丰、圆通、京东物流），但各物流商的“创建物流单”接口参数和格式不同（如顺丰用orderNo，圆通用waybillCode）。
核心流程定义统一的LogisticsAdapter接口（含createWaybill(Order order)方法），为每个物流商实现适配器（如SfLogisticsAdapter、YtoLogisticsAdapter），在适配器内部转换参数适配第三方接口。
新增物流商时，只需新增对应的适配器，核心履约流程无需修改。

5. 职责链模式（Chain of Responsibility Pattern）

核心思想：将多个处理对象连成一条链，请求沿链传递，直到被某个对象处理。每个对象可决定处理请求或传递给下一个对象。
扩展点应用：核心流程需要多步骤校验/处理，且步骤可动态增减或调整顺序（每个步骤作为扩展点）。
电商场景示例：

订单提交前的校验流程：需校验商品状态、库存、用户权限、价格有效性、风控规则等，不同订单类型（如秒杀单、普通单）的校验步骤不同。
定义OrderValidator接口（含validate(Order order, Chain chain)方法），每个校验逻辑作为一个处理器（如StockValidator、PriceValidator），并组成链条。
核心流程只需启动链条，新增校验规则时只需添加新的处理器并加入链条，无需修改核心校验逻辑。

6. SPI 机制（Service Provider Interface）

严格来说是一种服务发现机制，但常被用作扩展点实现方式：通过配置文件声明接口的实现类，运行时动态加载，实现“接口与实现分离”。
扩展点应用：框架级扩展（如数据库驱动、日志框架），允许第三方提供实现。
电商场景示例：

电商平台支持多地区税费计算（国内、跨境、保税区税率不同），核心流程定义TaxCalculator接口，各地区税率计算作为扩展实现。
在META-INF/services目录下配置实现类（如com.xxx.tax.ChinaTaxCalculator、com.xxx.tax.CrossBorderTaxCalculator），核心流程通过ServiceLoader动态加载对应实现。
新增地区税率时，只需提供实现类并配置，无需修改核心计税流程。

不同模式的选择依据

模式/机制	核心场景	电商履约典型应用
策略模式	同一操作的不同实现（择一执行）	不同商品类型的订单校验（如实物vs虚拟）
观察者模式	事件驱动的多扩展（一对多通知）	订单状态变更后的多系统同步（仓库、ERP、短信）
模板方法模式	核心流程固定，部分步骤可变	履约流程骨架固定，子类实现差异化步骤（如预售vs普通订单）
装饰器模式	动态叠加附加功能（横切关注点）	支付流程添加日志、风控等附加逻辑
适配器模式	第三方接口适配	多物流商接口适配（统一核心流程调用方式）
职责链模式	多步骤校验/处理（顺序可调整）	订单提交前的多规则校验（库存、价格、风控）
SPI机制	框架级、多实现的服务发现	多地区税费计算、多支付渠道适配

这些模式的核心是将“不变的核心流程”与“可变的业务差异”分离，通过扩展点让系统既能保持稳定性，又能快速响应业务变化。在实际架构中，常结合多种模式使用（如策略模式+SPI机制实现动态加载策略，职责链+观察者模式处理复杂校验与事件通知）。

动态植入扩展点实现

方式二：Spring 类路径扫描

步骤：

在 Spring Boot 中通过 @ComponentScan 扫描钩子实现类所在的包。
将钩子实例注册为 Spring Bean：

@Configuration
@ComponentScan(basePackages = "com.example.hooks")
public class HookConfig {
    
    @Bean
    public List<OrderHook> orderHooks() {
        return Arrays.asList(
            new EnterpriseOrderValidationHook(),
            new RetailOrderDiscountHook()
        );
        // 或通过反射动态加载（推荐）
        // ClassPathScanningCandidateComponentProvider provider = ...;
        // return provider.findCandidateComponents("com.example.hooks").stream()
        //         .map(c -> (OrderHook) c.getBeanDefinition().getBeanClass().newInstance())
        //         .collect(Collectors.toList());
    }
}

4. 注册钩子到中台系统
将动态加载的钩子实例保存到中台系统的管理器中，供后续调用：

public class OrderService {
    private List<OrderHook> hooks;
    
    @Autowired
    public OrderService(List<OrderHook> hooks) {
        this.hooks = hooks;
    }
    
    public void createOrder(Order order) {
        // 执行所有钩子的 beforeCreateOrder 逻辑
        for (OrderHook hook : hooks) {
            hook.beforeCreateOrder(order);
        }
        
        // 核心订单创建逻辑...
        
        // 执行所有钩子的 afterPaymentSuccess 逻辑
        for (OrderHook hook : hooks) {
            hook.afterPaymentSuccess(order);
        }
    }
}

配置驱动扩展

规则引擎

规则引擎通常是嵌入在应用程序组件中的，实现了将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策。接受数据输入，解释业务规则，并根据业务规则做出业务决策。简单来说就是，规则引擎主要解决易变逻辑和业务耦合的问题，规则驱动逻辑。以前项目内写死在代码里的逻辑用规则引擎可以提出来，随时热变更。

https://www.cnblogs.com/aibi1/p/18736933

配置表

自己通过配置表维护业务场景和业务活动/任务/步骤的编排关系。

比如订单评审业务活动下的规则有：通用校验，额度占用，分货占用，推送履约系统。这些规则组件是可编排的
自己实现
通过组合模式+策略模式实现
通用校验一个基类，一些扩展类。额度占用，分货占用，推送履约系统也是类似

注解驱动的钩子（AOP方式）

利用Spring AOP在方法前后插入钩子逻辑，适合无侵入式扩展。

// 定义注解
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface Hook {
    String value(); // 钩子名称，如 "payment_before"
}

// 核心业务代码
@Service
public class PaymentService {
    @Hook("payment_before")
    public void processPayment(PaymentRequest request) {
        // 核心支付逻辑...
    }
}

// AOP切面实现钩子
@Aspect
@Component
public class HookAspect {
    @Around("@annotation(hook)")
    public Object around(ProceedingJoinPoint joinPoint, Hook hook) throws Throwable {
        // 执行前置钩子
        executeHook("payment_before", joinPoint.getArgs());
        
        Object result = joinPoint.proceed();
        
        // 执行后置钩子
        executeHook("payment_after", result);
        
        return result;
    }

    private void executeHook(String hookName, Object... args) {
        // 动态查找并执行所有注册的钩子实现
        List<HookHandler> handlers = HookHandlerRegistry.getHandlers(hookName);
        for (HookHandler handler : handlers) {
            handler.handle(args);
        }
    }
}

OSGI

Spring Plugin

利用Spring的@Conditional和动态Bean注册。

posted @ 2025-03-01 18:10 向着朝阳阅读(60) 评论(0) 收藏举报

刷新页面返回顶部

aibi1