中移动报账系统建设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、ORACLE2、基于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请求，包括接受客户端的请求以及响应。