关于平台的一点想法

4年前在上一家公司，实现了一个RBAC平台，现在回头看一下，那个平台还很幼稚

一种常见的情况是，一个公司会有多个业务系统，每个业务系统都需要一些共享的东西

在我理解，共享包括2个层面：

较低的层面仅仅是二进制共享，比如数据库访问、服务路由等代码。将这些公共代码封装成jar包，如果没有业务系统的话，这些代码就无法运行

较高的层面是服务层面，比如用户管理、权限管理、登陆、鉴权、日志平台等。这个层面的东西，是能独立部署运行的，以组件的方式向业务系统提供服务。但并不是说这个层面就不向外提供jar包。一个典型的例子是CAS，除了服务端的CAS Server之外，也向客户端提供了CAS Client

我认为这2个层面综合起来，可以称为一个开发平台

上面所说的平台，涉及到以下这些概念：

统一用户：每个业务系统不需要单独维护用户信息，而是在平台统一维护用户信息，但是各业务系统可以根据自身的特殊业务，对用户信息进行扩展

单一用户管理：所有涉及到用户管理的动作，比如增删改，都在平台里实现

SSO：也就是单点登陆，在平台里实现所有业务系统的登陆和登出

LDAP：SSO的用户校验部分，有时候会基于LDAP实现，不过我个人感觉这个协议现在用得不太多

跨域访问（同源策略）：javascript不能跨域运行（包括子域，比如mail.xxx.com上的脚本，不能修改message.xxx.com上的页面）

RBAC：一般来说，既然用户是在平台里统一管理，那么相应的群组和权限，也应该在平台里实现

我有一个想法，还没想得太清楚。

平台独立部署，作为SSO Server，业务系统登陆时，首先跳转到平台上，登陆成功以后进入一个index.jsp（index.jsp部署在业务系统所在服务器上，但是可能也是由平台提供的）

然后index.jsp加载index.js，发起ajax请求（可以用服务端代理的方式，绕过同源策略），在平台服务器获取用户的权限信息，在页面上渲染生成菜单

同时，平台提供了公共的js、css等公共UI组件，实现各业务系统的UI一致性，这个可以称为UI框架

此外，平台还提供了公共jar包，封装了各业务系统的公共代码

大致就是这样，总的来说，我认为一个完整的平台应该具备以下的特性：

1、提供公共的服务，业务系统无需重复实现

2、将公共代码封装成jar、js、css，简化业务系统开发

3、界限明确，平台提供的服务，必须保证业务无关性。在设计时就需要考虑清楚，什么东西应该放在平台里，什么东西应该交给业务系统自行实现

4、业务系统能够对平台提供的组件进行自定义扩展

5、当平台升级时，业务系统只需要进行简单的文件替换即可实现，即透明升级