X-Series落地案例合集

540 阅读19分钟

前言

自从2012年第一个正式版以来,x-series已经在携程,天讯瑞达, 中国电信,杏汇科技,推演医疗,海拍客,中金云创,信也科技等多家公司落地,覆盖旅游,互联网金融,医疗,银行和证券等多个行业。为方便大家参考借鉴,本文汇集了之前在ArchSummit,K+技术峰会等场合分享过的案例,还有近两年用户提供的新案例。每个案例都会提供使用场景,模型截图,用户反馈和点评。除点评外,所有内容基本上直接引用用户自己提供的文字。如案例曾经发表过,将附上原文链接。

xUnit案例汇总

天讯瑞达案例

通用工单处理

包括流程实例结束前置规则处理,回单接口服务,发起工单服务,查询接口服务,操作工单服务。

daccb265ff06479195dcad181248e0d.png

e3312f77fb9d76a23f3cc39157b8526.png

用户反馈

工具非常不错,已经用了很多年。希望未来能够出基于浏览器的编辑器版本。

点评

这个用户的案例展示了一些独特的做法,并对未来xunit需要增加的功能提供了思路。

利用通用流程降低系统复杂度

如果我的理解正确,用户的场景需要按流程处理大量不同类型的工单。一般的做法是按照工单类型对每种工单单独创建流程。在处理步骤相同或者类似的情况下,这么做会导致系统中会存在大量雷同的工单流程。但这个用户按抽象的流程处理步骤,而不是具体的工单类型对流程建模。这样整个系统就只需1个,最多几个顶层通用工单处理流程就可以用于所有类型的工单。不同类型的差异化处理只在流程步骤这一级别进行。当增加新的工单类型时,如果抽象的流程没变,那么就无需改动顶层设计,只用扩展底层的流程步骤,从而最小化变更更范围。这个思路很巧妙,值得其他类型项目借鉴。

基于单元粒度的进度统计

该用户另外一个有意思的做法是用单元名字表示开发进度。你可以看到部分单元命名为“正在开发中”,这样在模型层面就可以对研发进度一目了然,对于项目管理非常有帮助。也许为xunit添加开发状态属性,包括未开始,开发中,已完成等状态,同时提供一些自动统计的功能,比如当前模型多少模块没有开发完毕,整体完成进度等,将会是一个比较好的功能选项。

通用调用组件

“回单接口服务”看起来是个通用的外部调用服务,因为没有看到不同工单类型的处理分支。未来xunit也应该提供支持各种常见协议或服务的通用外部调用模块,例如HTTP,OpenAI等,从而更加方便用户。

自定义的enum

可以看到对工单的分支处理是基于数字进行判断,即不同数字代表不同类型的工单,这样可读性比较差。如果用户已经定义了enum类,xunit应该支持显示enum的name属性;如果用户没有定义enum,xunit应该考虑是否支持用户在模型内部定义和使用enum。

信也科技案例

基于通用Http处理单元和并发能力的BFF

场景说明

某BFF需要调用多个后台微服务并对内容进行聚合,如果顺序调用则会总体超时。经过调研,利用xunit的并发机制对后台服务进行并发调用可以解决超时问题。同时xunit的单元配置功能可以很方便的进行组件复用。

首先由左侧第一个Locator单元节点对用户是否登录进行判断。具体实现为ExpLocator,该组件支持可配置表达式,可以复用在其他场景。

image.png

其次按用户是否登录分别调用不同的后台服务。对于已登录用户将并发的调用多个后台服务并对结果进行汇总。无论是哪种情况,使用的单元都是HttpProcessor,区别仅仅在于配置的URL不同。

image.png

用户反馈

xunit能够将原来串行执行的接口调用很直观的转变为并行。并且仅仅只需提供两个通用的可配置的xunit实现就可完成所有工作,大大减少了开发工作量和维护难度。

点评

xunit为组件复用提供了一个真正的落地机制。用户使用自己开发的两个通用的组件,仅仅通过配置表达式和URL就可以快速构建多种相似场景,无需额外的代码开发工作。不仅节约了开发成本,节省了开发时间,还降低了后继维护的难度。未来类似这两个组件的功能将考虑在xunit中缺省提供,或包含在扩展包中。

其实这个案例中对用户是否登录的判断用Validator组件更合适,因为Validator的输出就是固定的true/false两条路径。Locator一般用于多余两条的路径判断。当然用户这么用也行。

如果用户持续的积累可复用组件,未来有必要提供某种组件库管理机制,能够方便不同研发团队进行组件注册,查找,学习和查看具体应用案例。

