2015年平台现状

业务从最开始的项目化到平台化，是有一个成熟过程。我对一个平台的成熟度，总结了一个成熟度模型，如下：

平台成熟度

在2015年之前，阿里巴巴通过共享能力中心的建设（即业务平台事业部前身共享平台事业部），在一些核心平台，如交易中心、商品中心、营销中心等，平台成熟度初步达到了 I 级水平。这一级别的平台，主要是以API服务接口的开放为主。这个阶段，HSF框架在集团内部得到了非常广泛的应用，并享有盛誉。

但众多繁杂、形态各异的业务，他们的业务逻辑差异非常大，几乎是没办法通过准确定义API接口入参来解决这些逻辑差异问题。 因此，接口的入参中也逐渐出现了一些Map，通过这种方式来传递业务差异化的上线文请求参数。对于Map传递的此类参数，平台同学几乎是没有办法进行识别并做业务逻辑的特殊处理。因此，Java SPI机制，也在这个阶段被引入。并允许业务方同学能够访问平台代码，并基于平台定义的SPI接口去写接口实现类，实现业务特定逻辑的扩展。 这种机制，称之为“业务方共建”。 这种机制，在一定时期内极大的提升了生产力，但随后也因为架构上的不足导致了其他问题。

业务挑战 & 解法

业务方共建这个机制的设计初衷是好的，但比较蛋疼的问题在于平台并没有一个很好的 业务/平台 分离的机制，让业务定制代码与平台代码分离（至少不要共用一个代码库吧）。 这也到导致平台代码质量得靠人，而不是靠某种可信的“机制”。 时间一长，代码库里的业务代码与平台代码纠缠在一起，你中有我，我中有你。不仅仅有之前我文章《TMF — 平台代码是如何腐化的》中提到的问题。 面对被拆分成7000多个的微服务应用，作为业务开发同学，如何能从这个体量下以及“你中有我”的平台代码中，准确评估出业务代码该如何修改，都成为一种巨大的挑战。

业务/平台分离机制的缺失，也导致业务定制逻辑是没有办法独立发布的，必须要跟随平台的排期，在发布窗口（每周四）进行发布。到了每周四的平台发布，需要合并四五十个分支代码，颇为壮观：业务回归工作量巨大、A业务的发布会影响到B业务、业务与业务之间没有很好的隔离等等。

我在组织了几次设计团队研讨，我让大家用 “如果平台能做到XXX就好了，我们可以咋样咋样咋样”，用类似这样的写法，大家总结出新的平台应该具备的一些特征：

  • 针对特定业务的订约方式、履约方式，能快速的构建业务包并进行部署
  • 新构建的业务包与平台解耦，平台不成为制约业务开发的天花板
  • 新构建的业务包与其他领域的业务不会相互影响
  • 允许业务能自定义订约、履约流程以匹配实际业务流程
  • 业务能借鉴其他业务所用的产品以及配置的业务规则，选择性的复用在自己的业务上
  • 业务发布更灵活，想发就发，不用等待全网回归
  • 能提供灵活的部署模式，比如面对新零售线下业务的本地化快速部署
  • PD对业务现状了如指掌，不需要翻代码去看、去猜；需求传递顺畅、无损，能无损传递、快速实现；
  • PD、开发对系统能力直观可视、可控，能快速进行影响评估

基于这些点，我们也就很自然而然的提出了关键技术与解决方案：

1、业务与平台分离、业务与业务间隔离：平台的发布和业务的发布窗口解耦，业务与业务之间不会相互影响。
2、平台的能力可透出：业务能方便的知道平台能力，并选择具体的能力做定制
3、部署架构与逻辑架构分离，可灵活按需部署的能力

用类似这样研讨的方法，我总结出如果要做一个新框架作为平台内核，这个框架的关键设计要点：

  • 业务/平台分离插件化架构： 平台提供插件包注册机制，实现业务方插件包在运行期的注册。
    业务代码只允许存在于插件包中，与平台代码严格分离。业务包的代码配置库也与平台的代
    码库分离，通过二方包的方式，提供给容器加载。
  • 统一业务身份： 平台需要能有按“业务身份”进行业务与业务之间逻辑隔离的能力，而不
    是传统SPI架构不区分业务身份，简单过滤的方式。如何设计这个业务身份，也成为业务与
    业务之间隔离架构的关键。
  • 管理域与运行域分离： 业务逻辑不能依靠运行期动态计算，要能在静态期进行定义并可视
    化呈现。业务定义中出现的规则叠加冲突，也在静态器进行冲突决策。在运行期，严格按照
    静态器定义的业务规则、冲突决策策略执行。

以上三点，是在2015年4~6月份期间，我主要总结的框架Top 3设计要点。关于这三点设计要点的进一步说明，可参见《Alibaba交易平台TMF2.0介绍》

这三个设计要点，也引申出一些关键概念，大家可以进一步移步参考下面几篇文章：

早期我在云栖大会上的介绍材料下载地址：https://developer.aliyun.com/topic/download?id=7602&from=yq