基础业务集成开发平台(BusinessWorks) - 概要设计篇

Businesworks的设计目标是为复杂业务系统提供平台化的底层支持，所谓平台化，就是对业务开发能以扩展，隔离的方式推进，驱动业务快速支持。

目前阿里很多的业务系统随着业务支持的增加，慢慢发展成为一个庞大的铁板一块式monolithic(铁板一块式) 风格的强耦合系统，系统本身可能经历一些重构和优化，满足新业务发展。但整体上还是为了快速的满足业务需求，在主流程上打补丁的方式，对业务的响应能力越来越差。于是平台化被提上日程，希望重新审视系统的架构设计，使架构不成为业务快速发展的瓶颈，并且进一步促进业务的快速开展。

这类业务系统的平台化对架构的需求有一些基本共性，Ali-Businessworks目标就是为了给业务系统提供平台化的基础框架，专门为复杂业务系统而设计，达到以下设计目标：

1. 业务和平台分离。
   平台将不关心具体的业务，只通过抽象统一的模型去完成业务逻辑。平台提供定制扩展机制，方便业务方通过定制扩展开发实现自己的业务需求。
2. 业务隔离
   业务方将作为平台的ISV(Independent Software Vendors)，通过交易平台，设计开发自己的业务。各业务方完全隔离，如果需要对方提供的服务，该业务方可以通过平台注册提供服务。对于调用者来着，这互相彼此完全透明。业务方只和平台打交道。
3. 变化和实现分离
   在复杂业务平台系统中，业务变动需求频繁，比如大促期间，招商平台需要对玩法，招商流程等进行快速调整。因此我们需要把业务变化通过规则引擎管理起来，实现变化与实现分离，通过规则引擎去快速响应需求变化而不是硬编码实现，从而提高业务服务能力和系统稳定性。
4. 职责功能分离
   系统实现通过plugin形式实现，通过在平台的注册提供服务，形成微服务架构，减少系统之间耦合，使系统实现简明规范，并且系统之间易于通过事件驱动方式协调，提高系统性能和稳定。

Businessworks的设计思想基于一下三篇ATA：

1. 《从Eclipse平台看交易平台化》，强调微内核和扩展机制实现
2. 《Google Guice平台模块化开发的果汁》，讨论平台的模块化开发,强调业务隔离，松耦合。
3. 《平台化是舞台，流程编排就是导演一场戏》 ，讨论平台的服务流程编排

Businessworks就是基于这三篇文章的一个full story的实现， 定位复杂业务平台的基础架构，后续会以内部开源的方式进行迭代开发。

1. 平台架构

平台架构将采用微内核和插件扩展的架构，通过模块化技术，将平台的能力分层次透出。首先这个平台需要一个稳定的微内核Runtime，提供平台核心的能力，如扩展机制，插件模块管理等。在这个内核之上，平台提供一个基础集成平台，用于协调平台各组件协作，流程管理等。这个基础平台和微内核将构成平台的基石，然后在这些基础上，我们将构建业务领域平台，在这一层，定义业务领域相关的模型，功能点，业务原型等。最后业务方可以方便的利用平台的能力，构建自己特定的业务，满足业务需要。

平台自身成为一种运行时容器，为组件提供底层服务。而平台本身不具备任何面向用户的业务功能。 这个架构平台类似J2EE应用服务器，平台会定义类似J2EE规范的基础平台规范，基本功能组件用来定义扩展容器的能力，同时这些基本组件可以方便的扩展开发。各个业务方可以在平台规范下开发自己的业务模块，以类似J2EE应用包的形式部署在平台容器内，最终各个业务方在平台基础上构建一个灵活强大的业务系统。

同时通过分层设计，使得平台的建设开发和业务的开发独立开来，避免业务方代码影响平台，也是业务方以扩展开发的方式推进，保证业务之间的隔离，从而保障整个平台的稳定，更有效的提供对业务开发的支持效率。

2. 平台设计

在这一节，我们将分成讨论上面架构中的设计细节。主要分为基础平台设计，基础集成平台设计，业务领域平台设计，业务子系统设计，以及元数据和运维平台的设计。

2.1 基础平台

