软件架构生态化-多角色交付的探索实践

作者:京东零售 李春丽

作为一个技术架构师,不仅仅要紧跟行业技术趋势,还要结合研发团队现状及痛点,探索新的交付方案。在日常中,你是否遇到如下问题 “ 业务需求排期长研发是瓶颈;非研发角色感受不到研发技改提效的变化;引入ISV 团队又担心质量和安全,培训周期长“等等,基于此我们探索了一种新的技术体系及交付方案来解决如上问题。

背景

嗨,大家都知道软件研发需要许多角色共同协作,包括客户、产品经理、研发工程师、测试人员、实施运营团队等等。在这众多角色中,研发工程师的人数占比最高,但是研发资源毕竟有限,随着需求量不断增加,在项目中还会听到如下吐槽:

1、研发团队排期瓶颈,非研发角色感受不到研发技改提效的变化。

2、引入ISV 团队又担心质量和安全问题,而且培训成本高、周期长,在核心复杂系统中,不敢也无法短时间大规模引入。

不过,如果有一种方法能够实现生态化交付和全民开发的愿景,那就可以解决上述问题了!这种方法可以让所有角色,无论是技术还是非技术的,以安全、更简单的方式参与进来。

这样一来,就可以在不增加团队人数的情况下,提高团队的吞吐量,实现更高效的需求交付,是不是很奇妙呢?

挑战

为了达到生态化交付和全民开发的愿景,我们需要解决如下几个问题?

1、如何让非技术角色实现研发的交付?

2、如何让全民开发者完整实现一个需求闭环,而非仅仅实现其中一部分需求?

3、如何解决交付中核心系统安全问题?

我们带这几个问题看下解决方案。在讲技术方案之前,我们先站在客户角度,从整体看一下,一个系统的需求都来自哪里?而我们都知道比起从0-1新做一个系统,二次扩展类需求更加复杂,我们今天就以二次扩展类需求入手和大家一起分享下,在京东智能供应链Y做的一些实践。

方案

设计思路

如上图就是任意一个系统中二次扩展类需求分类的最大集合,主要有8类:API类、参数类、模版类,界面类、流程类、规则类及数据库类。

1、API类:主要是新增API和在原有API的扩展,例如,原有API上新增一些属性。

2、模版类:主要是新增一个模版。例如,制作一类新的合同模版或问卷调研,各部门填报填写。

3、参数类:主要是新增KV类的参数。例如,新增“是否包括自营商品“参数,并让这些参数在某些逻辑中起到作用。

4、UI类:主要是新增菜单、按钮、布局、图表、校验规则等。例如新增一个外呼按钮,并调用外呼系统 接口。

5、流程类:在原有流程节点中新增新的节点。

6、规则类:在原有的规则前、后等,新增新的规则。

7、数据库类:在原有表中增加新的属性,或者新增一个子表。

8、最后还有一类其他:无法划分为某一类,需要复杂的逻辑处理实现。例如 数据重新聚合与逻辑运算

我们就基于这些研发的需求类型,设计一套技术体系,实现生态化交付和全民开发的愿景。

技术方案

我们把软件系统分成三层,建立完整的全链路扩展技术体系,在把这些能力通过零低代码手段把他们进行打通、包装和开放,就可以实现屏蔽源代码的情况下,对系统进行安全、简单、闭环的二次增强,进而达到全民开发的目标。具体包括:

1、界面层:该层扩展主要手段就是零低代码技术。

2、接口层:该层扩展主要手段就是依靠不同模型之前的映射来解决,而模型的扩展就可以依靠对象扩展来解决。

3、服务层:该层扩展主要依靠流程、规则引擎来实现,这个业界有很多开源工具,例如activity和drools等。另外还有很多场景是复杂的逻辑变更,这个可以依靠插件、事件驱动模式来实现。

4、模型层:该层扩展主要手段就是依靠元数据驱动,通过依赖元数据对象,而非底层物理数据库。

