之前承接了内部应用系统效能提高的任务，组织设计了内部使用的一款PaaS云平台，旨在提供公共的功能给各个应用使用，未来可以产品化的应用也会在此上架，作为对外能力输出的平台，简单整理了下以飧读者。
搭建金融云PaaS平台，提供统一平台输出软件产品，实现业务的快速打包发布；
提供统一的控制台集成框架，界面标准化，整合用户权限、消息中心等公共服务；
提供统一运维、运营工具平台；支持多个公有云部署，私有云部署；
基于云服务商提供的容器引擎，金融云全面容器化，低现有金融云资源使用可弹性扩展，业务连续性达到%；
按安全规范的搭建生产环境网络。
开发者部署发布上架单位为应当为应用单元。
应用如上图涵盖了网关，批量，数据报表，工作流设计，表单管理，业务对象建模，应用权限管理，以及开发者中心，这些都是初始化时已经上架的应用，租户可以在后续使用中默认开通这些应用，其他的应用也可可以据此作为基础服务通过sdk进行调用。
其中要有一个单元管理所有的秘钥信息（sso，Oauth，api访问等）。
网关要分对内对外两种，对外的要完成通过密钥验签完整接入的服务，以及通过账号登录完成的服务；对内的要实现支持dubbo的接口服务调用，而且要实现对bo对象的映射。
业务对象BO与表单的Vo之间的映射可以通过可视化操作进行维护。
业务流程设计完成后，需要按照流程上不同的角色给予不同的权限。
具体的落地方式更倾向于下图：
所有开发者的产品均以应用为单位存在 在Paas平台，应用的构成见上图，有几个点要说明下：
接口按照应用为单位进行管理，即网关在应用下进行登记设置，以及相关的密钥也是按照应用单位去管理，目的为为了实现安全鉴权的隔离（在应用级别）。
网关的管理应当分内外，应该不能合并使用同一个网关（部署区域都不一样），内部网关建议可以简单些，不存在鉴权部分，外部需要鉴权，以及账户登录。
菜单配置，用户以及权限的管理，是在整个平台层面去管理分配，不在应用下进行管理，因为通常来看用户要使用多个系统的多个权限，应用下维护太琐碎，不易使用，需要多次重复操作完成。
字典值系统参数是在应用下单独设置还是全平台设置？（待定，讨论下），因为角色权限确认后，用户进到应用下初始化已经完成，需要的字典和系统参数是在应用层面下维护比较好？（个人认为是在应用层面下）。
目前基于PaaS金融云的业务形态主要有两种，具体介绍如下：
纯saas化服务形态，所有产品均以API的形式对外服务，在一个环境下集成服务，所有的用户数据按照租户隔离，每个SaaS金融云租户有自己的计费方式和费用明细，数据底层可以实现共享，增益部分应用功能（如图谱等），一般来说此种形式仅对调用进行按照包时或者包量的服务进行收取费用。
基于PaaS功能的SaaS服务，即为根据用户需要，以一体化全栈方式交付完整的云服务金融云，部署在客户要求的环境（有可能同一云开辟不同vpc，也可能跨云），以确保安全合规，运维面通过专线接入联招运维中心，统一运维以降低运维成本。
按需提供集成过应用的镜像进行部署，由我方人员代为维护，委托方只需要定期查看运维状况和金融云费用情况即可，此种模式费用一般为采用资源（比如应用的线路共享）调用情况（按照包时、包量等）计费，以及对环境进行托管的运维费用构成。
商户主要用户角色：
机构系统运维人员
机构业务人员
机构财务人员
机构开发者
机构业务系统
金融云平台综合运营主要用户角色：
平台开发者
平台系统管理员
平台运维人员
平台财务人员
基于用例角色进行了功能划分，其实相对结构比较简单，主要分了租户管理端和平台运营管理端，额外提供一个开放平台的入口供系统和开发者调用。租户管理侧主要进行了个人中心和费用中心以及自己的访问授权相关的配置，包括不限于密钥，权限，角色的获取和分配。
运营端主要是进行用户自身管理、租户管理、应用的上下架管理以及费用相关的配置支撑。
企业信息审核流程：
企业用户通过短信完成注册并登录，提交企业相关信息后，云平台运营人员进行审核，审核完毕用户企业认证通过，可以进行下一步其他操作。
应用上架流程：
应用上架步骤比较复杂，要先完成应用单元的新增，配置必要的应用菜单，主要是菜单和接口相关信息，然后要配置应用到首页（首页的位置，分组等），并配置先关权限角色，此类资源主要是默认的一个权限的分配，如果机构用户有需要可以在拿到菜单资源后自行组织，最后完成上架操作。
产品服务开通流程：
产品上架的服务内容流程见上图，更多的步骤是依赖于线下的操作，商户浏览产品后选择试用，进行试用登记，后台客服根据登记信息联系商户进行确认，并获取资料进行审核，在后台开启服务订单。
应用服务API调用流程：
平台涉及的几个重点功能的领域模型如下，主要体现了核心管理功能的领域模型设计思路。
首先是核心账户体系，用户账号与商户是一对一绑定的关系，企业信息和商户也是一对一的关系，用户信息与用户账号绑定，可进行相关修改，所有的商户自管理都是通过这个用户进行操作，左右的订购关系都是通过商户维度去建立关联关系，这样为后续的账号可修改变更主体，抽离出来账号与商户的关联关系。
如上所述，所有的订单、产品、账单费用均与商户相关联，这样方便在后续建立复杂账户与商户关系时能够降低耦合。
