从单一系统到SaaS平台的架构设计（以考试系统为例）

1+X考试系统完成了一期、二期的从0~1建设，并投入应用一年后，基于应用实际情况，我们进行了三期的建设，核心在于增加考务相关功能以及交互、跳转、鉴权的优化。至此我们的考试系统具备了考试证书管理、考试科目管理、考试等级管理、试题库、在线组卷、考生基础信息管理、考试资源管理、排考管理、考试编号及身份验证管理、模拟考试、正式考试、考试策略管理、考试成绩管理及考试异议管理。

接下来，我们在完成支撑自身1+X考试业务支撑能力建设的基础上，进行考试系统的SaaS化改造，需要关于的几个点：

1、对SaaS的认知

SaaS平台的意义在于，产研边际成本趋向于零，而租户新开带来的收益会随着时间，为我们带来营收的累计。具体到考试SaaS平台，首先，要将通用的考试黄金能力全部解耦出来；其次，此前依赖于在线学习平台的账号和权限能力，全部迁移至新建的iDaaS+USF底座能力上；最后也是最复杂最重要的部分是将不同用户的不同应用场景进行抽象，设计为统一的SaaS平台能力。

2、关于统一权限能力

虽然理论上权限粒度越细越好，但是我们的平台支撑的业务系统较多，能力点更多，全部能力点都拆分为赋权的对象，在平台实际应用的过程中，带来巨大的实施及数据初始化成本，而且极易出错，这种粒度的异常，靠人工来排查，成本太大，靠告警平台来监测，又会陷入开发一个系统孪生一个告警系统的成本居高不下的恶性循环中。

对于我们此次的考试SaaS平台，权限的对象应该对标到三个点，通用能力、可闭环能力单元和级联弧。

通用能力：相对好理解些，不论是B端，还是C端；不论是国家1+X考试、体制内学校学科考试、公司组织内的达标考试还是自己的组织的赛事类等特殊考试，均会设计登录登出、试题组卷、成绩查询这些通用能力。

可闭环能力单元：除过上边的通用能力外，比如排考这个功能，C端考试的应用场景就不会涉及，但是校内或者成规模的考试就一定会涉及到，这个能力单元就是闭环的。不同租户根据具体的业务场景需求，要不就全部调用这些闭环的能力单元，要不就不调用。这个逻辑和研发封装中的对象的概念如出一辙。

3、关于通用流程的打通

流程图务必把通用流程拉通，这样就具备了一个SaaS平台的全量能力点。同时产研对齐的时候，也可以从上帝视角来审视这次的SaaS化改造，知全局，而分版本，敏捷迭代。

4、关于分枝业务的支撑

流程图中在复杂场景应用的部分，要按照场景拉出来分枝；不同的分枝复用能力的时候，将个性化的能力点单独标注出来，用以表示不同类型租户下的特定业务场景，在产研对齐的时候，可以帮助研发在知全局的前提下，关注到特殊场景的应用，在表结构设计，数据逻辑、级联关系梳理及权限粒度切割的时候，更能有的放矢，并将业务场景带入到研发工作思考中。

5、关于平台化产品的架构设计

题库是我们这次考试SaaS平台的关键能力点，题库在产品化层面的设计，一定程度上影响了我们这次SaaS产品化的成功与否。我们这次的改造，着眼于平台化设计，在集成此前题库服务系统的基础逻辑上，要增加题库服务定向租户，租户题库数据隔离的设计；更为重要的是，要引入试题广场的概念，参照PUGC的平台生态逻辑来设计我们的题库，使得我们的租户不仅可以使用平台预置的试题，还可以自行建设校本题库，同时可以将优秀题库发布至平台中，与平台下的不同租户共享共建，逐步通过SaaS平台能力，形成生态聚合流量，通过产品化，赋能商业化。

6、关于商业化的思考

系统产品能力的建设，目标大致会有降本、提效、赋能商业化。我们之所以要将考试系统改造成SaaS，目标初衷就是将自用的系统能力对外开放，赋能营收。所以对于用户使用方式、使用体验、使用场景的设计，与此前的产品设计会有较多差异，也可以把这次的改造看做是一个从0~1的过程，这个过程更多的是考虑外部用户的场景需求。后续我们还会陆续有此类系统产品，从自用向外放演进，比如我们的游学系统，我们的证书管理系统等，这也是体现系统开发边际成本趋向于零，而不断赋能商业的，系统价值。