1. 应用配置——大门与钥匙
不同于toB与toC的项目，绝大多数中后台项目面向对象都是内部人员。所以很多情况下，业务方需要的只是不同的“大门”（域名）和相同的“钥匙”（内网账号）。因此渲染中心首先完成了根据用户访问域名不同，实现对应应用的渲染。而在此之后可以套用同一个钥匙，即可快速完成一个中后台“大门”与“钥匙”的制造。对于ABF平台而言，一个域名即唯一对应了一个应用。
2. 页面配置——多种多样的房间
在应用之下，ABF平台提出了页面的概念，以MPA的思路实现每一个页面相互独立，有着自己独有的页面与功能，又整体继承应用的配置。这样可以便捷的实现一个系统功能的拓展。想要一个全新的功能页面？来吧，新建一个“房间”（页面）吧！基于以上两点，在技术实现上，ABF渲染中心以域名与环境变量（daily/pre/prod）组成了应用的唯一标识，在路由匹配规则上，我们选用了servlet的url-pattern匹配规则。一方面可以满足我们精准匹配的规则，另外一方面通过/*和/**的匹配规则更好方便了页面的路由配置。
3.权限控制——人脸识别
既然钥匙是一样的，那就难以避免会出现只要我有这个钥匙，我就可以在所有“房子”的所有的“房间”里进进出出，显然这不会是业务方希望的。所以配置中心为每个“房子”里面的“房间”增加了一个“人脸识别”（权限验证），针对不同的页面、模块都可以通过增加权限验证来实现对访问的限制。为了更加方便的控制权限的授权，我们提出了租户的概念，即一个应用所有可访问的用户即为租户。而每个应用管理员只能管理自己应用对应租户的权限，避免了越权行为的发生。在权限这部分的技术实现上，首先我们确定了统一的用户信息结构体，包括用户id、名称、头像等字段，保证这个用户信息的结构体适用于多种登陆体系。用户信息结构的统一是权限验证的前提，而后通过用户ID、应用ID、权限点三者的关联验证来完成权限的控制。用户ID与权限点验证相信大家都可以理解，那么应用ID的验证又是为了什么？因为如果没有应用上的验证，那么权限点相当于对于所有人都是开放的。一个权限管理员可以管理所有应用的权限点。而实际开发过程中，我们必然需要自己管理自己的权限点。所以在权限点上我们做了应用的隔离。这一个隔离的应用ID在用户信息结构体上也有一个对应的ID，我们称为租户ID，即每一个登陆的用户我们都会有一个专有的租户与之对应，其与应用一一对应。租户A的用户无法通过租户B的权限点进行权限验证。保证了权限点之间的隔离。所以我们的登陆过程也就变成了：账号密码验证-租户选择-权限验证-页面匹配。一个用户可能有着多个租户身份，需要在登陆时候选择用哪一个租户身份进行登陆。
统一处理的权限申请页面
4. 布局配置——规范化的房子规格
一方面为了提高效率，另外一方面也为了整个中后台生态的规范性。我们提供了一个中后台统一的布局组件，定义了一个房子的“房间”应该怎么排布。同时提供了“房间排布图”（菜单）的配置。将一个应用的导航和菜单配置与源码解耦，大大增加了系统的可拓展性。
5. 自定义拓展——生成个性化的房间
在满足了99%的相似配置后，业务方就是想要一个独具一格的房间改怎么办？不要怕！配置中心提供了自定义“房间”拓展机制。类似于函数式的拓展方式，配置中心提供了一个统一的入参，包括用户身份验证信息、域名访问信息、应用配置信息等，只需要处理后的函数格式满足配置中心规定的格式，就可以实现自定义的“房间装修”。例如简单的优酷登录实现方式——通过拓展函数来验证优酷登录的用户信息，无论访问哪个页面只要你没有登录，都会渲染为优酷登录页：
其实之前几点的设计，基本上我们已经规范了一个页面的渲染结构：包括域名、环境、用户信息、路由匹配、权限、布局、菜单等。组成了一个ABF的页面数据结构体。通过自定义拓展能力，我们允许用户对这些所有信息都进行自定义的修改，只需要满足修改后结构满足ABF规定的渲染结构，ABF渲染中心就会根据返回的渲染结构渲染页面。如上面优酷MCN的例子，我们实现了自定义的用户信息结构体，同时通过对结构体是否有效的判断，修改渲染页面模板是否为登录模板。
通过以上几个方面的配置能力，ABF平台的配置中心实现了90%中后台应用创建所需要做的事情。通过ABF平台配置中心创建应用与页面即可快速的完成一个系统的创建与上线。
