狄林
楼主
发布于 2023-4-20 19:27:37
阅读 8753
查看全部
在一些“业务逻辑复杂且非常易变，但单业务功能的逻辑复杂度不是很高”的场景下，低码平台是这类业务系统的提效利器，如审批流管理、营销活动搭建、常规H5建站工具等。本文站在活开工厂的角度，对低码建立停止了分析，一起来看一下吧。
这两年低码的概念始终很火，看上去像是处置代码开发的银弹，但是低码并不是所有的场景都是适用的，在一些“业务逻辑复杂且非常易变，但单业务功能点的逻辑复杂度不是很高”的场景下，低码平台是这类业务系统提效的提效利器，比如说审批流管理、营销活动搭建、常规H5建站工具、报名签到功能等等，业界也有相当多的低码平台规划。
先看一下低码的概念，通常是指一种可视化的开发方法，用较少的代码、较快的速度来交付应用程序，将程序员不想开发的代码做到自动化称之为低代码，类似的概念还有“无代码”，也是一种开发方法，通常是面向非技术性员工，不需要写任何一行代码来构建应用程序，所以两者的差别主要是面向人群的不同和对于代码忍耐的力度。拿拖拽式H5建站平台来说，拖拽式H5建站平台实质上属于无码、而基于H5建站的DSL或者规则引擎停止编程则属于低码、H5建站平台自身的开发属于纯代码开发。
这些概念的没必要区分的那么清楚，大家通常说的“低码” 大多是泛指“无码” + “低码”。
本文主要站在活开工厂的角度来看低码建立，其中的低码平台的建立思路是互通的，都是大致类似的思想和架构方案，其他业务场景适当微调适配就可以啦，个人认为在大业务领域下的低码建立是最高效的，适用于所有业务并且地道的低码是不存在的（仅仅个人观点）。
一、收益分析
前面提到做低码平台多么多么有效，到底是如何提效的下面来看下：
1. 平台定位分析
我们做一个系统，通常来说参与方有四个：
功能的直接使用方（用户、销售、运营、三方系统）；功能的运维方（负责功能的后台运营比如运营、产品）；功能的构建方（研发）；机器本钱等根底资源运维方。
2. 收益分析
我们的系统的本钱主要是研发构建本钱、功能运维本钱、资源本钱，首先低码手腕可以直接的降低功能的开发本钱、功能优化迭代速度快之后功能运营本钱也间接得到优化，由于低码是基于Faas思想做的资源隔离部署，一定水平上也节省了机器资源。
当节省后的开发本钱能盖过新增低码平台的工作量时，整体收益无疑是正向的。
纯代码、无码化、低码化三种方式的开发迭代本钱差别，拿做只要一个玩法的活动来看：
二、代码切入点
我们通常的开发流程在业务提需之后，我们首先是领域建模，然后是效劳构建，最后发布运行（B、C两端），我们低码的环节是针对代码建模、效劳构建两部分停止的，每个模型的代码建模环节主要有职责的定义、属性定义、逻辑开发三部分，效劳构建过程主要有模型直接串联关系、组合关系以及关系的决策逻辑的开发。
三、低码——组装式架构设计思路
对于这部分的低码化，首先从粗粒度不时向下拆解，我们一个领域某场景下的业务可以分拆为若干的功能，功能由若干的业务才干单元组成，业务才干单于由若干的原子才干构成，假设想停止低码的设计，最直观的思路就是拼图或者搭积木的形式来构建，然后过程中停止一些业务逻辑的填充。
所以整体的思路就是上述拆解的逆过程：
上述就是一种经典的Faas+组装式架构的设计方法，不只是低码的落地可以如此使用（利用低码手腕停止组装），我们对于日常一些复杂业务的架构也可以是同样的思路，面向散落的零件停止组装式开发（只不过是地道的代码复用思路或者效劳复用思路而已），常见的展示型web效劳、密集计算类效劳都是这样的处置思路。
易变逻辑的处置：
对于一些其中非常易变的业务逻辑，用低码去做虽然本钱小了，但是面对宏大的变卦照旧是不适宜的，这时候这部分仍然需要从无码逻辑中抽离，在规则引擎或者DSL之上建立动态逻辑注入，以此应对变化。
四、整体逻辑架构
根据上述思路，整体停止归纳笼统后整体的逻辑架构差不多长这样：
蓝色部分为核心的低码才干部分：网关负责分配我们效劳功能点对应的URI；中间层集成核心的对象建模、效劳定义、流程编排、既定复杂领域等核心功能；其中最底层为低码驱动引擎：低码解析引擎（驱动）、根底函数的注册发现才干（地址）、负责效劳串联编排的业务事件总线（控制）、对于事件发生时对于交互维护的总线（数据），感觉有点像CPU + 三大总线构造，哈哈哈哈。
墨绿色部分为低码工具库：首先是当前平台集成好的函数库；然后是对于外部函数或者效劳的接入；最右是低码依赖的一些根底才干：上下文存储、自定义存储、表达式引擎、代码生成器等等；常用问题的处置方案，假设大家兴致比较高的话，可以单独沟通或者单独描绘。
运行视图：
五、看个demo
以上述整体的逻辑架构所呈现的功能来看一下如何搭建一个活动模版，如何落地一个活动。
1. 确定玩法
首先本次demo的活动中有盲盒抽奖、任务列表、兑换、金豆代币、养成小游戏、签到等若干玩法，整个活动中的大实体根本有这么几个，我们就以这几个模型停止功能设计，确定模型之后再确定玩法之间的关联关系设计即可。
2. 落地金豆玩法
首先金豆实质上就是个代币，也就是根底的流水账模型，我们直接使用根底函数库中的账务模型作为单元才干，然后并不需要做额外的逻辑处置，只需要给这个效劳赋予一点业务属性（名称等等），然后选择我们用的到的根底函数，便可以直接构建出金豆增加、金豆扣减、明细查询、余额查询等才干。最后完成api的映射实现“金豆”才干暴露即可。
3. 落地签到玩法
签到相对费事些，业务属性相对较重，没有现成的模型作为输入支撑，此时我们需要做根底函数单元的“组合拼装”。
确定签到配置的元数据，实体中有活动id、各周期限制等等；确定签到实体的元数据，实体中有用户ID、活动ID、计数周期、当前计数等等；确定我们要实现的输入才干：签到、补签、增加签到时机、增减补签时机；确定我们要实现的输出才干：签到胜利、补签胜利、连续签到、签到记录；根据我们要实现的功能确定用到的根底才干：计数、周期计算、时机才干、限制才干等等；对于根底才干停止组装拼接，这里可以有3种形式，我们可以通过拖拽的形式将根底函数停止组合停止输入输出的关联、各种if-else的处置；我们也可以直接编写代码实现逻辑处置；也可通过编写系统内感知的DSL简化拼接逻辑。实现输入输出的api映射暴露至此就完成了一个签到玩法的搭建。
4. 落地盲盒玩法
盲盒抽奖的玩法组装拼接也是类似的，只不过用到的根底函数不同。
确定配置的元数据，比如活动、奖池、奖品，及其中的对应字段；确定业务实体的元数据，比如用户当前状态、用户中奖记录，及其中的对应属性；确定效劳的输入：开盲盒、增加盲盒时机；确定效劳的输出：盲盒奖品列表、开盲盒记录；确定对应效劳逻辑中的根底函数：时机、周期、限制、概率、库存等等；根据功能逻辑停止根底才干的编排，同样是三种方式，比如拖拽完成抽奖功能，当前周期、时机-1、限制消耗+1、奖池选择、概率选择、计数统计；完成对应效劳的API对应。
5. 玩法间的编排
当我们完成玩法（业务才干单元）的定义之后，我们就需要对于整体逻辑停止编排，把这些相对完好的工具组合成一场真正的活动。此时我们需要做的是对于玩法各种输入输出的关联，并对于关联关系停止动态决策（场景、身份等）。
比如说：
任务完成增加盲盒时机签到每连续十天上报周期任务完成每日签到增加金豆消耗金豆兑换盲盒时机某些高价值任务完成增加盲盒时机签到完成增加盲盒时机
这块的详细设计可以参照之前《活动流程编排》一文。
6. 前后端的配合
整体看下来我们需要一个这样的低码平台“开发环境”来构建我们的低码产物，在编辑器里可以完成根底业务单元的组装工作、业务单元之间的拼接工作等等。
完成整体活动或者说我们业务功能的搭建之后，接下来的工作是对于我们暴露出来的才干停止适配搭建前端界面，其中包括B端运营界面、C端用户使用界面。对于B端运营操作界面，由于款式上要求并没有那么高，可以定义一个前端模版对于低码过程中生成的元数据及API接口停止直接渲染。对于C端用户使用界面，可以基于<才干，API>停止页面功能的构建，通过前端的低码应用停止页面的拖拽搭建。
六、代码建立后的收益
整体看下来低本钱低码平台建立后，对我们的收益是很大的，整体的思路也是实在可行的，整个建立过程对于业务收益是比较大的，比如：
沉淀的根底才干，除低码平台可以使用外，日常纯代码开发也是可以直接用的，也为无码功能增加了一件可复用才干。业务单元才干，由于迭代效率较高，功能丰富度、优化水平要更好，并且很多时候可直接复用。业务功能，才干在使用过程不时沉淀，可以直接复用，由于可以直接拖拽编排，整体的开发本钱是直线下降的。对于功能来说，迭代效率更高。
整体是好的，但是在低码平台的建立启动及过程中需要注意的是：
1）术业有专攻，不要贪大求全，在适宜且某个特定的大业务领域下建立才是合理的。
2）函数库的积累是一个循序渐进的过程，根据诉求逐步沉淀根底函数才是王道。
3）低码、无码、纯代码并不互斥，界线也相对模糊，他们只是适用于不同场景，受用不同的迭代效率和使用人群，很多时候一次性单功能纯代码开发效率最高（上低码走弯路）、无代码就能满足使用人群（适用人群是运营、研发无诉求），功能性增迭代要求非常快、倒排需求较多、功能相对类似、开发资源相对匮乏的场景就很适宜低码平台承接。
4）不要过分迷恋DSL，使用既定的工具来处置问题，现有的脚本语言、数据架构足够处置问题了。
作者：薄荷点点，“数据人创作者联盟”成员。
本文由@一个数据人的自留地 原创发布于人人都是产品经理，未经容许，制止借鉴。
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者自己，人人都是产品经理平台仅提供信息存储空间效劳。 |
|