此外, 虽然这个案例的用户和我是同一家公司的,但他们之前并不知道有xunit。我在一次偶然的机会下听说了他们的技术痛点,才有机会推荐她们尝试。这说明x-series的知名度不够,有什么好办法能够让x-series工具被更多的人知道?大家帮忙在评论区出出主意。

用户认证流程

用户认证过程包括几种不同的场景,分别是基于OCR的身份证识别,人脸照片识别,手持场景识别,身份证号码识别。对场景间的公共部分进行了组件复用。

image.png

image.png

image.png

image.png

用户反馈

尝试过使用状态模式来解决流程和代码复用的问题。但是某一种认证的流程逻辑还是不够明确。后来就想找一个流程引擎来解决流程的问题。经过调研发现 ActviJBPM 等流程引擎虽然可以实现流程管理的问题,但不是需要一套数据库,就是需要一些配置文件来维护,太重了。后来不经意间通过 CSDN 发现关于 xunit 的文章。读完后有种相见恨晚,柳暗花明的感觉。简单说下为什么特别合适。

  1. 业务逻辑清晰表达。xUnit 基于流程图灵活的构建各组件的流程,业务的的逻辑通过一张图片就能清晰的表达
  2. 代码复用。xUnit 里的各个组件可以在多个流程里使用,实现了代码的复用
  3. 轻量。xUnit 的各个组件之间的调用关系不需要配置文件也不需要数据库来维护

使用的总体感受,评价: 如果业务流程稍复杂又不合适重量级的流程引擎的业务场景非常适合用xunit 来实现。xunit 用起来简单,能快速实现业务透辑,业务辑清晰,代码复用率高 如果能 xunit 能实现组件并行的功能就更完美了。【该功能已经实现,见上例】

点评

在做x-series这么多年来,我发现优秀的研发总是会积极主动寻找好用的工具来提升自己的工作效率。他们非常理解研发痛点,对节约研发成本,降低研发难度,加快研发进度非常渴求。对如何判断工具是否适用非常清楚。很多东西一点就通,沟通起来非常顺畅。团队里面有这样的同事,工作就稳了。

用户登录流程

场景说明

处理不同来源用户的登录逻辑,包含不同来源下内外网和图形验证码的验证逻辑 处理不同环境下App消息推送逻辑处理

image.png

image.png

用户反馈

简化了复杂嵌套条件判断的代码逻辑,比起原来使用if-else加代码中注释的处理方式,更加直观易懂,易于维护 针对改动的分支可以很方便的做单元测试,减少代码bug

点评

这位同事的实践证明了利用xunit确实可以让单元测试更方便的进行。单元测试之所以难以推进,本质上是因为现有代码结构无法对代码进行有效的单元分割。如果你的业务团队还在为要不要搞单元测试而反复扯皮,还在为单元测试覆盖率提高异常缓慢而焦虑,请立刻马上让团队使用xunit对现有项目进行重构。

杏汇科技案例

医大师后台系统

场景说明

使用xunit构建整个公司的后台管理系统

主流程 image.png

业务处理单元子图配置

image.png

业务处理子图

image.png

响应处理单元配置

响应处理单元配置

响应处理子流程

image.png

安全检查子流程

image.png

用户反馈

如果将系统看一个人,那么可用Xunit来搭建人的骨架。以某服务系统为例,从服务总入口,到服务的分发,再到每个服务的业务逻辑切分都配置在Xunit

  • 整个系统的服务功能清晰明了
  • 业务逻辑一目了然,方便定位业务的节点,调整业务的逻辑
  • 能快速定位到每个功能点,极大方便了后续的维护

吐槽: Xunit的图形化编辑器已经满足开发所需,但对于懒人来说,总是会追求更懒的方式,所以这里还是要吐槽一下编辑器

  • 每个元件不能通过复制粘贴来复用
  • 没有搜索功能。

原文链接:提高系统开发效率的“银弹”——X-series可视化大规模应用开发工具集

点评

这是一个创业公司使用xuinit构建整个后台系统的案例。我最开始为研发团队做了为期一天的培训,并用xunit搭建了范例架子,虽然他们在后面的业务研发中基本上全部翻新了一遍。虽然整个系统有较多的子模块和较为复杂的逻辑,但由于用了xunit,从头到尾整个后端基本上只用了一个研发就全部搞定,没有增加新的人手。