作为平台的微内核，主要提供接口扩展，模块，插件等基础功能。微内核的实现必须精简，小而美，对第三方依赖尽量减少，开发一个稳定轻量级的实现。

一个微内核意味着在这一层只提供核心的功能，作为一个可扩展的架构，这一层的目标是为提供扩展机制，同时对上层功能开发提供组件模块化支持，提供容器管理注册能力。

2.1.1 对接口的扩展能力（IAdaptable）

当平台的核心接口以API服务的形式暴露给上层应用时，某种程度就是对依赖应用的一种契约，这些接口必须保证能稳定提供服务， 对这些接口的修改不应该导致强迫依赖应用去修改， 但同时，接口因为平台的发展，需要提供更多的能力。为了满足平台能力扩展和对外提供稳定服务的双重要求，我们需要一种介质能对接口的行为进行动态的扩展，在不修改核心接口的前提下，利用扩展机制，扩展接口的行为，满足平台发展的需要。

为此，我们将设计一个IAdapatable接口， 用来满足接口扩展的需要。 同时平台需要对扩展接口提供注册管理功能，接口扩展通过平台注册后，平台会将对应扩展通过扩展查询机制，返回给调用者。

IAdapable接口来自Eclipse的实现方式，当一个接口声明实现IAdapter接口时，就代表这个接口可被扩展。

当一个接口需要扩展新的行为时，我们为新的行为定义一个新的接口。 然后通过IAdapterManger进行注册管理。 平台通过一个IAdapterManger的唯一实例会扩展提供一个类似注册表的实现，保存被扩展接口和扩展接口的注册信，从而给上层调用完成注册扩展，同时平台通过该注册信息，代理返回调用方期望的接口扩展实现。

IAdapterFactory是IAdapter的工厂方法，在这个工厂方法实现里，可以对多个接口进行扩展配置。

这个单例类作为平台的入口实现，用来管理平台的全局信息。AdapterManger是平台维护的一个关于接口扩展管理的实现。所有的Adapter实现通过AdapterManger提供的方法注册，查询，从而提供给平台基础的接口行为扩展能力。

2.1.2 提供模块化功能（Module）

对于平台来说，将系统的功能通过模块来定义功能的边界，模块之间相对独立。模块作为平台功能的组成的基本形式，通过预定义配置和运行时配置来完成平台的组装。

模块的具体实现将利用Guice的Module功能，完成配置信息和绑定各接口的特定实现。平台启动后，通过各种途径将相关模块整合起来，构建Guice Injector, 来完成将模块定义的实通过依赖注入的方式，快速构建起来，从而创建一个复合的模块系统。

平台利用Guice实现的模块模块系统中会涉及到以下概念：

2.1.2.1 模块元数据（Module Metadata）
ModuleMetaData:{nameapace(命名), type(类型), setting(配置)}

平台会利用模块元数据对模块进行管理。模块作为平台的基本功能单位，我们将为此设计一个多维度管理方式。

模块的命名空间用来表示模块在复合模块系统中的唯一标识定位，通过name可以快速知道他所属的模块层级,命名格式为：module://{system|integration|trade|business}/{parent_module}/{module_name}
模块类型用来标明模块的类型，比如系统模块，领域模块，还是业务扩展模块，每种不同类型模块，平台可以给予不同的能力控制。

Setting是模块的配置信息，读取自预定义配置或者运行时候配置，可以动态的对模块进行控制管理。

2.1.2.2 模块命名空间（Module Namespace）

多个模块基于他们在源代码树或者代码中的调用情况被放进了不同的命名空间中。不同的侧面，诸如插件，监控，环境设置服务是分割的功能实体，他们之间没有模块层面的依赖。模块可能已经太过庞大或者难以复合使用的将会被进一步分割成嵌套命名空间中的稍小的模块。

这样平台的功能和结构便可以通过: {Namespace：Module Name： Bound Class}清晰管理起来。

2.1.3 提供插件机制（Plugin）

