1 项目背景
中国移动于2008年启动了中国移动总部FSSC层面财务集中管理工作，各省公司财务核算中心成立。
2008年5月进行财务集中管理报账平台和银企互联系统的全国集采。经过多轮与中国移动集团的技术交流和统一谈判，用友软件电信事业部中标9个省的报账平台项目和6个省的银企互联项目。 报账平台：9个省
黑龙江、吉林、辽宁、陕西、甘肃、宁夏、青海、西藏、新疆 银企互联：6个省
黑龙江、山东、广东、湖南、内蒙古、西藏 项目现基本都在进行第5-7期建设中
下图为移动各省报账项目建设历程：
2 建设目标
1、 基于私有云部署(中国移动报账项目)
以下数据参考的是中国移动报账项目日常数据
系统用户量:5000人 月单据量:1.5W张
日单据量:1.5W/20=750张 并发量：5000/25=200人 高峰期并发量:200*2=400人
全国数据大约为一个省的30倍左右.由此推算数据如下:
系统用户量:15W人 月单据量:50W张
日单据量:50W/20=2.5W张 并发量：15W/30=0.5W人 高峰期并发量:0.5W*2=1W人
数据库:DB2、ORACLE
2、 基于Saas部署（中小型企业租户模式）
以下估算数据按照10000家公司，平均一家公司100人计算
系统用户量:100W人 月单据量:300W张
日单据量:300W/20=15W张 并发量：100W/25=4W人
高峰期并发量:40000*2=8W人
数据库:MySQL
以上得知,系统需要满足如下: 1、8W人的并发量。
2、支持多数据库的部署。 3、租户之间数据隔离。
4、租户之间可以进行不同的后台管理。
本项目目标是建立一个生态化报账平台，报账系统建设目标主要分为四个方面： 1. 共享服务化：
a) 实现目标：集中核算、集中支付、集中审核、集中管控
b) 效果实现：标准化、工厂流程化，提高效率和质量，降低运营成本，加强内控。 c) 考虑要素：地点、流程、组织岗位、政策法规、技术、服务及考核
d) 采用技术：网络化报销系统、条码技术、影像技术、双屏技术、移动技术 2. 作业驱动的全业务化：
a) 全业务报销：收入、支出、人财物、产供销、投融资等所有主营业务、支撑业务全
部纳入报销体系，既是一个信息采集工具，有事财务联通业务的关键桥梁
b) 作业驱动：科目-作业预算-业务大类-业务小类-报销项目，细化到作业，以作业驱动
资源的消耗（即报销）。
3. 互联网化：
a) 云计算技术：云部署、saas服务 b) 移动应用：app、微信整合
c) 大数据分析：结构化、非结构化数据分析、经营分析、业务效率分析、用户行为分
析
d) 社交应用：在线客服、微信互动
e) 用户体验：前后台分离，工作台设计，界面友好，体验良好 4. 平台化：
a) 平台开放性：平台开源，提供第三方应用和服务的集成，更好满足客户需求。如商
旅服务、理财服务、电子发票等等。
b) 平台运营：包括客户自运营运营、用友自运营、合作运营等模式、代运营等多种模
式。内容包括：IT运维、流程配置、模板配置、影像扫描、档案管理、会计作业等等
从上图可以看出系统建设分为了三个阶段:
第一阶段：互联网化报账平台，该阶段以中国移动需求为原型，在全新的互联网开发平台上，实现报账的全面互联网化；完成报账核心应用大部分功能、辅助应用和支撑应用关键功能的上线使用；一阶段产品要求能满足移动各省现有报账系统的迁移。同时能实现与NC对接，对外向NC集团客户推广。
第二阶段：集成化报账平台，该阶段完善和丰富报账核心应用、辅助应用和支撑应用的
功能；完善前端门户应用的功能；实现移动应用，由微信整合到APP开发使用，提高报账业务效率和体验；二阶段产品要求在丰富功能的基础上，重点考虑提升用户的体验；
第三阶段：生态化报账平台，考虑引入和集成第三方应用服务，增强平台服务功能，满
足平台客户多方位的需求；在丰富和完善平台服务功能的基础上，开发平台运营管理功能，满足平台的第三方运营要求；具备对外咨询服务能力，建立完整运营体系，实现运营的多方位价值变现。
使用客户结构从大型单一集团至大型多元化集团至大型企业及小型企业到项目型组织不断演化及支持；
3 建设范围
实现前后台管理系统的分离:
功能范围分为前台应用和后台管理；其中后台管理分为系统管理和业务管理；
公共功能：帮助中心、忘记密码、用户信息、
设置功能{主门户设置、委托授权设置、工作交接设置、系统安全设置、个人信息设置}、 消息管理{代办事项、代阅事项、系统公告}、 门户切换功能
报账人门户：检索功能、收藏夹、
报账人首页{常用单据维护、报账单据过滤、填报、收藏、最近报销单据、系统公告、建议咨询}、合同管理、票据箱、
报账单据{规划25张单据+四川移动需求+移动在线及互联网公司需求}、
我的报销{首页面、我的申请、我的报销、合同管理、票据箱、账表统计、消息管理、收藏夹} 审批人门户：
审批人首页{代办任务、代办审批、常用报表、关键指标分析、常用单据、最近报销单据} 我的报销{首页面、业务申请、报销单、账表统计（2张左右）、消息管理} 财务处理门户：
财务处理首页{代办任务、代办审批、系统公告、建议咨询、作业统计}
报账基础管理{借款控制规则、备用金额度设置、费用类型设置、地区类型设置、报销标准设置}
期初管理{借款期初、合同期初、预算期初}
共享基础管理{待办池类型、待办量化标准、作业时间设置、业务高峰期、特殊档案设置、量化派单规则、量化时长管理}
共享作业管理{待办处理、待办调整}
预算管理{预算信息管理、预算信息调整、预算执行台账} 合同管理{合同信息管理、合同执行台账} 消息管理、账表统计
4 项目方案
4.1 建设思路
本项目建设的核心是需要实现报账系统的互联网化，实现企业的saas应用，并需要运
维平台的支持；
建设内容包括：通过如下图后台规划思路使用业务场景化（业务画像）方式，可以了解
本项目需要的功能；
产品在业务建模方面的功能设计要求：
1. 平台要求对每一项报账业务必选根据图中12个维度有详尽的描述，在业务建模时可
以按可视化、导航的方式，对业务进行画像，完成业务的设计和配置。
2. 用户可以选择平台提供的标准化的业务模型，也可以增加新的业务模型，增加一项
新业务模型可以从现有业务模型拷贝修改。
3. 对于配置好的业务模型，可以提供全景图，即指定一个业务模型，可以完整看到图
中的各项内容。
综上，报销系统从需要互联网化的saas应用，并对运维的要求，以及其中搜索、权限模型、参数设置（业务规则）、单据模板、审批流程等与iuap企业互联网开放平台匹配度很吻合；
4.2 应用架构
基于本项目的整体建设思路，报账系统的整体应用架构如下：
应用的管理流程设计
应用的功能设计
4.3 系统架构
在平台系统实现方面，我们需要重点考虑以下几个问题：
(1)由于财务大集中，而各省份之间没有业务关系，系统需要支持多租户 (2)系统需要保证弹性伸缩以及高可用 (3)支持云端的审批流程 (4)支持用户自定义模板
(5)云服务架构在不同的saas，基于ass；提供公共的服务 (6)流程、搜索的支持
(7)分布式服务的高并发高可用 (8)运维管理
以上是广信中移动报账系统的系统架构，下图为IUAP服务端框架和中间件结构，可以看出；业务应用采用的技术栈；
4.4 应用开发框架 4.4.1 前后端分离
4.4.1.1 前提要素
Web开发技术的日益发展和Web系统需求的日益的提高,使得前后台分离的条件日益成熟,而必要性也日益提高.总结概括如下: a.前端无所不能,通道日益便利,需求日益明确. b.HTML/CSS标准的发展使得前端表现日益丰富
在近年Web前端技术的竞赛中,HTML5/CSS3显然还是领跑者,它们的标准不断发展也给前端实现带来了更多可能,介于这两种技术是任何模式的必选,这里就不加累述了. c.JS框架的不断发展使得前端开发无限可能
如今,内有JQuery这种简单易用的基础函数库,外有AngularJS和BackBone这种框架实现. 在JS的肩膀之上,前端开发事实上已经具备无限可能. d.RESTful Api和Json的发展使得前后端交互日益便利
当然,分离以后就存在交流的问题,如何快速,简洁,有效,统一的在前后台进行信息的交互,成为分离以后必须考虑的问题.
幸运的是, RESTful思想和Json数据标准的出现,使得这种交互日益便利,在前端,我们耳熟能详的JS技术和框架对RESTful和Json的支持可以说已经水到渠成. 至于后端,不管什么语言,什么平台都有非常成熟的方案.
e.前后端的不同发展趋势使得前后端分离需求日益明显
Web开发桌面化已经是无法阻挡的潮流,而前端开发的需求应该会向更加注重界面表现,速度流畅,用户体验的方向发展,而且要求只会越来越高.
而在后端,稳定,性能,安全,存储,业务等核心问题依然是主流,所以前后端的需求必将日益分化,注重表现和注重内在的前后端开发人员必将需要适合自己的舞台.
4.4.1.2 分离原则
分离的四大原则：
a.前端静态化：
前端有且仅有静态内容,再明确些,只有HTML/CSS/JS. 其内容来自于完全静态的资源而不需要任何后台技术进行动态化组装.前端内容的运行环境和引擎完全基于浏览器本身. b.后端数据化
后端可以用任何语言,技术和平台实现,但它们必须遵循一个原则:只提供数据,不提供任
何和界面表现有关的内容.换言之,他们提供的数据可以用于任何其他客户端(如本地化程序,移动端程序). c.平台无关话
前端3大技术本身就是平台无关的,而后台连接部分的本质是实现合适的RESTful接口和交互Json数据,就这2者而言,任何技术和平台都可以实现. d.架构分离化
前端架构完全基于HTML/CSS的发展和JS框架的演变,与我们耳熟能详的后台语言(如C#, Java, NodeJs等)完全无关. 由于前台是纯静态内容,大型构架方面可以考虑向CDN方向发展. 后端构架几乎可以基于任何语言和平台的任何解决方案,大型构架方面, RESTful Api可以考虑负载均衡;而数据,业务实现等可以考虑数据库优化和分布式
4.4.1.3 分离特点
页面逻辑和呈现效果: JS已经无所不能,依托于目前的各种JS函数库和框架，在获取到合理的数据以后，几乎没有做不出来的逻辑和效果。对于数据校验，路由控制，代码复用等等问题，前端技术已经完全可以解决。
服务器性能和优化: 由于前端内容是完全的静态内容,在初次获取以后的大部分时间内，浏览器使用的就是本地缓存，也就是说，服务器的压力主要来自于承载数据的RESTFul Api调用，压力的大幅降低不言而喻。加上对交互数据的合理设计,可以说对客户端-服务端的交互量控制已经接近极限。
安全性: 由于前端静态内容仅仅只能获取,而后端只能接受Json,应该说,屏蔽了大量可能发生的注入型问题,而一些其他问题,比如非法对象,数据加密,DDOS等问题,这些本身就是后端人员无法回避的责任,在任何模式下都必须考虑.
跨平台,跨技术: 正如刚刚所所说, 前端技术本身无平台限制,而后端几乎任何平台都能实现. 企业级构架考虑: 前端考虑搭建CDN,后端考虑负载均衡,数据库优化和分布式设计.关键问题是,前后端构架可以分开考虑,各自交给其专业人员去架设.
测试: 前端JS已经出现非常优秀的单元测试框架(AngularJS),而后端RESTFul测试技术早已驾轻就熟.
SEO: 的确是一个问题,但通过OWIN或者其他HTTP Module桥接技术,转接一部分HTTP路由
到SEO功能并非难事.
开发技术: 前端人员只需要学习HTML/CSS/JS,而后端人员只需要学习后端语言.几乎不需要穿插.
Ajax跨域: 如果远程调用或者内部少量调用,可以考虑后端转接和JSONP,内部构架分离可以考虑CORS.
4.4.1.4 动静分离
由下图可以看到一个标准的http处理流程：
a.首先通过Web Server 接受Http请求;
b.比如html、css等静态资源 Web Server 可自行处理;
c.当遇到动态资源(jsp等)时候Web Server 将请求转接至Application Server中，由Application Server处理;
Web Server或者叫HTTP Server主要用于操作Http请求，包括接受客户端的请求以及响应。它可以处理请求，也可以将请求转发至其他服务器。 代表：Nginx、apache、IIS
应用服务器可以选择使用上文所说的 WebLogic和WebSphere这种重量级产品外，也可以使用类似与Tomcat、jetty这样的web containner 再加上第三方的框架(spring,hibernate等)来构建自己的Application Server。
动静分离通过nginx+tomcat实现，其中nginx处理图片、html等静态的文件，tomcat处
理jsp、do等动态文件；实现动静分离主要需要nginx的配置，并不会影响开发者；
4.4.2 SPA单页面应用
单页Web应用（single page web application，SPA），就是只有一张Web页面的应用，是加载单个HTML 页面并在用户与应用程序交互时动态更新该页面的Web应用程序。浏览器一开始会加载必需的HTML、CSS和JavaScript，所有的操作都在这张页面上完成，都由JavaScript来控制。因此，对单页应用来说模块化的开发和设计显得相当重要。
4.4.2.1 单页面应用特点
速度：更好的用户体验，让用户在web app感受native app的速度和流畅， MVC：经典MVC开发模式，前后端各负其责。
ajax：重前端，业务逻辑全部在本地操作，数据都需要通过AJAX同步、提交。 路由：在URL中采用#号来作为当前视图的地址,改变#号后的参数，页面并不会重载。
单页Web应用和前端工程师们息息相关，因为主要的变革发生在浏览器端，用到的技术其实还是HTML+CSS+JavaScript，所有的浏览器都原生支持，当然有的浏览器因为具备一些高级特性，从而使得单页Web应用的用户体验更上一层楼。单页Web应用，顾名思义，就是只有一张Web页面的应用。浏览器一开始会加载必需的HTML、CSS和
JavaScript，之后所有的操作都在这张页面上完成，这一切都由JavaScript来控制。因此，单页Web应用会包含大量的JavaScript代码，复杂度可想而知，模块化开发和设计的重要性不言而喻。
4.4.2.2 前端技术架构
前端开发框架是一套基于Html5页面展现技术和MVVM模式的编程框架，分为UI框架和模型两部分。UI框架具有响应式Web 的能力，支持在不同终端、不同尺寸屏幕、不同浏览器上实现统一交互体验。遵循基本的设计原则，同时支持触摸、语音、鼠标、键盘等输入方式。
前端控件库提供了布局类和基础控件类两类控件，布局类包括网格布局、导航布局等，布局类控件是解决不同端交互统一核心技术，基础类控件类包括按钮、菜单、输入框等常见表单控件，以及消息提示、加载动画等。
前端框架的模型部分是对MVVM模式的视图模型（ViewModel）和模型（Model）的实现，并增加了分页框架和事件框架，方便了开发人员对业务逻辑的处理。数据模型是对模型（Model）的实现，支持二维数据表和对象数据的存储，并对外暴露数据存取接口；数据模型对数据状态进行了描述，使得开发人员可以方便的取出变化数据，针对变化数据编程。数据模型提供分页缓存的能力，使得开发人员可以获取制定页面的数据，减少前后端数据传递的流量。事件框架是针对数据模型的变化，进行的事件监听，使得程序员可针对数据的变化进行业务逻辑的编写。
前端业务框架是一系列针对企业应用的工具集合，用于解决开发复杂的企业应用过程中遇到的各种问题。提供了Grid、多语、多级树、树表、参照等控件，为程序员实现UI展现提供了更多的选择。针对列表、树卡、一主多子、主子孙等复杂数据模型，进行了封
装，减少了程序员的编程复杂度。针对业务系统的公共基础层通过页面框架提供了更多的支持，包括页面模型、上下文模型、皮肤框架、国际化框架、日志框架、安全框架等。
本项目前端使用SPA单页面应用的模式，涉及的相关前端技术如下图所示：
4.4.2.3 IWEB框架定位及优势
框架定位：
IWEB框架是一个包含了UI控件库以及模型框架(基于MVVM)的前端框架。主要解决问题：
a.提供了一系列UI控件，方便开发者使用
b.定义了页面基础样式及颜色等规范，解决页面UE风格一致的问题
c.提供了数据模型，实现数据与UI双向绑定，构建数据驱动型页面。解决具有复杂交互的页面开发问题。
优势：
完善的控件体系：包含所有常见的控件。
兼容IE8以上的主要浏览器：IE 8+、Firefox、Chrome、safari
多端适配：使用响应式的CSS在电脑、手机和平板电脑上看起来都很好看 声明式绑定：使用简明易读的语法很容易地将模型数据关联到DOM元素上
双向数据绑定：模型与UI之间的双向自动更新
多维数据模型：解决了字段关联、主子数据、主子孙等多维数据模型的绑定问题
4.4.2.4 模块化管理工具
iuap平台建议使用requirejs来管理模块化
随着网站功能逐渐丰富，网页中的js也变得越来越复杂和臃肿，原有通过script标签来导入一个个的js文件这种方式已经不能满足现在互联网开发模式，我们需要团队协作、模块复用、单元测试等等一系列复杂的需求。
传统的js代码依赖多个文件，需要依次加载。这样做的弊端是浏览器会停止网页渲染，加载文件越多，网页失去响应的时间就会越长；其次，由于js文件之间存在依赖关系，因此必须严格保证加载顺序，依赖性最大的模块一定要放到最后加载，当依赖关系很复杂的时候，代码的编写和维护都会变得困难。
requirejs实现js文件的异步加载，避免网页失去响应；管理模块之间的依赖性，便于代码的编写和维护。
4.4.2.5 Director前端路由
界面效果
前端界面分为两个部分，一个是左边的菜单栏，另一个是右边的内容区部分。选择不同的菜单来加载左边的内容时，iuap平台推荐采用路由的方式来进行界面的加载。 Director路由框架是最纯粹的路由注册解析器，它在不刷新页面的情况下，利用“#”符号组织不同的URL路径，并根据不同的URL路径来匹配不同的回调方法。
路由注册在URL里的体现是用“#”符号来标识路由的开始，再利用\"/\"分隔符来定义路由片段。客户端路由其实就是通过URL来区分应用程序的不同状态，并且定义在不同的状态下应该做什么事情。当用户访问不同的URL时，director.js 会解析路由信息并告知应用程序需要做什么事情。 路由格式图：
Index.html中菜单栏用到的路由框架
4.4.2.6 AMD模块的写法
AMD规范全称是Asynchronous Module Definition，即异步模块加载机制。从它的规范描述页面看，AMD很短也很简单，但它却完整描述了模块的定义，依赖关系，引用关系以及加载机制。
require.js加载的模块，采用AMD规范。也就是说，模块必须按照AMD的规定来写。 具体来说，就是模块必须采用特定的define()函数来定义。如果一个模块不依赖其他模块，那么可以直接定义在define()函数之中。
用户节点boss_client\\src\\pages\js
4.4.2.7 控件与datatable数据模型
a. 控件使用
从js中找到对应的html路径boss_client\\src\\pages\p":{"h":15.839,"w":159.943,"x":367.635,"y":598.108,"z":47},"ps":null,"s":{"letter-spacing":"-0.052er\html 在非编辑态页面中使用的是table，下图为html代码：
当点击新增或修改时，跳转为编辑态，编辑态界面截图为：
b. datatable数据模型
在此案例节点中定义了4个datatable，分别是非编辑界面的listData，查询时的searchData，编辑界面的输入框cardData和关联角色的列表roleData。
4.4.2.8 页面初始化及与后台服务器交互
a. 初始化html界面及数据模型：
b. Ajax方式与后台交互
使用ajax的方式向后端发送请求，若请求成功到success方法中，通过setSimpleData将值赋给datatable，若请求失败到error中。
4.4.3 后台服务
4.4.3.1 服务器端框架
Iuap平台集成了Spring框架进行组件的配置和管理，以及SpringMVC作为后端MVC框架，更方便业务开发者进行开发使用。
Spring是一个开源的轻量级JAVA开发框架，是为了解决企业应用开发的复杂性而
创建，具有很多优点：
1. 轻量级的容器框架，没有侵入性；
2. IOC更加容易组合对象之间的关系，通过面向接口进行编程，可以低耦合开发； 3. AOP可以更加容易的进行功能扩展，遵循OCP开发原则；
4. Spring默认对象的创建为单例的，我们不需要再使用单例的设计模式来开发单体类； 5. Spring的集成很强大，另外可以对其他框架的配置进行统一管理； 6. Spring的声明式事务的方便使用。
通过开放的Spring可以快速集成市面大多应用框架，很适合作为管理企业复杂应用组件的基础。
SpringMVC是一种基于JAVA实现了MVC设计模式的请求驱动类型的轻量级WEB框架，使用了MVC架构模式的思想，将WEB层进行职责解耦。IUAP平台采用SpringMVC作为后端的MVC框架，帮助开发者简化开发。
SpringMVC有以下优势：
1. 简单快速的设计web层；
2. 提供强大的约定大于配置的契约式编程支持；
3. 支持灵活的URL到页面控制器的映射；
4. 容易与其他视图技术集成，如Velocity、FreeMarker等； 5. 灵活的数据验证、格式化和数据绑定机制； 6. 支持Restful风格；
4.4.3.2 持久化框架
业务应用在快速搭建过程中大多数都需要持久化，需要提供一种简单的持久化集成方式，快速搭建支持基础CRUD的环境，同时兼顾后期的扩展。持久化要简单易用，支持分页查询、保存和更新操作等。为了和其他iuap组件保持对Spring等第三方组件一致的版本依赖，需要平台提供基本的持久化、连接池等集成规范。
包含基于SpringJDBC的iuap-jdbc组件，Spring Data JPA方式，Mybatis方式等。 Spring Data是一个用于简化数据库访问，并支持云服务的开源框架。Spring Data JPA是由Spring Data提供的一个用于简化JPA开发的框架。使用Spring Data JPA可以极大的简化JPA的写法，可以在几乎不用写实现类的情况下，实现对数据的访问和操作。IUAP平台引入Spring Data JPA框架，底层采用Hibernate实现，与Spring集成，配合事务管理器等完成简单业务的查询与持久化操作；
MyBatis源自开源项目iBatis，是一个支持普通SQL查询，存储过程和高级映射的优秀持久层框架。它消除了几乎所有的JDBC代码和参数的手工设置以及对结果集的检索封装。MyBatis可以使用简单的XML或注解用于配置和原始映射，将接口和JAVA的POJO对象映射成数据库中的记录；
IUAP JDBC是基于JDBC的持久层框架，遵循基本的JPA规范，提供对数据的增删改查，分页等功能。提供了基础的sql功能，能够提供对多数据库的语法适配支持，目前支持的数据库包括：MYSQL、Oracle和Postgresql。
由于IUAP JDBC对多数据的语法适配支持，并且提供了对数据的增删改查，分页等功能；满足了项目的需要，简化开发；
4.4.3.3 分布式事务
IUAP平台使用Spring的事务机制来管理事务。Spring的事务是通过“声明式事务”的方
式对事物进行管理，即在配置文件中进行声明，通过AOP将事务切面切入程序，最大的好处是大大减少了代码量，同时便于理解。Spring AOP面向切面编程本质是针对具体的类创建对应的代理类，然后通过代理类来再对具体类进行操作。
在持久化操作时，如果是更新操作或者涉及到多表操作，一般需要进行事务控制来保证数据的完整性和一致性。控制事务的方式有多种，可以采取变成是事务，或者配置型事务。在IUAP持久化层框架的基础上，推荐使用Spring的事务控制，采用注解配置的方式进行事务控制。
Iuap平台提供的持久化方式有多种，如果单独使用Spring JDBC或者Mybatis，可以采用DataSourceTransactionManager进行事务管理；如果和Spring Data JPA混合使用，需要配置为JpaTransactionManager，建议业务开发前期进行选型，避免持久化层的混合使用；
事务的传播机制，使用了默认的设置；对于存在一个事务，则支持当前事务，如果没有事务则开启；
在中移动报账项目中，由于使用了平台的较多组件，而组件的持久化方式也是多样的；虽然业务开发选择的持久化层是Spring Data JPA的方式，但应用组件的持久化层还是有Mybatis等，故这里选择了JpaTransactionManager作为事务管理器；并且采用了统一的注解的方式，加在了service层的增删改操作上；以保证操作的一致性
4.4.3.4 对象OID组件
在数据持久化时，业务上通常需要生成全局唯一的对象标识ID，在应用水平扩展时，多个JVM中生成的唯一标识保证不冲突。传统的UUID能保证唯一性，但在数据量很大之后，数据查询效率会下降，所以需要一种能保证全局唯一并且可以保证读写效率的对象标识生成方案。
Iuap的对象OID组件提供唯一标识生成的统一封装，包括普通的UUID、基于Redis的自增ID、基于Snowflake算法和UAPOID算法的唯一ID。组件提供统一接口对OID进行生成，通过配置的方式实现ID生成策略的切换，同时可以扩展自定义的ID生成方案。
a. 在基于Redis自增时，支持为不同模块设置不同的ID起始值；
b. 基于Snowflake算法通过日期、机器信息、顺序号等共同组成一个唯一ID； 此种方式使用有限制，需要在启动tomcat时候指定系统属性，ID生成时候会使用系统属性，注意:次场景适用在同一台机器或同一个docker容器中启动单个Tomcat或java应用，
否则可能无法保证workerid不唯一。
c. 基于UAPOID算法通过Schema、顺序号（包括0-9和a-z）等生成唯一ID，同时利
用本地缓存和数据库机制实现高效和高可用。
最终生成的为20位的字符串，前8位为用户指定的schema名。依赖数据库，需要初始化表
d. 组件支持以扩展的方式生成自定义的主键
4.4.3.5 缓存组件
为了提高业务应用的性能，避免对数据库资源的频繁访问，应用中常常引入缓存技术，将需访问的资源或初次调用后的结果缓存起来，针对后续的相同访问直接返回缓存结果，以支持应用的高并发。
业务缓存的实现方式可以是将数据放置在JVM的堆内存中，也可以将数据放置在第三
方中间件中，如memcached、redis；其中JVM内存缓存有两个弊端:一是大小受到JVM堆内存的限制，会引起频繁的GC；二是集群部署时候，web应用间存在多份缓存，无法共享。第三方缓存中间件解决了JVM内存的这两个问题，但在操作中间件的缓存时，需要建立统一的连接和维护连接池，同时为了不绑定在某个特定的中间件上，还需要对多种中间件进行适配，这些都需要平台提供标准组件进行处理；
Redis针对数据结构、持久化、过期策略、分布式集群、数据备份和灾难恢复等方面
相对缓存中间件更有优势。IUAP平台采用redis作为缓存中间件，并针对redis提供统一的连接以及基本java api封装，更利于方便业务开发简便快速的实现对业务数据的缓存操作，提高系统的运行效率；
Iuap缓存组件还实现了缓存服务的高可用性，在主从模式下支持主节点宕机后的自动切换，业务服务无感知。 关系型数据库与NOSQL
NoSQL 数捤库，全称为 Not Only SQL，意思就是适用关系型数据库的时候就使用关系型数据库，不适用的时候也没有必要非使用关系型数据库不可，可以考虑使用更加合适的数据存储。主要分为临时性键值存储( memcached、 Redis）、永久性键值存储（ ROMA、 Redis）、面向文档的数据库（ MongoDB、CouchDB）、面向列的数据库（ Cassandra、 HBase），每种 NoSQL 都有其特有的使用场景及优点。
Oracle， mysql 等传统的关系数据库非常成熟并且已大规模商用，为什么还要用 NoSQL 数捤库呢？主要是由于随着互联网发展，数据量越来越大，对性能要求越来越高，传统数据库存在着先天性的缺陷，即单机（单库）性能瓶颈，并且扩展困难。这样既有单机单库瓶颈，却又扩展困难，自然无法满足日益增长的海量数据存储及其性能要求，所以才会出现了各种不同的NoSQL 产品， NoSQL 根本性的优势在于在云计算时代，简单、易于大规模分布式扩展，并且读写性能非常高。
下面分析两者的特点，及优缺点：
4.4.3.6 分布式服务框架
异构系统间或者不同的应用间的对接常采用微服务的方式提供，服务的提供方式可以是RestFul、webservice、dubbox服务等多种，iUAP平台提供常用的几种分布式服务方案，方便业务开发时对系统的组装。 Restful服务
RESTful架构，就是目前最流行的一种互联网软件架构。其目的是为了提高系统的可伸缩性，降低应用之间的耦合度，便于框架分布式处理程序，具有结构清晰、符合标准、易于理解、扩展方便，正得到越来越多网站的采用。
REST（ Representational State Transfer）即 \"表现层状态转化\"。REST服务采用HTTP协议规定的GET、POST、PUT、DELETE等动作处理资源的增删该查操作。RESTful架构具有以下特征：
（1）每一个URI代表一种资源；
（2）客户端和服务器之间，传递这种资源的某种表现层；
（3）客户端通过四个HTTP动词，对服务器端资源进行操作，实现\"表现层状态转化\"。
iUAP平台引入了Spring MVC，利用Spring MVC配合注解的方式，提供REST服务，供前端页面调用以及为其他系统或者端提供服务。 WebService服务
Apache CXF 是一个开源的服务框架，支持多种协议，比如：SOAP、XML/HTTP、RESTful HTTP 或者 CORBA ，并且可以在多种传输协议上运行，比如：HTTP、JMS 或者 JBI。
iUAP平台采用cxf支持对WebService的开发，使可以方便的定义和发布soap 协议的webservice，也可以发布类似RestFul服务方式的webservice。 Dubbox服务
Dubbox是在广泛使用的开源分布式服务框架Dubbo基础上做了扩展；它解决了分布式服务的URL调用配置复杂，相互之间依赖关系难以整理，服务容量难以估算的问题。并结合zookeeper的集群机制以及版本控制机制，提供了动态扩容/缩容和动态升级/降级的功能。
iUAP平台对dubbox服务的使用提供完整方案和示例，使得服务的提供和调用变得简单，开发者进行简单的配置即可快速搭建分布式服务架构。
4.4.3.7 分布式锁
很多业务上都有对同一个资源并发进行读写访问的场景，又要保证单次访问的正确性和多次访问的一致性，这就要求对资源进行加锁。同时在服务部署可以水平伸缩的情况下，无法做到在单JVM中的加锁控制，所以需要有一个分布式的系统来统一进行加解锁处理。
IUAP的分布式锁组件是利用Zookeeper的强一致特性，通过Zookeeper来提供分布式锁的能力，解决了在多JVM中对共享资源加解锁的需求，并通过集群方式保证整个系统的高可用。本组件实现了对共享资源的互斥加解锁，以及在业务结束后通过拦截触发的自动解锁功能等。
IUAP分布式锁组件的特点： 1. 支持对共享资源的互斥加解锁 2. 支持线程内可重复加锁功能 3. 支持批量加解锁功能 4. 支持线程结束自动解锁功能
4.4.4 应用服务组件
4.4.4.1 编码规则组件
在业务系统中，业务对象通常会有一个业务对象编号，业务对象编码作为业务对象具有业务意义的标识，一般由时间，序列号，常量等字段按照一定的规则拼接而成，这个规则我们称为”编码规则“，各个字段我们称之为”编码元素“。考虑如下的业务对象编号：”TT201608220001“，编码规则为：（常量”TT“+yyyyMMdd类型的时间”20160822“+序列号”0001“），并且以yyyyMMdd作为“流水依据元素“，时间变为”20160823”，序列号重新从”0001“开始流水，同一个编码规则，可以有很多个流水依据；所有的流水依据元素合起来叫做本编码规则的”流水依据“；
目前比较少编码规则的开源组件，网上能找到的也只是一些简单的实现类或者设计思路， 要么将规则写死在代码中，缺乏通用性和灵活性，要么缺少全面的考虑，本组件提供了一种通用的编码规则解决方案。本组件的核心是根据编码规则和一些必要信息，生成业务对象编码。组件需要的编码规则可以存储在文件中，甚至是手工构造，或者存储在数据库中。本组件提供了存储在数据库中一种实现，提供了基本的增加、删除、修改编码规则的服务方法，用户可以在此调用此服务，开发出自己的编码规则设计工具，也可以直接设计符合自己要求的编码规则数据库结构和服务，编码规则VO符合组件的模型即可（实现组件的规则接口）。另外，组件提供了数据库行锁和zookeeper分布式锁的支持，以应对大并发的情况下可能出现的编码重复问题。其中的分布式锁前面介绍了IUAP提供了解决方案；
对于IUAP编码规则功能说明：
1. 根据编码规则和一些必要信息，生成业务对象编码；
2. 支持灵活的规则定义，包括业务数据属性、日期、时间、常量、流水等； 3. 支持最大号定义和归零规则定义；
4. 支持扩展机制，支持业务属性获取，支持自定义序列号生成算法、支持系统时间的扩展、
支持自定义随机码算法 5. 支持批量取号、退号等操作； 6. 支持编码补号
7. 支持高并发场景下不重号、丢号；
IUAP编码规则预留了对业务数据属性的支持，项目中，对此进行了设计，使得能够满足业务的不同维度（业务单元）支持不同的编码规则，并抽象出单据类型来满足需求；并提供候选属性和编码对象及编码对象映射使得编码规则能够从开发态转换变成实施态的工作，能够灵活支持业务的需要；
并且编码规则服务相对独立，在业务上和编码规则服务进行拆分，按照DUBBOX分布式
服务框架的方式提供了编码规则服务，满足分布式的应用；
4.4.4.2 调度组件
iUAP作业调度框架是基于Quartz实现的，Quartz是一个完全由java编写的开源作业调度框架。它完全由 Java 写成，并设计用于 J2SE 和 J2EE 应用中。它提供了巨大的灵活性而不牺牲简单性。你能够用它来为执行一个作业而创建简单的或复杂的调度。
Quartz允许开发人员根据时间间隔来调度作业。它实现了作业和触发器的多对多的关系，还能把多个作业与不同的触发器关联。
iUAP平台提供调度任务组件，业务开发人员引入调度任务组件后，经过简单的配置即可快速实现作业的定时调度、作业的持久化、调度任务服务集群。 调度任务设计原则：
（1）iUAP集成的quartz调度器方式可分为本地启动和依赖数据库启动两种方式，本地启动随着业务的web应用启动，只需要在spring的配置文件中加入job结合业务动作即可，基于
数据库的启动方式需要单独部署war包，可以集群部署，保证高可用性。其和业务应用之间通过restful服务的方式调用。
（2）本地启动方式如果集群部署，需要业务上考虑重复调用和日志的问题
Iuap-saas-dispatch-service是任务调度的服务，该组件可通过前台接口调用服务端的添加、删除、暂停、启动定时任务等功能； 1. 2. 3. 4. 5.
功能说明:
提供独立的任务调度服务； 支持定时任务执行 支持重复任务执行
提供任务的新增、删除、暂停接口 支持集群环境下任务执行唯一
4.4.4.3 业务日志组件
系统中需要记录用户的操作信息，所以通常以埋点的方式记录需要的日志信息；但是代码中既要处理业务逻辑又要出力日志逻辑，显然代码会变得复杂，并且维护也麻烦；
IUAP业务日志组件可以解决此问题：业务逻辑和日志逻辑“分离”！ 业务日志组件的目标：
1. 支持业务逻辑和日志逻辑分离 ； 2. 支持日志的记录对业务方法无侵入； 3. 日志记录不影响业务方法的性能； 4. 支持日志模板，灵活配置日志记录内容；
5. 提供灵活的日志保存方法，并支持自定义业务日志的持久化操作；
事实上，要达到真正的无侵入是不可能的，业务日志组件对业务方法的侵入只不过是要在业务方法上加上一个注解。
业务与日志分离的原理是采用Spring AOP的拦截机制进行。
组件对使用@BusilogConfig(\"业务方法别名\")注解的业务方法，通过Spring AOP进行拦截。 当Spring察觉到被注解的业务方法被调用的时候，即可对此方法进行日志记录。
其中，本组件通过Groovy脚本配置日志模版，定义拦截的业务方法的参数。日志注解@BusilogConfig(\"业务方法别名\")用来给需要日志记录的方法链接日志模版，不同的业务方法可以有不同的日志模板。同时对于日志内容的输出也是可配置的，用户可以自定义来实 现对业务日志的持久化操作。
4.4.4.4 附件管理组件
业务场景中经常会涉及到和文件的交互，需要能够对文件资源进行有效的操作和管理。但传统的单机文件系统在互联网应用场景下往往效率不高、稳定性不佳、扩展困难，无法达到高并发、高性能的业务需求，所以需要有一种高效稳定的方式来提供文件资源管理。
iuap的文件组件提供了对文件资源的通用操作，使用分布式文件系统FastDFS高效存储海量文件，通过集群模式水平扩展容量和数据冗余存储，同时支持阿里云OSS对象存储服务， 使用OSS直接上传文件可以节省带宽流量。在对不同的文件系统进行适配时，尽量保持接口参数相同 ，保证用户使用简便。
IUAP文件组件具备以下特点： 1. 支持文件的上传、下载、删除操作； 2. 同时支持FastDFS和阿里云OSS服务； 3. 支持获取文件下载URL；
4. 支持阿里云OSS的文件直传和回调；
5. 支持阿里云OSS不同bucket权限的文件URL获取； 6. 支持对阿里云OSS请求的安全校验；
在IUAP文件组件的基础上，还提供了IUAP附件管理组件，该组件提供了业务系统与文
件服务之间的管理功能，支持单据的上传多个附件的管理功能。
1. 独立的附件服务系统，支持基本的增、删、改、等等，可以和其他组件集成。 2. 支持多种格式的附件上传 3. 支持一次选择多个附件
4. 支持直传回调、支持回调自定义参数的扩展、支持oss和FastDFS、支持缩略图调节； 5. 支持微服务的部署方式；
组件依赖于文件组件，通过文件组件可适配不同的文件服务器，目前支持FastDFS，阿
里的OSS服务。组件主要用于业务系统的附件管理功能，提供具体业务单据于单据下多个附件的分组管理功能。通过附件管理表建立业务单据与具体文件的关系，支持业务单据对文件的管理功能。同时屏蔽了不同文件服务器不同接口调用 。
项目中使用FastDFS分布式文件系统
FastDFS是一款类GoogleFS的开源分布式文件系统，它用纯C语言实现，支持Linux、FreeBSD、AIX等UNIX系统。它只能通过专有API对文件进行存取访问，不支持POSIX接
口方式，不能mount使用。准确地讲，GoogleFS以及FastDFS、mogileFS、HDFS、TFS等类GoogleFS都不是系统级的分布式文件系统，而是应用级的分布式文件存储服务。
FastDFS是为互联网应用量身定做的分布式文件系统，充分考虑了冗余备份、负载均衡、线性扩容等机制，并注重高可用、高性能等指标。和现有的类Google FS分布式文件系统相比，FastDFS的架构和设计理念有其独到之处，主要体现在轻量级、分组方式和对等结构三个方面。
FastDFS是为互联网应用量身定做的一套分布式文件存储系统，非常适合用来存储用户图片、视频、文档等文件。对于互联网应用，和其他分布式文件系统相比，优势非常明显。FastDFS没有对文件做分块存储，因此不太适合分布式计算场景。 FastDFS架构：
FastDFS服务端有三个角色：跟踪服务器（tracker server）、存储服务器（storage server）和客户端（client）。
•
tracker server：跟踪服务器，主要做调度工作，起负载均衡的作用。在内存中记录集群
中所有存储组和存储服务器的状态信息，是客户端和数据服务器交互的枢纽。相比GFS中的master更为精简，不记录文件索引信息，占用的内存量很少。 •
storage server：存储服务器（又称：存储节点或数据服务器），文件和文件属性（meta data）
都保存到存储服务器上。Storage server直接利用OS的文件系统调用管理文件。 •
client：客户端，作为业务请求的发起方，通过专有接口，使用TCP/IP协议与跟踪器服
务器或存储节点进行数据交互。
4.4.5 多租户方案
4.4.5.1 多租户背景及总体
大型分布式企业是指规模庞大，各子系统/部门在地理上分散且各相互间协作密切的企业。在传统的企业信息化进程中，由于地域、业务、职能、经济实力的不同，各子系统往往独立建设信息系统，加上缺乏整体的统筹规划，往往导致系统间接口不一致，系统重复建设等问题频现，企业整体信息化建设效益低。网络以及信息技术的不断发展，特别是近年来SaaS的兴起为大型分布式企业的信息化建设提供了新的思路；
软件及服务（Saas）以多租户模式为核心理念，以单示例支持多个租户的功能需求，具有维护方便、价格适中等特点，分布式企业内部各子系统/部门均可以看作一个租户，多租户软件能够很好的满足其共性软件需求，采用SaaS模式能够显著降低信息化建设成本和运维成本，同时保证数据接口的一致性。
多租户（Multi Tenancy/Tenant）是一种软件架构，其定义是： 在一台服务器上运行单个应用实例，它为多个租户提供服务。
在这种架构上，应用程序被设计成能将自己的数据、配置进行虚拟的分区，以便每个租户都感觉到自己是在一个私有的、可定制化的应用实例上工作。
这背后代表的是资源的伸缩能力。即在同样硬件配置，不同租户在数据分离的情况下，共享同样的应用程序，还随着租户数量的提升，应用程序的水平扩展，并维持着类似的性能指标（一致响应时间等）。这同时意味着资源使用效率的提升，以及节省 IT 资产的投入。
在共享与安全之间取得平衡，是多租户架构最主要的关注点。更多的资源共享有益于灵活性的上升和总体成本的下降，但单个租户的安全性需求要有额外的技术手段来保证。
多租户的设计牵涉到两层：数据、应用 / 平台
数据层的多租户能力是一个很大的主题，主要是指不同的租户如何共享或分离数据，并满足安全性。
多租户技术或称多重租赁技术，是一种软件架构技术，它是在探讨与实现如何于多用户的环境下共用相同的系统或程序组件，并且仍可确保各用户间数据的隔离性。在云计算时代，
多租户技术在共用的数据中心以单一系统架构与服务提供多数客户端相同甚至可定制化的服务，并且仍然可以保障客户的数据隔离。目前各种各样的云计算服务就是这类技术范畴，例如阿里云数据库服务（RDS）、阿里云服务器等等。
数据层的三种多租户架构： 架构 独立数据库 简介 一个租户独享一个数据库，这种方案的用户数据隔离级别最高，安全性最好，但成本也高。 优点 1）为不同的租户提供独立的数据库，有助于简化数据模型的扩展设计，满足不同租户的独特需求； 2）如果出现故障，恢复数据比较简单。 缺点 1）增大了数据库的安装数量，随之带来维护成本和购置成本的增加。 2）这种方案与传统的一个客户、一套数据、一套部署类似，差别只在于软件同一部署在运营商那里。如果面对的是银行、医院等需要非常高数据隔离级别的租户，可以选择这种模式，提高租用的定价。如果定价较低，产品走低价路线，这种方案一般对运营商来说是无法承受的。 共享数据库、独立 Schema 多个或所有租户共享Database，但是每个租户一个Schema。 为安全性要求较高的租户提供了一定程度的逻辑数据隔离，并不是完全隔离；每个数据库可以支持更多的租户数量。 1）如果出现故障，数据恢复比较困难，因为恢复数据库将牵扯到其他租户的数据； 2）如果需要跨租户统计数据，存在一定困难。 共享数据库、共享 Schema、共享数据表 租户共享同一个Database、同一个Schema，但在表中通过TenantID区分租户的数据。这是共享程度最高、隔离界别最低的模式。 三种方案比较，第三种方案的维护和购置成本较低，允许每个数据库支持的租户数量最多。 1）隔离级别最低，安全性最低，需要在设计开发时加大对安全的开发量； 2）数据备份和恢复最困难，需要逐表逐条备份和还原。 如果希望以最少的服务器为最多的租户提供服务，并且租户接受以牺牲隔离级别换取降低成本，这种方案最适合。 最后一种模式则是租户数据在数据表级别实现共享，它提供了最低的成本，但引入了额外的编程复杂性（程序的数据访问需要用 tenantId 来区分不同租户），备份与恢复也更复杂。这三种模式的特点可以用一张图来概括：
三种部署模式的异同
上图所总结的是一般性的结论，而在常规场景下需要综合考虑才能决定那种方式是合适的。例如，在占用成本上，认为独立数据库会高，共享模式较低。但如果考虑到大租户潜在的数据扩展需求，有时也许会有相反的成本耗用结论。
而多租户采用的选择，主要是成本原因，对于多数场景而言，共享度越高，软硬件资源的利用效率更好，成本也更低。但同时也要解决好租户资源共享和隔离带来的安全与性能、扩展性等问题。毕竟，也有客户无法满意于将数据与其他租户放在共享资源中。
4.4.5.2 Iuap动态数据源组件
单租户就是传统的给每个租户独立部署一套web+db。由于租户越来越多，整个web部分的机器和运维成本非常高，因此需要改进到所有租户共享一套web的模式（db部分暂不改变）。
基于此需求，IUAP动态数据源组件对租户的程序做了简单的改造实现web多租户共享。具体改造如下： ➢ web部分修改：
1) 在用户登录时，在线程变量（ThreadLocal）中记录租户的id并写到Cookie中 2) 基于IUAP登陆认证组件，基于shiro实现的filter拦截，设置线程变量
（ThreadLocal）中记录租户的id
➢ 修改jdbc的实现：在获取数据库连接之后，从ThreadLocal中获取租户id，利用租户的
schema动态切换数据库连接中的schema
4.4.5.3 其它方面的考虑
数据备份
独立数据库和独立Sechma的模式，为每个租户备份数据比较容易，因为他们存放在不同的数据表中，只需对整个数据库或整个Schema进行备份。
在共享数据表的模式下，可以将所有租户的数据一起备份，但是若要为某一个租户或按租户分开进行数据备份，就会比较麻烦。通常需要另外写sql脚本根据tenant_id来取得对应的数据然后再备份，但是要按租户来导入的话依然比较麻烦，所以必要时还是需要备份所有并为以后导入方便。
性能
独立数据库：性能高，但价格也高，需要占用资源多，不能共享，性价比低。 共享数据库，独立 Schema：性能中等，但价格合适，部分共享，性价比中等。 共享数据库，共享 Schema，共享数据表：性能中等（可利用 Cache 可以提高性能），但价格便宜，完全共享，性价比高。如果在某些表中有大量的数据，可能会对所有租户产生性能影响。
对于共享数据库的情况下，如果因为太多的最终用户同时访问数据库而导致应用程序性能问题，可以考虑数据表分区等数据库端的优化方案。
经济考虑
为了支持多租户应用，共享模式的应用程序往往比使用独立数据库模式的应用程序相对复杂，因为开发一个共享的架构，导致在应用设计上得花较大的努力，因而初始成本会较高。然而，共享模式的应用在运营成本上往往要低一些，每个租户所花的费用也会比较低。
4.4.6 系统安全
4.4.6.1 安全组件
IUAP提供了Iuap-security组件提供安全访问时候请求的签名、验证、传输，简单数据加密解密等功能，包含对Hmac、RSA等算法的封装，方便业务开发使用；
iuap-security组件引入OWASP组织的开源项目ESAPI，利用ESAPI，平台实现了对跨站脚本攻击（XSS），sql脚本注入等安全问题的预防。ESAPI具有一个安全接口集，其对每一种安全控制有一种参考实现并支持自定义实现。组件在ESAPI的基础上进行扩展。加入了对HTML、CSS、JavaScript、XML、URL等编码与解码，信息的加密解密，信息的摘要签名，防sql注入等功能的API。
iuap-security组件通过可配置的方式提供ESAPI给开发人员使用，方便了业务开发人员使用，iuap-security提供了rest api的签名和验签，在调用端和服务端分别做信息的摘要和验证，确保数据的完整性，防止恶意篡改。
非对称加密算法可以用作传输加密，即数据从请求端发送到服务端时，对敏感数据用公
钥进行加密，在服务端用私钥进行解密，该组件提供了RSAUtils工具类进行RSA加密。
在登陆认证的场景下，利用该算法对用户登录密码进行加密传输，并在服务器端进行校
验；
4.4.6.2 登陆认证
Iuap的登陆认证组件是基于shiro实现；其中Shiro负责所有请求的拦截；
登陆认证的流程如下：
a. 需要先定义好用户以及密码策略等
b. 进行登陆操作，首先加载页面会从服务器端获取公钥
c. 用户进行登陆操作，提交用户名及加密的密码至登陆服务，结合安全策略进行校验，登
陆成功时会将当前用户的token保存至redis内存中；这里使用的是无状态的会话；并将相关的cookie返回给客户端；
d. 当发起请求时，客户端携带cookie访问，Shiro会拦截请求进行身份认证，对于需要拦
截的请求，会使用statelessRleam进行用户校验（向redis中校验当前用户是否有效）； e. 校验成功之后，会设置当前的相关上下文信息，详见InvocationInfoProxy
4.4.6.3 权限模型
Iuap的权限模型RBAC基于shiro实现；其中Shiro负责给权限模型获取资源，及进行权限校验；
对于权限模型的流程如下：
a. 首先通过授权管理、角色管理、权限资源管理建立用户、角色、资源（功能、按钮）进
行定义并进行用户与角色的授权，角色与资源的分配；通过权限管理的API实现持久化； b. 当客户端发起请求操作某个资源（功能、按钮），首先会被Shiro的shiroFilter拦截器，
进而由Shiro的安全管理器中插拔的授权域（由iuap提供ExtShiroDbRealm）进行当前Subject的授权；由于在登陆认证组件部分对当前的Subject进行了验证，所以到权限模型部分，Subject已经明确了当前的用户，故在授权域中可以通过iuap的权限管理的API即可获取当前用户有权限的资源，并设置在Subject中；
c. 以上授权成功之后，ShiroFilter拦截器的目的就已经完成了，会将请求放行至
AuthorizationCheckFilter拦截器中，该拦截器是普通的Servlet拦截器；会将所有的请求进行拦截，这里需要注意的是对于没有身份信息的请求需要直接放行，补充说明，对于
需要身份信息的请求在经过登陆认证组件之后，都会带有身份信息，对于没有身份信息的(登陆认证组件放行的请求，如js文件等)请求，权限模型也不需要校验权限直接放行请求；
d. AuthorizationCheckFilter拦截器中，对于需要校验权限的请求，通过uri在功能注册表中
查找获取当前操作的功能节点，再通过shiro的API Subject.isPermitted()进行权限验证；再通过url的最后操作，判断该功能的按钮是否有权限；
4.4.7 BPM
iUAP BPM（流程平台）是支持工作流和业务流程自动化的高性能平台，是一组适合互联网应用开发的组件、服务和工具集，由流程引擎、流程设计器、流程中心、SDK，以及流程应用扩展组成。该平台基于Activity工作流开发，完全支持了审批流、业务流以及自由流。流程平台支持多种数据库，并为流程后期的开发提供了SDK跟REST服务,并支持在线跟离线流程设计。同时该平台支持多租户，为数据同步提供了解决方案， 可以轻松与项目实现集成。涉及到多租户的场景，IUAP提供了云审的支持；对于非租户可以使用BPM来满足项目需要；
Ubpm(iUAP BPM)提供了流程的各种服务以及对外集成的接口。系统技术架构图如下：
➢ 流程平台提供了SDK跟REST服务，更方便开发。在使用REST服务的时候，后台代码几
乎可以零开发。
➢ 流程平台提供了两种模式的流程设计器。在线设计，目前只支持chrome内核的浏览器，
方便实施与后期维护流程使用。离线设计，eclipse集成的插件，方便开发人员使用。
➢ 支持多种数据库，mysql，sqlserver,oracle ➢ 支持多租户，为数据同步提供了服务。
➢ 提供了流程管理的界面，可以对流程相关数据进行管理。 适用范围
➢ 跨越多个部门，多个系统，组织的 ➢ 业务流程处理 ➢ 流程集成项目 ➢ SOA相关项目等 ➢ 应用集成类项目 流程引擎
➢ 提供流程活动灵活的启动和完成策略
➢ 支持人工路由流转，人工自由流转，自动路由流转
➢ 支持单人、多人顺序、多人并行、多人抢占、自动处理、人工处理模式 ➢ 支持流程分支、合并 ➢ 支持启动远程子流程 ➢ 支持子流程
➢ 支持按照部门、角色、人员多种办理人设置方式 ➢ 办理时限设置
➢ 支持代理、协办、会签、指派 ➢ 支持流程内节点跳转，流程间跳转 ➢ 支持以同步、异步方式调用外部服务 ➢ 提供灵活的任务分配策略
因篇幅问题不能全部显示，请点此查看更多更全内容