最新消息:欢迎访问Android开发中文站!商务联系QQ:1304524325

业务架构浅谈

开发进阶 loading 244浏览 0评论

一、序章

一般的工程师接触到的是 应用架构 ,传统的MVC分层架构、事件驱动架构等等。第一次接触业务架构这个概念是在来到商品发布团队之后。商品发布是一个业务属性很重的系统,承载了淘宝、天猫、盒马、魅力惠、汽车、虚拟、SCM自营、苹果、村淘、公益
、教育等诸多业务(业务多的围起来可以绕地球一圈)的商品发布功能。头半年对“业务架构”还是很懵逼的,随着慢慢的熟悉业务,研究框架代码,才对我们的业务架构框架有了清晰的认识。

二、单体应用的痛点

在GPF框架(我们团队的业务架构框架)诞生前,上述的所有业务都在一个单体应用里承载。每新加一个业务,我们的应用工程就会变得更加的臃肿,软件熵变大,代码难以维护,不少类都有几千行以上。不同的业务代码都杂糅在一个类或者一个方法里。
以商品上架时间组件为例,当我们承接教育行业时,我们的代码会做如下的改动(为了方便理解,我把源码改成了伪代码):

/**
 * 初始化商品上架时间:
 * 1)教育业务发布,开始放入仓库中,且不可修改
 * 2)其他业务立即上架
 * @return
 */
private int initStartTime(){
	if("业务身份" == "教育" && renderStatus.isPublish()){
		velocityContext.put("startTimeReadonly", true);
		return “放入仓库”;
	}else {
		return “立刻上架”;
	}
}

每承接一个新的业务,我们都要添加很多if else式的打补丁代码。严重违反了开闭原则,这种写法是典型的代码坏味道。当承接的业务越来越多时,系统变的越来越庞大。不管是承接新的业务还是对老的业务进行改动,都越来越麻烦。马老师说:

抱怨越多的地方,机会也越多。

这句话对软件工程同样适用。为了解决单体应用架构的痛点:新增业务就给老代码打补丁。实现业务代码给力功能的GPF框架面世。
新架构的核心诉求:业务隔离。更加具体一点,代码隔离,配置文件隔离,运行时流程隔离。围绕业务隔离这个核心诉求,其实我们做了更多的事情,这个后面讲。

三、如何做到业务隔离

我们给每个业务身份建立一个模型,并配一个业务id。业务模型包含这个业务要用到的组件,扩展点,流程配置。所有业务身份构成一个业务身份列表。每个业务模型都有一个业务识别逻辑——当前用户请求是否命中该业务。用户请求进来时,都会走一遍这个路由算法,以确定唯一的业务身份。
在这里插入图片描述

唯一的业务身份id确定后,对应的组件集合,扩展点集合,流程配置也就确定了。

1. 组件

每个业务的发布页都由十几个到几十个组件构成。这其中有平台通用的组件,比如说商品标题,商品条形码,类目属性,销售属性,sku等全行业都需要的业务组件。垂直业务有垂直业务的定制组件,比如说公益业务有捐赠金额的组件,除了公益业务,其他业务不可能用到这个组件;盒马业务有商品所属门店,管理机构等新零售行业特征的组件。
在这里插入图片描述

业务需要的组件 = 业务定制组件 + 需要的平台通用组件

2. 扩展点

这里的扩展点可以理解为插件(plugin)

  • 扩展点
    • 组件扩展点
    • 流程扩展点

扩展点同组件一样,也是有平台通用扩展点和业务定制扩展点构成。

业务需要的扩展点 = 业务定制扩展点 + 需要的平台通用扩展点

3. 隔离方案

通过上述可以发现,平台通用的扩展点和组件是代码复用的!并没有达到之前的代码隔离要求。解决方法也简单:系统初始化时,每个业务身份id都会new一份通用组件和扩展点,并merge自己的定制组件和扩展点。于是,内存里,每个业务身份id都会有一套运行时的独立且完整的组件和扩展点集合。系统真正运行的时候,取到的是组件和扩展点的对象,并不是代码。这样,代码复用,业务数据隔离。这才是最合理的方案。

在这里插入图片描述

四、如何做到灵活易接入的中台化产品

仅仅达到业务代码解耦并不够,商品发布系统要做一个中台化的产品。能够快速的支持新业务接入,让新的业务一起共建甚至新业务的同学独立的在GPF框架上接入他们的业务,是我们的目标之一。要做到高扩展,快速接入新业务,这里不得不提到“微内核 + 插件化”技术。
微内核技术:

微内核是内核的一种精简形式。将通常与内核集成在一起的系统服务层被分离出来,变成可以根据需求加入插件 这样就可提供更好的可扩展性和更加有效的应用环境。使用微内核设计,对系统进行升级,只要用新模块替换旧模块,不需要改变整个操作系统。

微内核技术源于操作系统,但是在互联网产品“平台化”的大浪潮之下,这个技术得到了广泛的应用。
在这里插入图片描述

GPF微内核会暴露一系列的SPI(Service Provider Interface)接口,不同的业务按需去实现这些插件接口。系统启动时,程序扫描出所有实现了SPI接口的插件,并集成到系统中对外提供服务。当新业务需要接入时,定义好一个业务身份,同时实现需要的SPI接口,即可完成业务的接入,同时做到业务的隔离。

五、 结语

架构不是设计出来的,是演进而来的。演进式架构才有生命力。从Xsell 到 GPF1 GPF2 GPF3, 每个版本我们都解决了前一个版本的痛点同时往前看半步。一个产品要走平台化道路,业务架构一定是标配。

——————— 本文来自 bruce128 的CSDN 博客 ,全文地址请点击:https://blog.csdn.net/bruce128/article/details/82871316?utm_source=copy

转载请注明:Android开发中文站 » 业务架构浅谈

您必须 登录 才能发表评论!