我曾经回访过他们的研发总监关于xunit的使用效果。他举了个例子,医大师后端需要支持多种前端,并且各端之间数据协议格式差异较大(参见上面的“响应处理子流程”)。因为采用了xunit,每当来了新需求后,研发都可以快速定位和修改。所以即使只有一个后端研发,也能很轻松的对接多个前端。从管理层面讲,使用xunit不但人效显著,而且从架构上保障了产品质量。

中国电信案例

流程步骤处理

场景说明

下图是在我们实际项目中的部分应用。图中的“启动流程”功能,主要分为三个步骤:获取工单流水号、组/人数据处理(会签)、执行流程规则。开发人员可以把 xunit 中的处理单元关联对应的 java 类,可以很轻易的实现图形化的系统开发。

image.png

用户反馈

相信各位在开发比较庞大的项目,或者接手项目进行二次开发时,最头疼的问题是觉得模块间调用太复杂,自己不拿张纸画图都搞不清系统很多处理过程是怎么回事,另外可能做着做着,才发现有些功能之前的同事已经实现过,但是由于对整个系统代码不熟悉,没有重用原有的代码,自己又开发了一套出来,重复造轮子!!如果有一种方式,可以让开发人员比较容易看明白系统各个处理模块和流程,及其对应的类和方法,肯定可以大幅降低系统开发的复杂度。XrossUnit(简称 xunit)是X-Series图形化系统开发框架中使用最多的一个组件。xunit 可以通过图形化的方式描述系统业务。对开发人员来说,系统更易理解,更易维护,更易扩展,并且模块更容易被重用。

点评

很多时候当我在培训中介绍xunit能增加系统可理解性,可维护性,可扩展性和可复用性时,台下的听众都是一脸懵逼。这说明大家其实并不知道这些概念该如何落实到研发中。但这个用户用自己的案例和语言证明了只有借助具体的工具,这些理念才能真正落地。

道法术器缺一不可。无论多好的理念如果没有工具配合,光靠人的自觉是很难落地的。而有了好的工具,懂不懂理念其实没啥关系,做出来的产品自然合道。好的工具一定会减少,简化用户完成任务所需的知识,技能和步骤。

君子生非异也,善假于物也。研发人员和研发人员的区别就在于会不会使用合适的工具。

加密过程

场景说明

接下来举一个简单的例子,可以比较清晰的了解xunit在系统处理流程中的作用。下图可以看到,我们定义 MD5 加密和 SHA 加密两个模块,“加密过程”这个处理流程中,第一个模块的功能是输入数据,我们可以写一个读取数据的类并让该类与“输入数据”模块关联。然后根据入参判断使用不同的模块,调用 MD5 加密或者 SHA 加密。最后编写一个类与“输出数据”模块关联,把加密后的数据输出。当新增一种新的加密方式时,我们可以新增一条路由,指向新的加密算法。这些模块本身也可以轻松被别的流程重用,整个处理流程就像堆积木一样!

image.png

用户反馈

通过上面的例子,可以看出 xunit 能解决编码中的不少问题:

  1. 可以有效避免冗长的分支判断;
  2. 减少代码嵌套调用,轻易对代码进行解耦;
  3. 模块重用变得十分简单;
  4. 可视化的系统开发对开发人员十分友好。

xunit 上手十分简单,其源码并不复杂,感兴趣的小伙伴们可以试试。

原文链接:图形化系统开发组件X-Series(一)——XrossUnit介绍

点评

这个案例有两个特点。

  1. 运用了xunit的子图功能,很罕见的是子图只有一个单元节点。图中MD5加密和SHA加密顶层单元除了可以单独调用,同时还被加密过程中的加密步骤引用,估计用户需要同时支持这两种场景。
  2. 很罕见的用到了Converter。目前为止绝大多数反馈的案例使用的都是Processor。能用到Converter说明用户对xunit的功能相当熟悉,运用也很灵活。同时也证明了我对xunit 的设计非常完备。

xState案例汇总

推演医疗科技有限公司

电子卡券状态管理

电子卡券的兑换状态,涉及和业务团队的沟通

14a69bf0d2f02dbf970e73dfd59ad3e.jpg

用户反馈

我们对标一个叫 psychopy 的开源软件,它用python实现的图形化流程编排,与xunit能做的事情类似,还能与硬件外设交互,但没有xstate。 我们对psychopy 做了一些扩展,确认了需求后,认为不能在python上继续,优选拉回Java平台,这是考虑到招一个Java 团队还是选择余地更大。Python程序员中我的感觉是有软件工程概念的不够多 试用了赫总你做的x套件后,我们评估觉得条件齐了,开始用Java对标psychopy 做一套。春节前后用起来。

