微信旅游网站建设,有的网页打不开是怎么回事,广州网站推广排名,中小企业官方网站导读#xff1a;集成开放平台采用的是混合云部署架构#xff0c;包含两个大的组件#xff0c;管理控制台和引擎。管理控制台是SaaS的#xff0c;部署在公有云#xff0c;按租户隔离。引擎部署在客户私有云。一套SaaS版的管理控制台如何适配不同客户的引擎#xff0c;本文… 导读集成开放平台采用的是混合云部署架构包含两个大的组件管理控制台和引擎。管理控制台是SaaS的部署在公有云按租户隔离。引擎部署在客户私有云。一套SaaS版的管理控制台如何适配不同客户的引擎本文将介绍我们的最佳实践。一、背景集成开放平台采用的是混合云部署架构包含两个大的组件管理控制台和引擎。管理控制台是SaaS的部署在公有云按租户隔离。引擎部署在客户私有云。由于业务、管理的差异不同的客户其本地引擎的版本也存在差异甚至版本跨度会比较大。随着客户的增多不同客户的版本差异越来越大云端一套管理控制台如何兼容不同客户的后端版本挑战也越来越大。下面通过一个例子来阐述这些问题。二、问题客户A的租户环境是我们19年部署的一套环境客户B是我们另外一家客户。A客户的诉求是只需要保持稳定就可以了不需要对他们的环境做任何的升级B客户的诉求是我们的产品必须要不断升级去满足他们的需求。那么基于这种现状我们给客户A在他们的服务器部署一套后端引擎在客户B的服务器上也给他们部署了一套后端引擎。基于客户A的诉求客户A的引擎版本可能一直稳定在2.0版本但是基于客户B的诉求我们需要给客户B进行产品升级那么经过一段时间的迭代客户B的后端引擎版本可能已经升级到了3.4.x.x了。但是这些客户却公用一套web端部署在公有云上。一套web端页面对应多个后端引擎造成的问题就是客户A进入web端页面之后有各种报错因为web页面中很多的新的接口在客户A的引擎中不存在。为了解决这一个问题我们有2种方案。三、解决方案方案一组件纬度加版本控制通过在前端页面的逻辑中判断当前引擎的版本号来决定是否要请求某一个接口、显示某一个模块用新的数据结构还是老的数据结构 优点1、可以公用部分组件以及部分页面逻辑 2、是最快速最直接的响应需求的方式 缺点1、因为写了很多兼容逻辑会导致项目体积过大影响打包速度 2、引用的三方库的升级对历史版本可能会有影响 3、公用组件的升级需要考虑对历史版本的数据结构的兼容增加组件的复杂度后期可能会更加难以维护方案二对不同版本的前端资源进行物理隔离我们把云端控制台分为三部分console、ipass-console、mipconsoleconsole是我们云端控制台网关主要是做身份验证、租户管理等功能租户管理模块维护了各租户的引擎地址主要把各租户的管理控制台(mipconsole)来的请求转发到该租户所对应的服务端引擎。ipass-console主要包含登录、租户管理等模块。从ipass-console租户管理模块的页面可以进入不同租户的管理控制台。mipconsole是各租户管理控制台页面。包含接口中心、事件中心、服务编排、数据集成、仪表盘等功能。ipass-console发送请求到console控制台网关网关会直接操作console控制台的数据库由于各租户的服务端引擎是私有化部署部署在客户自己的服务器上所以不同租户的引擎地址不一样mipconsole发送请求到console控制台网关网关会把该请求转发到租户的服务端引擎引擎接收到请求会操作引擎端数据库。由于ipass-console不需要跟后端引擎做关联的所以不需要做版本区分。但是mipconsole是各租户的管理控制台的功能。那么mipconsole是如何做到对各个租户的管理控制台的web端资源做到物理隔离的呢答案是通过git的分支来做到对不同租户的web端资源来进行物理隔离。下面我们结合上面我们的问题来进行阐述 1、web端各版本资源的物理隔离我们如何通过git分支来做不同的租户之间web端资源的完全隔离呢首先我们把客户A的租户的前端资源当作一个基线分支基于这个基线分支切出一个开发分支在这个开发分支上开发客户B的新需求当第一批的需求开发完成并且测试验收通过之后我们会基于这个开发分支打一个tag并且把开发分支合回基线分支在基线分支编译出一个正式静态资源包放在我们主工程ipass-console的web目录下。下次在有新的需求时在基于最新的基线分支切出开发分支重复上述过程。如果后期在迭代过程中发现之前某一个版本有bug那么我们会基于那个版本的最新的tag切出一个hotfix分支修复该bug修复完成并测试通过之后基于当前的hotfix分支生成一个新的tag同时基于当前的分支编译生成一个新的静态资源包替换之前老的资源包。bug的修改不会新增静态资源包只有无法兼容的新需求需要写版本判断的这种才会新增一个静态资源包。这就是mipconsole各个租户管理控制台的前端资源的物理隔离方案。2、web端各版本资源的加载、解析 console是我们云端控制台网关因为不同的租户引擎地址不一样所以前端无法直接访问引擎地址所以前端会先发请求云端控制台网关 网关在把请求转发到相应租户的引擎服务去。在项目初始化的时候console会去遍历主工程ipass-console下的web目录下资源目录的文件夹名称生成一个前端静态资源目录与后端引擎版本号的一个映射文件缓存在内存中。当console接收到前端的请求地址是以/cloud/ 开头的就会根据请求的参数租户corp_id和环境env_id去数据库里查询当前环境所对应的引擎版本号然后通过引擎的版本号去映射文件里面匹配到前端的静态资源的文件夹名称把匹配到的静态资源文件下的index.html返回给浏览器浏览器下载了index.html后js会自动解析并导航到对应页面。这样进入某一个的租户的管理控制台之后浏览器只会加载某一个版本的前端静态资源。以下是我们的项目工程目录1、 资源工程的各个版本的分支如下图2、主工程、各个版本静态资源包以及各个静态资源包所对应的后端引擎版本号如下图V3.1.0.0 、V3.2.0.0代表的是前端资源的版本号minVersion 代表后端引擎的最小版本号。如果当前后端引擎的版本号3.1.1.1 大于等于3.1.0.0小于3.1.22.0则对应加载3.1.0.0版本的前端资源。前端版本资源与后端版本资源是一对多的关系以实际的正式发版时的后端版本号做为前端匹配的最小版本号。3、各个版本资源包所对应的tag号如下图四、总结针对多租户的前端工程管理的方案困扰了我们很久市面上也没有我们这种业务场景所以我们也没有可以参考的标准解决方案我们一直在思考寻找最适合我们的解决方案在这期间我们发现现在比较流行的微前端的思想或许可以解决我们的问题但是当我们去预研这些流行的微前端框架single-spa、qiankun等发现都不太适合我们的业务场景于是我们基于这些思想预研出了最适合我们自己业务场景的方案。在我们的工作中对于一些比较好技术和框架我们不能生搬硬套而是要基于我们实际的业务场景来考虑是否适合我们我们可以借鉴别人好的思想来形成我们自己的技术方案和技术体系。------ END ------作者简介郭同学 前端工程师目前负责集成开放平台的研发工作。也许您还想看技术分享Java SDK动态数据源和上下文机制技术分享NodeJS分布式链路追踪实现技术分享 | Java SDK 元数据驱动的事件通信架构技术分享Hangfire深度实践技术分享 | APT结合JavaPoet生成模板化Java源代码文件技术分享 | 玩转高效UI自动化测试更多明源云·天际开放平台场景案例与开发小知识可以关注明源云天际开发者社区公众号【建模】文档服务提供高保真打印模式明源云·天际硬核技术认可获华为鲲鹏技术认证书天际·开发者社区“重装发布”
