请南京大汉网络有限公司总裁金震宇分享研究成果，题目是《网站集约化与移动集约化》，大家欢迎。
有难得的机会和大家来分享一下大汉这几年在集约化建设项目当中的一些体会，我们参与了浙江省包括江苏省、湖南，包括山东等有非常多省级集约化的建设项目，现在集约化也不仅仅是在省一级，在很多的地市以及很多的厅、委办局等部门也都有集约化的需求，集约化的建设不是一蹴而就的，在建设的过程中除了经验积累之外更多的还有很多的得失，我今天的题目是网站的集约化和移动集约化。
网站的集约化有很多误区，我们有很多政府部门在建设网站的时候更多现在的建法是称作为集中化，其实是很多的服务器搬到了一个云平台上，对云平台的应用也仅仅是虚拟化的应用，有很多云端的技术以及分布式的架构都没有被充分的利用，包括弹性计算等等，因此仅仅是完成了一个机房的搬迁。
在整个集约化的建设过程当中，整个的统一体系也缺乏统一的规划，架构、应用、资源、运维，在一开始就没有很好的规划，以至于到建设大部分完成的时候才发现有诸多的问题会存在，当一个集约化的帝国建设完成之后我们会发现，数据的并发有问题了，数据的展现有问题了，数据的存储有问题了等等一系列的问题，很多的风险都存在了。
怎样去做好一个集约化的网站？我们通常的政府由于是立项制，流程类似我画的这个流程，招投标、页面的确认、审核，建设过程当中看似有序但是无须，很多边设计、施工、完善，大不了再推翻重来。
很多公司都很辛苦，项目厂商、配合实施都在熬夜，都在打补丁，在顶层设计出了问题，总结了一下有七大纬度，一个是应用抽象，一个是目录规范，一个是服务框架的梳理，一个是数据归集的方向，一个是数据挖掘如何做，再有就是用户访问路径的优化和多端同源头问题，如果这些问题没有很好的做顶层设计，最后的集约化建设到后来就会非常的困难。
在建设顶层设计的时候最重要的是标准，这里面包括集约化的管理办法、集约化的统一认证身份规范、集约化的接口规范等，集约化建设的时候我们会发现，我们的云架构当中到底是在SAAS层、PAAS层还是在IAAS层在做部署和开发，很多说在做集约化都是在SAAS层做部署开出很多子网站，我称作为仅仅是网站群，到了集约化的阶段，其实是在底层的云架构考虑集约化的问题，PAAS层考虑分布式存储、缓存等问题，包括大数据的并发和大数据同时大规模的发布，能不能撑得住这些网站，这些方面都需要考虑。
集约化的建设并不是全新的建设，我们牵涉到有很多应用的移植，原有很多应用重新的规划，这时候集约化如何做？按照我们通常的做法，应当把所有的应用先进行整体的抽象，比如说信息公开，行政公开、网上互动、检索等等，这些是从省到市到区县，可能整体都是一个业务类型的，交换处理方式都是一致的，网站是对这些应用的横向打通，各个业务系统当中横向进行业务抽取进行展现，因此对原有系统的改造和调整，集约化的建设是不简单的，要进行重新的规划和梳理。
集约化的运维更需要一个大数据的展现，集约化的能力怎么样，整个平台到底输出了什么样的服务，到底在平台上有多少服务器，用了多少的资源以及在这个平台上用户的访问量，办件的数量等等，需要有一个统一的展现，能够告诉领导我们建设的效能和成果，这是我们参与建设河南省的集约化项目。
集约化实施的难点与风险，整个集约化的建设规模非常大，最重要的是主站目录标准化和向子站标准化的推送，子站能够继承主站的所有目录体系，这样可以做到牵一发而动全身，再有就是系统要支持大规模子站的克隆和复制，这样可以提高实施的效果。
系统在架构上要规避大规模的并发风险。在系统上要很好的处理好数据的移植问题，老数据要移植，同时还有增量的数据要产生。[有统有分，兼顾共性和个性，统分的结合在集约化当中非常典型，我们并不是说集约化建设以后所有的网站都完全是一件衣服、一个步调、一个样子，网站既有它的统的地方又有它分的地方，又有它共性的地方，又有个性的地方，如何兼顾共性和个性。还有数据同源多频联动的问题，我们现在经常会看到很多政府建一个公众服务号，又建微博，又单独建了APP，数据和网站都是没有打通的，后台都是独立的，再有就是落频之间数据关系有没有梳理清楚，就造成了数据不同源。我们也知道还有很多手机终端、机型兼容性，浏览器的兼容性这些问题都要去考虑。还有一个更复杂的问题，这是很多厂商一开始没有讨论到的，包括大汉，我们建设浙江省政府集约化两年以后碰到一个问题，原有网站不能停机要对现有网站进行改版，如果是单一网站没有问题，但是现在几千个网站要改版这个怎么实现？改版过程当中又不能影响原有网站的正常工作。配合改版就要把内容管理和后台发布从原来的秒级提升到毫秒级，实现大规模的信息发布，使得发布没有瓶颈，充分利用云计算的资源做这个事情。集约化建设过程当中模板资源库的整体支撑也是非常重要的，因为我们在建设过程当中免不了很多子站会有很多的模板复用，怎样使得网站能够有更丰富的模板资源库，需要建设一些模板资源库的平台。要考虑到网站的异地、安全、移动令牌、IP控制等。对于集约化网站的备份如何来做？集约化了之后网站的规模以及数据量已经不是原有的网站群可比的，它的备份以及灾难的恢复怎么做到在瞬间能够完成？这个也是需要在集约化当中考虑的问题，也是风险点。
移动的集约化，很多厂商在研究集约化，包括很多在座领导谈集约化的时候我们更多谈的是网站的集约化，移动的集约化如何考虑？移动是网站另外的一个延伸，在移动的应用开发时我们会碰到很多非常纠结的问题，比如说移动开发APP好还是开发微信公众号好？开发的难度有问题，开发的成本也比较高，因为开发一个APP要比网站复杂得多，牵涉到不同的语言，iOS是一个语言，安卓又是另外一个语言，测试的复杂度也非常高，我们有各种各样的安卓手机，据不完全统计国内各种类型手机5000多种，怎么样适配各种手机的兼容性，并且在这些手机上能够使得我们移动应用能够完美的展现。总之有很多问题，包括APP开发了以后没有下载量，品牌的树立和推广也没有很好的去做。
移动应用在集约化当中我们经常会碰到一些非常基本的问题，比如说PC网站做集约化移动应用怎么办？是独立做后台好还是跟网站统一后台好？规范和网站的集约化是否一致，他们之间有什么样的关系？APP统一开发好还是遵照统一的开发标准去做？现在政府既然有了APP，我们还有微信支付宝的城市服务，以及微信现在又有了小程序，以及未来还有其他的，怎么打通，我们现在通常做法就是为每一个平台开发一套，有很多的厂商做法是这样，有没有一个办法，我只开发一次就直接在微信上也能跑，在支付宝的城市服务例也能用，能够在PC端、APP端也能用，有没有这样的解决方案？也就是说开发者不需要考虑跟微信的接口和支付宝的接口问题。
下面谈一谈移动政务应用集约化之道，大汉在很多项目当中，包括大家能够下载到的浙江省政府服务的APP，就是采用了一种叫做政务应用生态体系，它的整体的建设是采用了开放平台，通过组件封装进行扩展，把很多可以封装的应用封装起来，在此基础上开发拓展，统一标准，即刻升级，多端对接。我们做了移动集约化，我们有大量的委办局应用都是不同的，如果都在迭代的开发，都在更新，我们这个APP将没有办法，每天都得更新新版本，用户的体验非常的差，有没有很好的办法能够瞬间更新，有没有极简开发，完成极致体验方式，这个当然是有，通过移动集约化的开放平台，在浙江的做法是把很多能够封装的，包括统一用户支付，很多的社保、固化的应用，能够固化的都固化起来，包括地理位置定位等等，封装底层，通过H5的轻应用进行扩展，对用户的接口、体验以及多端开发性进行统一的规划，形成一个开放平台，微信的公众号就是这样做的，都是在用微信，但是开发都是基于微信开发，这样可以使得我们品牌统一，开发会变得简单。在开放平台上可以支持对微信的JS-SDK接口和支付宝的JS-SDK接口，通过封装能够很好的对接支持，开发一遍所有平台都能够应用。
在移动集约化的开发也会碰到问题，比如说移动APP在做的过程中和移动应用在手机端做的过程当中我们经常碰到的是关于服务入口的设计问题，移动应用和PC应用不一样，移动应用更重要的是入口，因为屏幕很小，入口设计就变得非常重要，而且在移动端入口是非常丰富的，像二维码的入口、搜索入口、分类导航入口、个性化入口、信息推送入口、地理位置入口，信息推送入口就是我们收到一个信息通过这个信息再带回到应用。再有就是移动设计当中还有Wall概念，我们经常看到有用户设置我的中心，有搜索的墙，有城市服务的墙，移动应用和PC不一样是往下拖是没有关系的，这个是移动应用的特色。还有就是移动应用在交互设计上有很多需要考虑的，包括提供了丰富的语音交互、消息导流的交互、多频的交互、STEP BY STEP交互。在开发的时候我们有很多移动应用，我们把办事指南、下载附件都放在一个页面上做链接，这样做移动应用是没有人用的，真正的移动应用应该是STEP BY STEP进行交互，引导用户办事。再有移动的特点是可以地理位置进行交互，这些都是在移动应用上可以考虑的。
以我为中心的设计思维，包括消息服务、热点服务、个性服务、场景化的服务。作为移动应用用户的黏度和下载量也非常重要，我们也要考虑到这一点，怎么能够处理好用户成本和用户黏度的问题。再有就是移动应用的应用场景设计，我们经常忽略这个问题，我们往往带着PC端的设计的思路去考虑移动应用，这时候在PC端是通过链接不断的调整，在移动应用端其实很多的体验是不好的，页面跳转太多用户容易流失，我们移动应用应该考虑特定的场景完成特定的事情。因为时间的关系，只能大概跟各位谈这么多。谢谢大家。