以上能力,在通过最后零代码技术的加持和封装,实现可视化配置,形成一个工作空间,在对工作空间进行分角色授权,让不同角色以熟悉的语言进行操作,这样就可以实现生态化交付和全民开发的愿景。

所以说扩展的技术体系不是一个单一的解决方案,它需要零低代码、插件、业务事件、元数据驱动、流程规则引擎等技术共同协作才可以。而难点是这几个技术需要互相搭配好,实现扩展的互认,例如我们在对象模型扩展中增加了一个属性,这个属性需要在界面展示、需要在接口中透传、需要在规则中校验,这就需要做好顶层架构设计。

我们通过几个案例来描述,它需要和可以实现哪些能力?

案例

案例1:让非技术参与进来,体会技术提效的变化

需求描述:基于业务变化,一个核心系统,需新增 “渠道类型” 这个属性,改动涉及:

1、数据模型变化(技术上:数据库字段变化)

2、后端服务及规则变化(技术上:接口变化、对象变化、判断规则变化等)、

3、展现界面变化(技术上:UI 界面增加带数据权限的查询条件、表格新列及图表增加等),

也就是需要软件不同层次的进行变化。通常,这些特别技术的需求变更,只能技术排期做,但是通过这种新方式。产品经理/客户就可以在无需等待,7 分钟内,全程零代码的模式下完成。

1、在对象扩展中,增加新的属性。

2、在规则引擎中,基于新的属性,编排增加新的校验。

3、在界面扩展中,把在对象扩展中的新列拖拽出来,展示为查询条件,并制作一个新的饼状图展示到界面。

通过这个案例,也就是说我们可以把黑盒的研发工作,安全、高效的交付给其非研发角色自助完成,提升交付效率,减低沟通成本。另外还有一点值得一提,这种方式也让非技术人员,可以直观的感受到技术提效的变化。

案例2:不触及代码情况下,实现安全一站式开发

需求描述:基于业务变化,一个核心系统,需要与客服系统集成,实现对某类特殊业务的客服外呼,改动涉及:

1、新增一个外呼按钮

2、新增前端规则校验,只有履约数据滞留2天的才需要进行客服介入。

3、调用外呼接口,组装数据增加复杂逻辑并传递。

4、发送邮件通知相关角色。

同样,这些也是特别技术的需求变更,原来只能原厂技术开发来排期做,但是通过这种新方式。客户IT或ISV,就可以在不触及代码的情况下,通过统一平台一站式完成需求的变更。

1、在界面层中,通过零低代码手段完成按钮新增。

2、在界面层中,通过零低代码手段完成规则校验的新增。

3、在服务层中,通过插件方式,实现代码逻辑处理,并调用外呼接口。

4、在服务层中,通过事件订阅方式,监听外呼状态,配置邮件模版,实现邮件自动发送。

通过这个案例,我们可以看出来,业务需求具有多变性,不能仅仅依靠一种手段完成扩展,需要多种方式进行搭配,才能实现大幅度提效。

结束

其实零低代码、插件、业务事件、元数据驱动、流程规则引擎等技术在行业中并不是一个新事物,而这些技术可以互相搭配,实现完美集成和互认,让用户在一个平台针对不同业务的场景使用合适的技术,完成需求的自助化,是个难点。它不仅仅需要平台技术,还需要对业务系统需要合理的抽象、抽取。

最后,我们在回过头看看最开始的技术挑战。是不是都解决了呢?

1、如何让非技术角色实现研发的交付?答:通过零低代码模式进行封装和开放。

2、如何让全民开发者完整实现一个需求闭环,而非仅仅实现其中一部分需求?答:需要全链路开放和打通,并不仅局限一种技术手段。

3、如何解决交付中核心系统安全问题?答:屏蔽源代码的完整扩展体系。

热门相关:帝少的专属:小甜心,太缠人   霸皇纪   时间都知道   霸皇纪   天启预报