产品的拼装化之概述

最新推荐文章于 2024-09-19 23:35:26 发布

陀罗犬穆

最新推荐文章于 2024-09-19 23:35:26 发布

阅读量250

点赞数

分类专栏：说说架构文章标签：项目架构

本文链接：https://blog.csdn.net/wurenhai/article/details/120648638

版权

4 篇文章 2 订阅

订阅专栏

产品拼装化的思路

对于公司来说，都有一种本能的想法（多家公司都有这么一种想法，所以我就把它认为是“本能”了）：

貌似一相简单的想法，做起来是相关复杂的，涉及公司的开发策略、资源调配等。这里主要简单的介绍：以组件拼装的方式构建产品的技术实践。

关于组件化产品拼装，其本质的思路为：

即：

为了方便下文的描述，这边需要统一以下概念：

这里有几点需要注意：

用组件一词，但是跟一般意义上的组件有所不同。通常情况下，组件多用于某端范围内的，如Android的组件，可能就是指一个UI的小控件、或者包含一定业务含义的二次开发单元。而本文所说的组件，是业务领域的全实现，有各端的实现有。因此，内部也有人称之为”业务组件“，但为写文章方便，如无特别说明，还是叫组件。
强调多端的交付，当然，并不是说有多端的交付，就是hyber的开发模式，手机端与Web站，就是一种响应式的变更。这边强调的更多的可以按端进行业务UI展现上的拼装，以满足业务多样性的需求；

以组件的方式拼装产品，比较自然的思路，可以拆分为：

针对以上两部分的内容，具体分析如下：

针对组件的开发，从逻辑上，可以分为：

组件服务：有云平台中提供单一业务领域的软件服务，可以看成是一种SaaS。由于需要支撑产品的拼装，因此也要支持租户化方案；
组件管理：这里主要指组件的管理台，有运维管理、运营管理。一般来说，运维管理偏向组件开发者的，比如技术上是限流、缓存配置等；运营管理偏向产品配置人员，可以是某些的UI变更、或者可选功能的确认；
组件Web端：组件的Web端，提供包含业务的UI级控件库，让产品配置人员通过UI的组装，形成产品的站点；
组件移动端：组件的移动端，提供包含业务的UI级的组件库，简单的是业务的完整界面，复杂点的也可以是包含业务的控件库；

对于组件的开发平台，即负责组件中上述组件内容的开发任务。笔者所在的公司，采用统一的DevOps平台实现组件颗粒（即可独立开发、部署的单元，如JS组件、WEB应用等）的开发、部署、运维流程的控制。这边就不扩展介绍了。本文主要关注组件上述规范的经验说明。

考虑以下的产品模型：

如上图的产品业务模型，举个例子，笔者所有的公司做教育类产品，在省级的三通两平台类的产品中，往往会有：省级的学习空间类的需求，那么同样会有市、乃至校级的学习空间，那么对该类的需求，采用同学的租户化管理，显然开发起来更自然些。

那么上图的产品业务模型中，就要求在产品中需要考虑产品中多租户的场景。对于多租户的开发：

对于租户隔离的维护，存在以下的思路：

按组件独立隔离，每个组件都可以拥有独立的租户标识。该场景下，为统一管理产品、以及组件租户的关系，可以创建租户管理服务，从而实现对产品的租户的创建、查询；
-.通过规则管理，按业务规范明确组件租户标识。相对前者该方案的优势在下租户的可控性更强些，另外，考虑到像三通两平台的建设中，存在校级的子业务，规模是10W级别的，此时单产品的租户数据可能超1000W（子业务数*组件数，组件以100个算），因此也能进行数据压缩。

那么，可以采用如下的租户模型：

如上图所示，通过产品标识（app id）与业务名称（biz name)共同组件租户标识。

对于客户端的租户标识的传递，比较简单，在请求头中增加app id、biz_name即可。

这边讨论几个在客户端比较优雅的识别出app id、biz name的方法：

通过域名：特别是WEB站点中，对于用户来说首先输入的是产品的域名，可以建立域名跟组件租户的映射数据实现站点域名的识别。其要点在于网关层需要支持多域名、多服务的路由关系，笔者所在的公司通过KONG的插件开发实现该路由规则的统一管理；
划分业务层级：在客户端，特别是移动端，产品中进行业务切换时，都会有一个明显的页面变更。根据此特别可以建立上下文，对子业务进行统一的切换；