SPI扩展性与中台化

·  阅读 384

1. SPI的扩展性设计

什么都行很多时候等于什么都不行,设计的本质并不是强化能力,更多的是限制能力。

1.1 编程语言强大的扩展性

面向对象编程语言提供了扩展性,比如java,自身就提供了interface和Override机制。子类可以通过实现接口或继承父类,来扩展原来程序的功能。 当我们使用java语编写的开源框架,比如spring或mybatis等,我们大部分时候都是直接使用框架功能。如果我们对框架做出很多扩展,如下图,框架升级的时候很难保证所有的接口和类不发生改变。发生升级后,我们会发现原来的扩展开发都无法匹配使用了,原来的扩展开发代码资产全部要重新开发。

程序扩展.png

1.2 使用SPI限制扩展范围

支持二次开发

如果是少量的二次开发,上面的直接使用语言自身的扩展可以接受,但对于一个支持二次开发的平台来说是不可接受的,为了支持二次开发,我们需要用到SPI技术,把需要扩展二次开发的接口加以管控。

减少承诺,更好的遵守承诺 为了能更好的保护已经扩展开发的代码资产,我们应该减少可扩展的范围。并尽量保证这些可扩展的SPI(接口)的不变性。减少承诺,你才能更好的实现承诺。

程序制约.png

如上图:平台代码分离开「可扩展部分」和「不可扩展部分」。「不可扩展部分」伴随框架升级可以随便修改(第三方扩展开发无感知) ;「可扩展部分」尽量稳定提供历史接口兼容,第三方扩展开发不会受到影响 。在保护第三方扩展开发的资产和框架自身的可持续升级之间取得平衡。 「可扩展部分的接口」既「SPI」第三方可以扩展,官方也可以提供实现了这些接口的「官方组件」,第三方可以直接使用官方组件。

虽然第三方也可以继承官方组件进行子类overwite掉,但这样会强化官方组件的承诺。以后官方组件进行了升级,第三方会受到影响,overwite官方组件并不推荐。

1.3 扩展性总结

以上为「中台化建设」的引导篇,关键点是折中灵活性与扩展性,接下来会展开「中台化建设」的讨论,里面应该可以看到扩展性折中的影子。

扩展性的SPI稳定性,取决于行业需求或标准是否稳定, 如果你项目本身就是标准制定者,只要标准稳定扩展就会稳定,第三方扩展开发遵从标准SPI-SDK;如果标准发生改变对第三方造成的改变是必然的;反之如果你不是标准制定者,标准本身还在探索,那么SPI自然也就不稳定,第三方扩展开发就会不断受到影响。

1.4 中台化预览

在开始正式说中台化之前,我们先来看下中台化的结果,之所以以终为始,原因是和上面SPI的扩展性非常像,可以把两个图对照理解下:

中台的扩展性概览-减少契约.png

2 中台化建设

2.1 中台化的概念

中台化是阿里首先提出的概念,中台化并不是一种架构,是一种方法论。我查阅了下,国外并没有中台化的说法(带有主观性,可能只是我未检索到),但中台化用到的相关理论,比如「SPI扩展开发」,「六边形架构」,「DDD」等在中外是互通的。既然是方法论,如果不明就里的直接看具体的中台化技术,很难明白中台化到底是什么?你会感知到好像里面没有什么新鲜的东西,不都是已有的技术,比如DDD,SPI,六边形这些哈,到底是啥?

中台化实体很可能是一个组织机构,中台部门的职责是搭建公司的公有平台(比如阿里的电商中台),沉淀每个独立业务的共同逻辑(比如阿里的淘宝和天猫的公共逻辑),用于解决不同业务(淘宝或天猫)重复开发问题,同时支持每个业务个性需求的扩展开发(比如淘宝或天猫可以定制开发自身的个性业务)。

2.2 烟筒式独立开发

互联网为了快速响应需求,需要快速迭代开发以满足快速上线的要求,在初期一般会使用烟筒式开发:不同业务由不同的研发部门独立开发(每个业务部门都有专门的技术团队伺候,自然服务质量好)。比如一个电商平台可能存在国内线上业务,国内门店业务,以及国外业务,为了国内和海外业务需求互不影响,不同业务有不同的开发团队,如下图所示:

平台系统烟筒式开发.png

  • 优点:互不影响,可以快速响应需求,管理成本低。
  • 缺点:存在大量的重复开发,相同的逻辑不同团队需要重复开发一遍,如下图所示(不同垂直业务林立,形似烟筒称为烟筒式开发)。

烟筒式开发-重复逻辑.png

2.3 中台化思路-沉淀业务资产

伴随业务的逐渐发展成熟和行业沉淀,不同业务条线的公共逻辑越来越多。随着公司不断开拓新的市场,每出现新的业务条线,需要成立单独研发部门,招聘大量研发人员。迫切希望能够对已有的能力进行沉淀(减少研发成本),形成如下的结构:

平台系统中台化开发.png

前台与中台的定义与常见歧义

这里的前台不是指页面前台,前台指的是不同的业务条线,中台指的是不同业务条线的公共业务;拿阿里来说,天猫和淘宝是两个前台部门,中台部门是维护天猫与淘宝公共的业务逻辑的部门。

中台重沉淀积累,前台站在中台的沉淀基础上,快速响应业务。

以上说明了中台化演进的前因后果,接下来说下技术上如何搭建一个中台系统。

3. 中台的实施过程

3.1 中台的树形组件结构

通过SPI定义扩展点,程序框架进行扩展点调用,扩展点的实现有中台开发的公共水平组件,也有前台垂直方开发的个性组件。如下图:

中台化-扩展点与组件.png

3.2 代码模块划分

代码结构参考:

中台化-代码模块.png

  • 「SDK模块」:存放可扩展编程接口SPI,被垂直方以及中台代码所依赖。
  • 「水平包」:依赖SPI,编写不同业务的公共组件,这些组件可以被不同业务直接使用。
  • 「垂直方」:依赖SPI,编写自己的个性逻辑,这些组件不能直接执行,需要被中台的执行框架回调。
  • 「Core」:提供程序执行的框架,装配Bean工厂(比如通过Spring注入相关扩展SPI的水平包公共组件,或垂直方个性组件),调用扩展点实现具体的领域逻辑。
分类:
后端
标签:
分类:
后端
标签:
收藏成功!
已添加到「」, 点击更改