推荐系统架构治理( 四 ) _推荐系统

② 框架平台：在目标定位上，是开发一款工具，还是开发一个框架平台，会直接影响到我们的系统设计决策。工具的特点是被集成，可以为使用者提供更灵活有效的手段解决具体问题，但对于使用者本身有比较高的要求，最终结果如何，高度依赖使用的方式。而对于框架来讲，将实现过程让渡给框架，开发者无需了解全过程，只需要按照框架提供的规范进行开发即可，这一定程度约束了开发者的行为，也降低了上手门槛，这实际上是依赖反转思想的体现。我们提到的知识依赖，就可以通过框架或平台把它们沉淀下来。而使用者自然会在框架的帮助下，使其开发的系统是相对可靠的。比如web开发框架Spring，亦或是持续集成平台Jenkins，它们的作用就是提供一个领域业务模式或流程，能够使得初学者只需要掌握平台或框架的使用便能在其领域达到一个比较高的水平，获得方法论指引，避免前人的错误。
③ 组件化：其特点是标准化，复用性和灵活性。框架和它是依存关系，是它的契约，组件是按照契约去实现及被集成。
④ 低代码 ( LowCode )：特点是简单，快速。当下比较热门的概念，一个框架或者平台，不需要写代码或者少写代码就能够完成开发，是基于框架开发基础上的更进一步，能够将业务过程，核心逻辑封装成一些低代码的模块，这对于简单化业务过程，降低使用门槛有很大的帮助。
2. FlowEngine

文章插图

基于上述的挑战及解决思路，第四范式研发了这样一个声明式的、低代码的、组件化的智能场景开发和管理的框架平台。在这个框架基础上可以快速开发和管理推荐等智能场景。
03
Flowengine架构
接下来简单介绍一下Flowengine架构，它位于场景业务服务和子领域执行层之间。它的出现其目的便是将我们缺失的领域层补充上。
1. 表现

文章插图

Flowengine提供了一套声明式API，可用来创建，管理智能场景 ( 推荐 )，表现为以下方面：

场景沉淀，迁移，快速构建。在框架无状态的前提下，将应用逻辑，业务规则和服务依赖保存成一个方案文件，从而做到可以在不同的Flowengine平台下无痛迁移分享。
领域要素 ( 组件，JOB，FUNC等 ) 的管理，集成，更新。提供要素的开发，发布，集成，运行等全生命周期管理，使得其能够在明确的标准下被集成和管理。
业务逻辑编排 ( 批/流/在线pipeline ) 。场景业务逻辑是对领域要素的逻辑编排，这就使得其天然具备敏捷性，业务上也能做到垂直切分隔离，却共用相同的执行底层。在业务隔离和资源共享层面达成了统一。
预置核心组件及标准流程方案。简单的业务可以通过已有方案自动的生成推荐服务，达到开箱即用的目的。如果存在场景差异也可以在此基础上进行修改和完善，但修改过程仅仅发生在方案场景层面，从而有效的控制了修改风险蔓延，做到了框架与方案的分离，从而在易用性，规范性与灵活性，差异性上达成了统一，这个在传统架构上是一个不可调和的矛盾。
标准化的底层集成方式，上层简单，下层开放。标准化的底层集成方式，均采用业务组件或技术组件的方式集成，对上层呈现为可被pipeline编排的资源要素，使用者无需关注执行层差异。这样就保证了上层是接口简单，下层是开放的。

2. 构成与基本实现