如何打造一个满足快速定制能力的私有化部署系统？

打造私有化部署系统过程中的一些和总结

场景

我们来看一个场景，一个『规模不大』或者『精力有限』的中小型公司，接入三方公司的效率工具，比如 IM 工具（企业微信）、文档协作系统（语雀）、问卷系统（问卷星）、绩效系统等等。三方公司提供接入的主流方式为 SASS，通过用户分级的方式（普通用户、会员用户、企业用户）售卖自身的产品，这对三方公司来说，易于统一维护。

然而我这边举的几个例子往往关系到公司内部的敏感信息，比如高层员工间的对话、核心战略文档、eNps 调研数据、绩效信息等。这些数据如果保存在三方公司维护的服务器里，多少会有一些安全问题；此外『用户分级』的方式就像套餐，难以满足各类用户的定制需求。因此目前越来越多的三方公司支持私有化部署的方式，将自身的服务部署在客户指定的服务器上，比如企业内部机房、公有云和专有云（阿里云、华为云）。目前，我们对外提供的一款服务也遇到此类问题，当客户不满足于我们提供的『用户分级』套餐，且对『数据存储』十分敏感时，我们如何快速定制并私有化部署服务呢？

现有问题

直接将现有的系统，打包部署到客户指定的服务器上不就完事了？事情没有这么简单，它存在如下3个关键的问题：

一、依赖内部环境

在公司内部维护了多年的系统，不少能力都强依赖了内部提供的基础设施，比如 CDN、数据库、缓存服务、动态配置、用户体系等。这些基础设施可能在用户指定的服务器上不一致，甚至不存在。

二、缺乏定制能力

当开放用户对系统的定制能力后，现有的系统仅仅支持『用户分级』的方式，是难以支持用户『变幻莫测』的定制需求的，如何快速响应用户的定制需求，是需要全新的一套『模块组织方式』。

三、 并行维护成本

如果支持用户私有化部署，那么不得不面临一个这样的问题，当 N 个公司接入时，我们会同时维护 N 套系统，那涉及到一系列在多套系统之间同步 bug 和 feature 的规范、多个版本并行『开发调试构建部署』的研发流程。

解决方法

那么，如何打造一个满足快速定制能力的私有化部署系统呢？依旧从上述三点问题出发：

一、摆脱依赖内部环境

配置化

为了摆脱对内部环境的依赖，我们需要对现有系统进行配置化改造，支持对涉及到的基础设施进行配置，这些配置可以手动写在配置文件里、可构建时生成、运行时动态修改。最终做到根据 N 份配置，即可产出针对 N 个公司的部署包。

二、满足需求定制能力

模块化

抽离功能模块，通过『开关』、『配置』进行设置。那模块如何拆分和维护呢？拆分可考虑从『垂直』角度，比如『投放功能』、『个人中心』等；或者从『水平』角度，比如『登录』、『权限』等。

三、降低并行维护成本

系统融合

对现存的系统进行融合，维护一个基线版本的『基础版』，这个所谓的『基础版』有两个目的：

1. 当有新的企业需要接入时，可使用本『基础版』快速定制开发
2. 作为所有并行系统的上游代码分支（master），下游代码分支（各企业分支）定期从该分支 pick bugfix & feature

流程改造

我们的服务比较特殊（参考页面搭建类服务），有负责配置的 B 端，以及由 B 端生成的 C 端页面。这样我们就有 4 个工程，每次功能开发都可能涉及到 4 个工程的开发、调试、联调、构建、发布，同时 C 端的静态资源版本和服务地址又是自身决定的。这两点无疑增加了开发人员的心智负担。

首先，将 BC 两端的前后端各放入一个工程中维护，每次发布最大仅需要发布两次。同时 B 端既然作为配置侧，那么不仅 C 端页面本身的功能需要由 B 端决定，我们完全可以将诸如静态资源版本和服务地址这类配置也交由 B 端获取和设置。

接着，对应用初始化、开发、调试、联调、构建、发布进行规范，规范是一种约定，为了更好地将规范落地，有必要实现一套命令行工具或页面流程作为规范的载体。更进一步，可抽象应用概念，这样所有的流程都围绕着这类应用开展； BC 两端可以是这类应用，同时拆分的模块也可以是这类应用，此时我们的所有流程都是围绕着这个应用概念，也就是说，BC 两端以及拆分出的几十甚至上百的模块都共用一套初始化、开发、调试、联调、构建、发布流程。

配置化

此外，配置化也有助于降低并行维护成本，我们通过维护配置而不是维护各类代码逻辑。避免诸如『如果是A公司，就执行B逻辑』这类逻辑，配置更关注功能，比如 A 公司的配置开启了『B逻辑』。

除了降低成本之外，配置化还用于应对未来的规划，由于目前所有的企业『定制需求』都是通过人工方式去组装 BC 端应用。在未来当我们接入的企业越来越多，沉淀出大量的『模块』应用之时，便可去探索如何摆脱手工组装，也即通过在线页面通过搭积木的方式组装，借助于配置化，我们的设计可以很好地满足这个需求。

结语

此处仅简单讨论了下一个私有化部署系统所需要的改造，步骤三中的流程改造涉及到大量前端工程化相关的能力，还需进一步展开~