|一款企业内部使用的PaaS平台的概要设计

之前承接了内部应用系统效能提高的任务，组织设计了内部使用的一款PaaS云平台，旨在提供公共的功能给各个应用使用，未来可以产品化的应用也会在此上架，作为对外能力输出的平台，简单整理了下以飧读者。

本文插图

产品定位

产品架构图

本文插图

开发者部署发布上架单位为应当为应用单元。
应用如上图涵盖了网关，批量，数据报表，工作流设计，表单管理，业务对象建模，应用权限管理，以及开发者中心，这些都是初始化时已经上架的应用，租户可以在后续使用中默认开通这些应用，其他的应用也可可以据此作为基础服务通过sdk进行调用。

其中要有一个单元管理所有的秘钥信息（sso ， Oauth ， api访问等）。
网关要分对内对外两种，对外的要完成通过密钥验签完整接入的服务，以及通过账号登录完成的服务；对内的要实现支持dubbo的接口服务调用，而且要实现对bo对象的映射。
业务对象BO与表单的Vo之间的映射可以通过可视化操作进行维护。
业务流程设计完成后，需要按照流程上不同的角色给予不同的权限。

具体的落地方式更倾向于下图：

本文插图

功能路线图

本文插图

所有开发者的产品均以应用为单位存在在Paas平台，应用的构成见上图，有几个点要说明下：

接口按照应用为单位进行管理，即网关在应用下进行登记设置，以及相关的密钥也是按照应用单位去管理，目的为为了实现安全鉴权的隔离（在应用级别）。
网关的管理应当分内外，应该不能合并使用同一个网关（部署区域都不一样），内部网关建议可以简单些，不存在鉴权部分，外部需要鉴权，以及账户登录。
菜单配置，用户以及权限的管理，是在整个平台层面去管理分配，不在应用下进行管理，因为通常来看用户要使用多个系统的多个权限，应用下维护太琐碎，不易使用，需要多次重复操作完成。
字典值系统参数是在应用下单独设置还是全平台设置？（待定，讨论下），因为角色权限确认后，用户进到应用下初始化已经完成，需要的字典和系统参数是在应用层面下维护比较好？（个人认为是在应用层面下）。

产品特性
目前基于PaaS金融云的业务形态主要有两种，具体介绍如下：