比psychopy多了状态机,这个是非常提升沟通效率的。我们一个操作流程下来,没有状态机就天天扯皮讲不到一块去。

点评

本例证明了可视化明显对提升沟通效率的作用。此外,状态机如果用代码表示所需的代码量会非常客观,基本无法理解和维护。但用xstate创建的可视化模型不仅非常直观,而且无需代码就能满足基本需求。

携程金服案例

用户资格在线审核

场景说明

用户资格在线审核。在线审核是个比较复杂,并且需要合规的流程。当政策发生变化,系统需要及时调整以保证合规性。

用户反馈

最近需要对目前的业务进行重构,考虑引入类工作流来完成业务流程。对比了好几款工作流引擎,如 activiti,JBPM 等,最后选择了 Xstate 来作为重构业务流程方案。

对比的几款开源软件都能完成我的业务需求,最终选择 Xstate 理由有以下几点:

  1. 无环境依赖。对数据库,环境都无特殊要求。相比其余的引擎需要一系列的搭建工作,如建表,编写配置文件等,Xstate 只需引入 jar 包就可直接使用。
  2. 快速上手。一款框架产品可以快速上手是非常重要的。Xstate 是一款非常轻量级的基于状态机的框架,通过阅读文档,运行 sample 即可快速了解整个框架的运作机制,从而进行自己的开发工作。十分符合目前互联网环境快速迭代的开发节奏。
  3. 快速融入现有系统。Xstate 提供了状态扭转所需要的所有基本步骤,使用配套的可视化工具可以快速搭建一套包含各个业务节点的工作流。通过简单配置可以迅速绑定节点和指定业务代码的关系,无需对已有的业务代码进行重构。这大大降低了二次开发的成本。
  4. 可视化工具。Xstate 配套有 Xtools 工具,通过可视化界面,快速完成功能设计,同时如上述第三点,通过配置节点和业务代码的关系,简单的操作就串起整个业务流程。

原文链接:基于 xstate 实现携程金服业务流程动态化

点评

这个用户的技术选型标准非常清晰,评价也很专业。确实,一款产品的质量好坏很大一部分体现在其安装是否简便,上手是否容易,是否能很好的兼容现有环境。我在研发x-series的时候构思了很久,做了很多艰难的功能取舍,克制了很多冲动。简化是件复杂的事情。

信也科技案例

内容生命周期管理

场景说明

简单的工作流场景。不希望引入太重的工具 Xstate是经过技术选型后最轻量级的,使用也最方便

image.png

用户反馈

功能全面的轻量级状态机工具。当前状态+事件->下一状态。靠谱,清晰,易懂。

点评

出院!

杏汇科技案例

user status

场景说明

杏汇公司医大师系统的用户状态图。用户状态使用数字进行枚举,状态变化相关事件为注册,解锁,复用,激活和后台增加。

image.png

researchJoinStatus

场景说明

状态很多,但是事件只有2个。【用户没有对该状态图有更多说明】

image.png

点评

用户案例中的数字貌似是直接与数据库中的字段保持一致,这样可读性较差。解决方案有两种,一种是这和最开始的xunit案例一样,需要支持用户自定义enum来增强模型的可读性;另一种是用户自己定义状态的enum,并使用enum的名字作为状态Id,但实际存储时可以使用对应enum的index。

xDecision案例汇总

有实际案例,但用户暂时不方便提供。后继将补充。

总结

正如当下中美科技战所表明的那样,能否拥有先进的生产工具是决定生产力大小最关键的因素。软件研发也是一样,如果研发人员没有先进的开发工具做支撑,强推研发规范,代码评审和单元测试很可能得到适得其反的效果。而后端研发工具已经很长时间没有什么突破了。

x-series系列后端低代码工具是基于十多年的后端经验教训而总结研发出来的。目的正是为系统的可理解性,可维护性,可复用性和可测试性提供落地工具,为研发效率带来质的提升。通过用户提供的一小部分案例,已经可以充分证明x-series确实实现上述目标。

参考资料

关于x-series的定位和与其他低代码工具的区别可以参考:低代码工具选项难题浅析

为什么研发规范,代码评审,单元测试这么难以推动

如果想进一步了解xunit和xstate并快速上手,可以看看:

再要扯皮,就上Xstate

还在Show me the code?试试xUnit吧!

有任何建议和问题都可以反馈到在线QQ技术支持群:

x-series支持群群聊二维码.png

X-Series Github地址

关于本文所提到的问题欢迎大家在评论区留言讨论。