在前面接口扩展，模块化基础上，平台已经具有了灵活扩展的能力，但是这种扩展能力是在平台代码的基础上通过增加新的类来实现的。对应一个平台来说，我们需要更加灵活的开发方式，让第三方团队可以跟方便的开发平台业务功能，这需要提供一种插件的方式，我们希望能够实现类似eclipse的插件机制。业务方提供一个压缩包，这个插件包有约定的目录组织方式，有一个描述插件的plugin定义文件(plugin.xml)。平台启动后，通过扫描classpath下的plugin.xml文件，得到plugin的实现类名，然后去启动执行，将plugin的功能加入到平台里。

• 插件的定义

  • 插件主要提供模块的扩展和配置的扩展，如plugin接口定义
    

• 插件文件结构

  • 平台默认一个目录为插件的安装目录，第三方插件放在该目录下，平台启动时，会加载扫描这些插件执行里面的plugin接口实现类。

• 插件扫描加载

  • 平台会实现一个PluginService，用来在Classpath中扫描加载plugin插件，并提供插件的注册管理功能。

• 插件生命周期管理

  • 平台会提供插件的安装，卸载，测试等功能。方便新功能的开发效率。 同时我们也会定义插件的元数据格式，用来管理插件。

• 插件开发

  • 插件开发以maven项目形式，平台提供插件开发所需的二方包。插件的开发和平台开发独立，各业务系统可以独立开发功能插件

2.2 集成平台（Integration）

首先我们要明确为什么需要这个集成平台：

对于交易这样的复杂业务系统，数据庞大并不是平台增长的唯一方式。业务流程也可能在复杂性方面不断增长。交易处理的信息可能会是各种数量的并且任意数量组合的传输类型、过滤、增强以及路由等。
复杂的问题会在任何领域都出现，但是解决它们的总体策略通常是一样的：分而治之。我们会将问题拆分为更容易解决的子问题。然后这些方案再按照与分解相反的方式组合在一起形成整体的解决方案。
通过观察会发现这样的问题是经常发生的；借助于经验，能够识别出最优的方案。我所讨论的就是模式。这些模式被命名为企业集成模式(Enterprise Integration patterns), 由Gregor Hohpe和Bobby Woolf进行了分类和总结。

2.2.1 集成平台设计目标

在平台Runtime成品当平台的功能已插件，模块的形式接入平台后，我们需要一组模块一起完成一些复杂的业务功能。比如在交易系统中，下单这样一个流程，就可能设计到多个模块提供的功能和服务。如何方便对这些流程以及服务进行编排是体现平台能力的重要标志。当一些业务需求需要对流程进行少量修改或者重新定制某些服务，而大部分流程功能保持不变是，平台提供简单方便的编排能力就可以满足对业务的快速响应。

首先在这样的流程体系中，一个复杂的业务流程需要和多种外部业务系统(比如交易的下单系统，退款系统，支付宝)，中间件，数据库系统(比如Tair，Notify，MetaQ)连接，调用本地服务或者远程服务才能完成，如果我们希望平台能够以简洁的方式对流程进行编排，平台必须达到以下要求：

• 简化外部系统的连接调用方式，消除不同系统调用方式的差异，将系统的调用细节由平台完成，对调用者透明，平台提供一致的调用模式，同时该调用方式简单有效。
• 同时，对流程的描述提供DSL语言支持，简化流程的设计，方便通过可视化流程设计工具提高开发者流程设计能力。
• 提供对流程的运行监控，实时追踪业务运行情况。
• 对流程的生命周期进行管理，可控制流程的启动停止。
• 高效的流程执行引擎，能针对流程进行流量控制。
• 完善的流程错误处理报警机制。

为了达到以上要求，系统通过集成平台提供对满足对流程编排管理的需要。这些要求在EIP模式里有很好的实践和总结，在金融领域，传统中间件厂商利用这些模式实现的中间件方案为复杂的金融交易业务提供了解决方案。

目前业务系统涉及的业务和流程也变得越来越复杂，流程，定制需要对不同的业务提供不同的支持。涉及到多个系统之间的交互，比如交易里一个订单从生成到完成，需要UIC,IC，UMP，库存，保险，风控，限购，积分，toc，buy，tp等多个系统合作，不同类型的业务订单设计的流程也很不相同，集成模式为我们解决这些业务的复杂性提供了很好的问题解决方案，让我们对于业务和流程能更清晰的管理。

