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

上述这些问题的表现都可以用一个字来总结，那就是"乱" 。
4. 如何戡"乱"

文章插图

那么我来讲一讲如何戡乱，首先我们深入分析一下乱的原因。
① "乱"的原因：
a. 智能系统特有的复杂性，涉及到庞大的服务依赖，数据依赖，知识依赖。推荐系统涉及到的服务模块很多，而一个服务又涉及多个依赖，整个服务的依赖关系就会很复杂，从而管理上就需要很大的成本。数据依赖层面，系统涉及到大量的原始摄取数据，中间加工数据，以及最终的结果服务数据，数据的质量对最终的推荐效果影响是至关重要的，而这种依赖又非常的隐含，极易出错还难以排查。最后，特别提出"知识依赖"这一概念，推荐系统一直以来在应用系统中以其技术复杂性著称，其在工程上，策略上，数据处理上，算法模型上，有很多模式经验及潜在技能门槛。但这些知识在系统中是隐性的，存在于架构师、专家的脑袋里面，并没有固化和沉淀到系统内。强依赖架构师凭借自己的认知和经验去构建，驱动整个系统流程。而正是因为是人来主导，那自然会随着人的水平的高低以及偏好，产生实现上的差异，难以沉淀和继承，后期持续演化也会很脆弱。
b. 领域架构缺失现有的框架都在解决局部问题，需要抽象出一层专门解决推荐场景应用开发领域自身的问题。比如Airflow是做离线任务调度领域的平台工具，Flink是做数据处理领域相关的框架，这两者都是各自领域很优秀的框架或平台，但是要解决推荐领域的问题，他们都只能解决其中部分子领域问题，缺失一个面向推荐领域的一体化平台或框架，其结果就是从业务问题直接穿透到子领域层，在实现上，缺乏抽象和隔离，使用胶水代码将下层服务拼接在一起完成逻辑实现。虽然子领域框架能够解决了一些局部问题，但它们之间如何协同，管理，以及在其之上更有序的解决推荐领域层面的业务问题成为了如何让架构更好服务场景业务的关键。所谓戡乱，就是需要形成一个中间推荐场景开发的领域层，承接服务依赖，数据依赖，知识依赖，并协调子领域服务更有效工作。
② 这一层应当如何做？
a. 统一的场景开发和管理接口。对于上层来讲，开发一个"看了又看"，"买了又买"等不同的场景，开发过程和接口应该是相似的，只需要面向这一层开发，无需关注下层细节。
b. 统一的底层架构和集成标准。下层非常复杂，涉及到众多子领域，作为开发者，常常在选型和集成上犯难，也无法将它们协调起来，那么我们需要这一层能够把复杂度给屏蔽掉，开发者面对的是统一的数据结构和接口规范，而无需关注具体的执行层选型和实现。
c. 领域内要素治理：

合适粒度的领域实体抽象及实现。在推荐服务中，有大大小小的服务，规则，策略及数据，我们称之为领域资源要素，它们需要有合适的领域抽象和粒度，粒度不能太大，也不能太小。是一个规则那么我们就用规则去承载，如果是一个服务，那么我们就应该用一个服务来承载。这样能够在提供灵活性的同时，控制整体复杂性
统一灵活的管理方式。我们需要针对领域要素有统一灵活的管理方式，领域的业务逻辑通过统一的编排管理方式来构建。
成熟可复用的单元。资源要素的载体是成熟可复用的单元，组件、策略等避免重新开发，产生重复的成本，应该通过复用让使用者更低成本使用。

有几个指导思想，来指导我们具体应该如何将这一层做好。
02
推荐系统"治理"的指导思想
1. "治理"的指导思想

文章插图

① 声明式 ( Declarative )：解决复杂系统，复杂流程管理的灵丹妙药。早期在没有k8s的时候，微服务运维管理是一个复杂的过程，需要人工编写很多的脚本完成应用的部署更新扩缩容等工作，使用者必须明确描述其所有操作细节。因为相对于声明式，这种过程命令式的运维脚本，需要使用的人要能够掌控过程执行所有细节，这对于大型复杂系统来讲是一个很大挑战。声明式编程的思想流行会使这样的工作大大简化，服务负责内部自身复杂运行逻辑，上层使用者只需要声明出自己的目标即可，系统自动帮你完成，无需关注其达成目标的具体过程。就像SQL一样，之所以大家用着觉得简单，其很大原因是SQL就是一个声明式的编程语言。这一思想已经逐步成为架构师解决复杂系统管理的推荐思路。比如，当下很热门的运维部署框架Ansible，运维人员只需要按要求编写安装部署剧本，系统就会自动安装和部署相应的服务。