集成平台设计的目的就是引入企业集成模式解决方案，为平台提供对复杂业务的流程的隔离和编排。

2.2.2 集成平台实现

集成平台会利用Apache Camel提供的EIP开源实现，完成集成和流程编排的功能.

Apache Camel是Apache基金会下的一个开源项目,它是一个基于规则路由和处理的引擎，提供企业集成模式的Java对象的实现，通过应用程序接口 或称为陈述式的Java领域特定语言(DSL)来配置路由和处理的规则。其核心的思想就是从一个from源头得到数据,通过processor处理,再发 到一个to目的的.
我们将在Apache Camel的基础上，为交易业务平台提供集成和编排能力。

2.3 业务领域平台（Domain）

业务领域平台主要定义业务的领域模型，包括功能，流程安排等。所有这些业务的基础元素会以元数据的方式定义和管理起来。

以交易为例：

2.3.1 业务领域模型

业务领域平台是建立在基础集成的平台基础上，通过设计业务相关的领域模型，来完成业务相关的基本功能和流程设计。 比如对于交易这个领域，我们需要定义出交易涉及的订单等领域对象模型，设计超时，优惠，物流等功能模块，以及下单等流程。 对于招商之类的业务平台，需要定义活动领域对象，设计玩法，招商流程等相关的功能和流程。 这些业务领域相关的实现会通过模块的方式实现并向基础平台注册。

2.3 业务平台（Business）

业务方根据特定的业务场景，开发符合自己需求的业务系统。 业务系统和业务领域平台的关系就像是策略模式的一种实现。
业务领域平台提供业务的各种抽象的策略定义，
比如定义了各种业务原型,定义了业务领域功能

业务系统则基于业务自身提供具体的策略定义, 如确定本类业务的交易原型，各种功能点的特定实现。

2.4 元数据平台（Metadata）

在这个平台，平台开发者可以通过平台元数据和集成元数据定制扩展平台的功能。 领域和业务开发者可以注册新的业务类型，设计业务流程等。

对于整个系统，我们将平台的能力通过元数据定义出来。 作为基于领域对象模型设计的平台系统， 根据系统的分成设计，会有以下元数据定义

平台元数据
元数据 定义

基础平台
Adapter 定义接口扩展
Module 定义模块

集成元数据

元数据 定义

集成平台
Component 定义端口组件
Processor 定义处理器
Router 定义流程

业务领域元数据
...

2.5 运营开放平台

在业务系统里，一定是运行着大量业务的复杂系统，需要对业务的各个环节进行监控，比如我们需要知道订单从生成到关闭所经过的处理链路，需要知道不同的服务被调用的统计等等，所有这些将以不同视角通过运维开发平台提供给使用者，使交易业务更加透明，可控，方便问题排查，方便交易性能调优等。

运营的各方面能力也可以从平台各个层面进行维护监控。业务团队会关心本身业务的运行情况，领域团队可以关注领域相关能力的运行情况。

3 研发模式

开发团队分为平台开发团队，领域开发团队和业务开发团队，对平台的开发进程处理基础平台外，其他都以插件开发的形式推进。保证平台开发和业务开发独立，基于不同的代码管理。

• 平台开发团队的职责

a) 基础集成平台的功能模块开发，提供平台的基础能力，也包括性能优化，错误追踪隔离等功能。
b) 开发辅助工具开发，包括流程设计，插件开发工具，平台命令行等。
c) 发布流程设计和维护
d) 测试机制设计
e) 问题排查流程设计和辅助工具开发

• 领域开发团队职责

a) 负责开发该领域内的领域模型，相关功能点定义和实现，也包括流程原型设计，扩展点设计。
b) 提供业务类型的审批流程设计
c) 提供业务部署设计规范

• 业务开发团队职责
  a) 在交易平台基础上，定制扩展开发自身业务

b) 制定自身发布流程
c) 制定自身监控报警设置

4 现状

目前Businessworks基础集成平台第一版本已经开发完成，并在招商平台中开始试用。 平台以二方包的实行提供给业务团队使用， 在下一篇中，《基础业务集成开发平台(BusinessWorks) - 业务开发篇》
我们会介绍如何在业务系统中接入Businessworks，从而具有平台化的一些底层支持。