大型企业IT基础架构与技术服务能力云平台建设方案

项目总体概述建设背景为有效落实集团公司全面深化改革的指导意见，按照《全面推进深化改革的通知》的要求，推进IT深化改革，既要立足当前，提升运营效率，服务好企业的改革发展，又要抓住机遇，从IT架构、IT研发与运营、IT人才激励等方面系统地推进改革，解决IT体系中存在的突出矛盾和根本问题，支撑企业的转型发展，集团公司在深入研究的基础上，制定了企业IT深化改革实施方案。企业IT深化改革实施方案提出，在服务好企业全面深化改革的同时，要抓住改革的机遇，系统化地推进IT自身的改革，并将两者有机的融为一体，相得益彰。具体目标是：以互联网思维变革企业的IT体系，构建以客户为中心的全网集中、开放的云化IT架构，建立核心架构自主掌控的开放式IT研发体系和全网一体化管理的集约化IT运营体系，通过市场化机制组建充满活力的IT研发和运营队伍，推动企业全面深化改革，使IT成为企业核心竞争力。企业IT深化改革的目标是构建集中、开放、云化的互联网化IT架构，实现这一目标的关键是聚焦两大关键任务协同快速推进。一是通过自主研发，建成稳定高效、开源开放、可持续演进的IT云服务能力平台（以下简称“IT云平台”）；二是基于IT云平台的技术架构和集成能力，合作伙伴以低技术门槛快速开发构建CRM、计费等IT核心生产应用。平台与应用之间不断磨合、迭代优化，最终形成平台自主掌控、应用百花齐放的良性平台生态。为此，企业信息化事业部遵照集团公司领导指示，启动了IT云平台一期工程建设。根据IT云平台自主研发的要求，同时考虑到IT研发中心编制及人员逐步到位，平台一期工程由IT研发中心牵头，多家主业公司参与，完成了10个关键组件的研发，功能、性能指标均达预期。经过专家进行评审，一致认为IT云平台（一期工程）已基本具备承载应用的能力，有必要在现网生产系统开展应用试点，通过试点加快平台成熟稳定，同时启动IT云平台二期研发工作，进一步提升平台能力。平台现状业务功能现状一期工程在内蒙古云基地新建了一套IT云服务能力平台，搭建新一代IT系统的PaaS层，主要建设平台基础能力组件，包括数据中间件组件、消息中间件组件、负载均衡组件、工作流引擎组件、分布式协调管理服务组件、事件驱动框架组件、安全中心组件、监控与日志中心组件；同时在新建的IT云服务能力平台上开发交易密集型应用原型和计算密集型应用原型，开展部分智慧运营平台应用场景的功能和性能验证，通过原型验证评估IT云服务能力平台近期承载集约智慧运营平台核心应用的技术可行性和能力成熟度。系统架构如下图所示：企业IT云服务能力平台为新一代集中、开放、云化IT架构的PaaS层。其采用开放架构，高性能、可扩展，数据一点生成、全局共享，基于同一的底层平台架构承载核心业务系统应用。具有平台与应用解耦、硬件与软件解耦、基础设施云化，平台持续演进、核心架构自主掌控、应用快速构建等特点。平台提供统一数据服务、计算框架、共享业务组件组件等面向开发者的通用能力，提供平台运维配套设施。应用基于平台提供的框架，调用、组装云平台能力并进行业务开发，提供面向最终使用者的能力；应用受平台框架和规范约束。IT云服务能力平台近期优先实现智慧运营平台域集约化核心应用的承载。本期先行加载智慧运营平台域部分交易密集型和计算密集型应用验证平台功能与性能需求。组网现状IT云服务能力平台现部署在内蒙古信息园数据中心A5机楼，系统硬件设备由IT资源池内蒙古节点提供，整个IT资源池内蒙古节点组网架构如下图所示：其中IT云服务能力平台部署于区域2，组网部署示意图如下所示，汇聚网络内部采用二层网络互联，服务器采用万兆网络连接接入交换机，满足高性能高吞吐量需求。设备现状IT云服务能力平台现部署在内蒙古信息园数据中心A5机楼,设备配置情况如下表所示：表2-1互联网不良信息内容检测管理系统设备现状类别序号设备类型用途数量单位配置要求硬件1物理PC服务器数据层管理服务器6台4路8核，256GB内存，10*600GSAS硬盘（转速10K）2物理PC服务器DSQL服务器（6台）、SYNC服务器（6台）、计算框架服务器（5台）、分布文件系统管理服务器（2台），原型应用服务器（计算密集型23台、交易密集型19台）、运维管理服务器（1台）62台4路8核，512GB内存，10*600GSAS硬盘（转速10K）3物理PC服务器原型验证数据库服务器（计算密集型14台，交易密集型20台）34台4路8核，512GB内存，10*600GSAS硬盘（转速10K），PCI-E卡3.2TB，4物理PC服务器HBASE（6台）、分布式文件系统服务器（34台）40台2路8核，128G内存，12*3TSATA硬盘转速72005虚拟机研发管理服务器5台2路8核，64G内存，1T硬盘6虚拟机研发管理数据库服务器机1台4路8核，64G内存，1T硬盘流程现状当前CRM已包含各种业务登记单、营销规则、终端核销单、积分兑换单等纸质文件全部电子化；业务稽核电子化：实现对业务稽核的电子化操作；文件存储电子化：实现单据存档的自动化、电子化，仓储管理系统化；移动设备的无纸化影像采集和电子签名；电子业务受理单管理、电子稽核管理、电子模版管理、电子签章管理、组织构架管理等管理功能；在营业厅和移动设备上实现了电子业务受理单生成、电子签章、客户签名采集、客户证件采集、营销规则匹配等业务功能。2017年2月对无纸化系统进行了相关的扩容和优化工作，“中小渠道”受理订单接入无纸化、政企CRM营业无纸化受理优化、代理商门户翼受理无纸化优化、实名制拍照功能优化、移动端能力提升、无纸化平台渠道维度信息优化、集团产品本地无纸化平台归档、电渠无纸化归档优化、CRM的合同与受理资产挂钩等。2018年6月在现有的营业厅无纸化平台功能和能力上进行进一步优化扩容，实现无纸化平台优化、电渠无纸化优化、无纸化营销规则调整优化、移动端能力提升、营业厅前端程序升级改造、云桌面无纸化改造、新增实名影像人脸系统自动比对功能、实名拍照场景优化、结对甩单优化、实名拍照功能优化、版本升级、无纸化平台业务档案存档功能优化、开放渠道人证合一影像数据提取等功能优化。建设目标及需求用户体验组件根据智慧运营平台应用界面设计的现状分析以及未来集团基于云平台的全国集中智慧运营平台应用的原型研发的要求，智慧运营平台应用原型的UE/UI设计需要完成覆盖智慧运营平台全业务的场景设计，主要包括订单类场景、客户类场景、计费账务类场景、客户管理类场景、批量受理类场景、员工类场景等的设计需求。当前智慧运营平台设计中，产品在提高用户与产品交互过程的体验的同时，保证要产品能够成功的定向对用户传达其价值，通过从增强产品的可用性，简化操作，增加使用愉悦感，三方面改善客户与产品间的交互体验，从而提高用户满意度和使用体验。统一数据访问引擎（数据中间件）优化当前智慧运营平台系统将支持T级业务数据存储，传统单库已经无法满足当前飞快的数据存储和响应要求，使用分布式数据库系统势在必行，但是当前企业内的分布式系统在配置和生产使用过程中依然存在一些不足需要完善。提供一个数据库分库分表中间层，采用数据库代理方式，形成分布式数据库中间件解决方案，解决分布式系统数据库分库分表带来的数据透明访问难题。消息中间件优化一般，我们认为消息中间件是指支持与保障分布式应用程序之间同步/异步收发消息的中间件。消息是分布式应用之间进行数据交换的基本信息单位，分布式应用程序之间的通信接口由消息中间件提供。其中，异步方式指消息发送方在发送消息时不必知道接收方的状态，更无需等待接收方的回复，而接收方在收到消息时也不必知道发送方的目前状态，更无需进行同步的消息处理，它们之间的连接完全是松耦合的，通信是非阻塞的，这种异步通信方式是由消息中间件中的消息队列及其服务机制保障的。消息中间件是在消息的传输过程中保存信息的容器。消息中间件在将消息从源头到达它的目标时充当中间人的作用。队列的主要目的是提供路由并保证消息的传递；如果发送消息时接收者不可用，消息队列会保留消息，直到可以成功地传递它为止，当然，消息队列保存消息也是有期限的。本期工程主要对API、Broker消息节点实现、命令行与运维平台进行优化与完善。在对API、Broker消息节点实现方面，需要进行消息去重处理，在一期项目中已经实现了消息获取，但是存在大量的重复消息，但是在分布式架构下，单纯依赖消息中间件难以实现完全去重，建议采用消息中间件增加消费去重处理+应用幂等性+运维手段结合的方式来达到消息完全不重复的目的。提供相应的告警机制处理消息签收超时，同时对客户端返回中间状态提供相应机制确保消息结果的正确性；当增加新的消息队列时，能够增加新的对应的消费端；提供无序模式下消息跳跃性签收处理功能等。完善运维平台，为提高对消息中间件的使用体验，增加消息数量、消费深度等信息查询、节点、生产者、消费者在线监控，实现对消息积压及吞吐量的监控，增加关键操作日志方便查看用户操作，增加消息回溯及综合查询功能。另外支持消息中间件接入易监控平台。交易密集型应用原型优化本期工程在内蒙古云基地现有IT云服务平台基础上，验证平台基础能力组件，包括数据中间件组件、消息中间件组件、负载均衡组件、工作流引擎组件、分布式协调管理服务组件、事件驱动框架组件、安全中心组件、监控与日志中心组件；同时在原有基于IT云服务能力平台上开发的交易密集型应用原型和计算密集型应用原型，开展部分智慧运营平台应用场景的优化和验证，通过原型验证进一步评估IT云服务能力平台近期承载集约智慧运营平台核心应用的技术可行性和能力成熟度。本期工程主要建设内容包括：1)IT云服务能力平台基础能力验证。IT云平台为新一代集中、开放、云化IT架构的PaaS层，采用开放架构，高性能、可扩展，数据一点生成、全局共享，基于同一的底层平台架构承载核心业务系统应用。本期建设内容包括数据中间件组件、消息中间件组件、负载均衡组件、工作流引擎组件、分布式协调管理服务组件、事件驱动框架组件、安全中心组件、监控与日志中心组件。2)智慧运营平台部分应用组件原型的优化与场景验证，用于进一步验证IT云平台的基础能力。本期建设内容为选取部分智慧运营平台应用的典型场景，开展部分场景功能优化和验证，包括分布式交易密集型和计算密集型的部分应用在云平台架构环境下的功能健壮性和性能稳定性。原型验证涉及关键技术包括分布式文件系统、分布式数据库、分布式缓存、数据中间件、消息中间件、负载均衡、工作流引擎、分布式协调管理服务、事件驱动框架、运维框架等。通过原型验证评估IT云服务能力平台近期承载集约智慧运营平台核心应用的技术可行性和能力成熟度，为智慧运营平台集约推进策略决策提供技术参考。监控中心优化本期工程主要新增部分功能，进一步完善监控中心能力。新增分布式服务追踪能力：收集分布式系统调用栈，并对调用链数据进行分析处理，处理的调用信息统一存贮；随着业务发展，系统拆分导致系统调用链路愈发复杂一个前端请求可能最终需要调用很多次后端服务才能完成，当整个请求变慢或不可用时，我们是无法得知该请求是由某个或某些后端服务引起的，这时就需要解决如何快读定位服务故障点，以对症下药。于是就有了分布式系统调用跟踪的诞生。新增基础数据管理能力，统一存贮应用信息及主机信息；统一存贮应用信息及主机信息,根据系统大小不同，每一部分的结构又有一定变化。譬如，对于大规模分布式系统，数据存储可分为实时数据和全量数据两部分，实时数据用于故障排查（TroubleShooting），全量数据用于系统优化；数据收集除了支持平台无关和开发语言无关系统的数据收集，还包括异步数据收集（需要跟踪队列中的消息，保证调用的连贯性），以及确保更小的侵入性；数据展示又涉及到数据挖掘和分析。虽然每一部分都可能变得很复杂，但基本原理都类似。新增WEB界面，提供标准化方式展示监控数据；Zipkin的基础架构UI组件，基于API组件实现的上层应用。通过UI组件用户可以方便而有直观地查询和分析跟踪信息。新增数据开放能力，为应用开发个性化监控界面提供监控数据获取。在SpringCloudSleuth中对Zipkin的整合进行了自动化配置的封装，所以我们可以很轻松的引入和使用它。分布式WEB项目建设随着Internet/Intranet的普及和飞速发展,充分利用网络资源、缩小时空地域限制,在互联网上进行并行分布式处理,将成为今后计算机应用发展的一个重要方向，并且随着业务越拆越小，应用系统整体复杂程度呈指数级上升，由于所有应用要和所有数据库系统连接，最终导致数据库连接资源不足，拒绝服务。所以公共的应用模块被提取出来，部署在分布式服务器上供应用服务器调用。使用基于Web的分布式应用系统，用户只要有标准的Browser(浏览器)软件，即可访问和使用计算机应用系统，而且用户的计算机系统可以不受硬件平台的限制。而这些服务之间的调用就要考虑网络，负载，缓存，配置等问题。本期工程主要对分布式WEB项目涉及的DNS、负载均衡、网页缓存、文件中心、Session管理、配置管理及监控等功能进行建设。分布式数据库企业在支撑系统建设中一直以来采用Oracle数据库，并利用小型机和高端存储设备提供高性能的数据处理和存储服务。随着业务的不断发展，数据量和业务量呈爆发性增长，传统的集中式Oracle数据库架构在扩展性方面遭遇瓶颈。传统的商业数据库软件(Oracle、DB2)，多以集中式架构为主，其最大特点就是将所有的数据都集中在一个数据库中，依靠大型高端设备来提供高处理能力和扩展性。集中式数据库的扩展性主要采用向上扩展(Scaleup)的方式，通过增加CPU、内存、磁盘等方式提高处理能力。这种集中式数据库的架构，使得数据库成为了整个系统的瓶颈，已经越来越不适应海量数据对计算能力的巨大需求。为解决此问题，本期工程总结业界基于Mysql的高可用数据库集群方案基础上提出了TeleDB数据高可用方案。分布式数据库系统通常使用较小的计算机系统，每台计算机可单独放在一个地方，每台计算机中都可能有DBMS的一份完整拷贝副本，或者部分拷贝副本，并具有自己局部的数据库，位于不同地点的许多计算机通过网络互相连接，共同组成一个完整的、全局的逻辑上集中、物理上分布的大型数据库。服务框架企业集团正在推进IT架构互联网化改革并推进智慧运营平台系统集中工程，智慧运营平台集中架构采用全分布式架构，新架构各业务系统及平台组件大量采用REST协议开发系统间接口。本组件“服务框架”实现大量分布式服务的统一治理，为应用提供标准的运行容器，设计统一的接口协议，并为应用服务提供统一入口、服务路由、访问控制、负载均衡、高可用、安全认证、服务监控及审计日志等基础能力服务，并为服务提供统一服务目录。DFS企业全国话单文件数据量非常大，计费系统在实时处理话单的时候文件很碎，会产生巨大数量的小文件。巨大数量的小文件会给HDFS带来巨大的冲击，HDFS存贮不适合存放小文件，应专门为小话单文件设计存贮方案。本方案采用将多个逻辑小文件合并成一个物理大文件方式实现小文件在HDFS上存贮，该方案可以使用在任何需要用HDFS存贮小文件场景。开发DFS文件系统，核心功能包括元数据管理及数据存贮管理，并提供与HDFS一致的开发API，支持C++/JAVA语言对文件进行读写操作；支持Mapreduce并行处理框架；支持REST方式调用。为配套平台监控，需要将指标推送到监控中心。提供文件系统相关配套，包括文件操作命令集及文件系统健康检查。结构化数据服务随着企业流量经营的逐步深入，无论企业内部还是外部用户对流量使用的服务需求日趋强烈。在处理用户流量相关投诉时，基于现有的客服系统手段难以解释用户何时、何地访问哪些网址或应用导致高流量；面对计费争议，企业也无法提供流量产生的依据，只能协商退还费用。所以，建设并完善移动用户上网记录查询功能（包括上网流量详单及更详细的流量轨迹记录查询），通过对用户上网内容的解析实现洞察用户、分析用户上网行为，以支撑流量经营、流量服务。流量轨迹记录数据量十分巨大，据统计全国每天数据量约20T，如果提供6月在线数据查询，总数据量达4PB，基于现有技术方案，无法提供如此巨大数据在线实时查询。本期组件“结构化数据服务”，基于多个开源技术组件设计数据结构及存贮方案，满足超大量数据存贮，并提供实时查询接口，为“流量轨迹数据实时查询”提供解决方案，同时支持SQL及MapReduce并行处理框架。密集型计算框架为贯彻企业深化改革的要求，落实IT深化改革的具体举措，构建集中、开放的云化IT架构，按照集团公司领导对签报《关于以互联网思维实现核心业务系统（智慧运营平台）集中的建议》（2014【351】号）的指示精神，企业信息化事业部计划采用平台加应用的方式构建全网统一的IT云服务能力平台以及基于云平台的全国集中智慧运营平台应用的原型研发。在2015年IT云服务平台关键技术专题能力建设中，提出了建设密集计算框架，用于解决集约计费面临的海量数据计算的问题。基于IT云服务能力平台的集中计费系统技术架构示意如下图所示，主要实现采集分发节点、计费节点部分基本功能原型，验证平台的分布性能、故障恢复、平滑扩展等问题。分布式事务系统使用分布式数据库（TeleUDAL+TeleDB）后，一个事务如果涉及到多个物理数据库节点操作，可能会出现部分物理节点处理成功、部分失败的中间状态，按照传统的数据库操作方式无法保障数据的一致性及可用性，这就是我们在分布式数据库中需要解决的分布式事务问题。在分布式数据库中，事务边界越大(或者单个SQL所执行的数据分片数)，那么系统的锁冲突概率越高，系统越难以扩展，性能越低。因此，若想将系统做到很好的扩展性，那么一个最重要的原则就是想办法划小事务边界，并尽可能让事务的边界限制在单台机器内。缩小事务边界的方式，主要有以下三类：第一种方式：事务边界本来就很小比如，按照某个切分条件，数据分布均匀，并且事务边界只在单机内，那么这个事务就是单库事务，目前TeleUDAL已支持单库事务。第二种方式：使用基于消息的最终一致模型，将强一致事务变为最终一致事务将一个大的事务拆解成多个单库事务，分别处理，使用异步消息+幂等性来保障数据的最终一致性，此方式由应用自行处理。第三种方式：谨慎的使用分布式事务使用最终一致性事务，一般只能解决90%的业务场景，剩下的一些场景，可能还是需要使用分布式事务方式完成。但分布式事务必然带来非常多的性能问题，因此，我们只建议在不得不使用分布式事务的时候，才使用。对于第三种方式，我们需要结合TeleUDAL及TeleDB现有功能研发分布式事务组件，为应用系统提供分布式事务解决方案。分布式任务调度系统任务定时调度是指基于给定时间点、给定时间间隔或者给定执行次数自动执行任务。目前业界存在的几种任务定时调度，主要采用Timer，SpringTask,ScheduleExecutorService，Quartz等技术实现。作为分布式集群环境的定时任务调度系统，目前开源方案主要有easySchedule、elastic-job、ligth-task-scheduler、uncode-schedule，但都存在一定的不足。easySchedule自2012年之后已不再维护，同时只支持HTTP任务。elastic-job是一个无调度中心的分布式弹性作业框架，作业运行的状态数据保存在Zookeeper节点，在作业量较大的情况，严重影响调度的实时性和准确性；同时运维平台操作不方便，功能较简单，缺乏监控、统计、告警的能力。ligth-task-scheduler的实现参考了dubbo架构，采用众多技术，存在过度设计的情况；同时架构上分成了4种不同类型的节点，提高了部署和运维的难度；缺乏统一的任务配置功能。uncode-schedule是基于zookeeper+springtask/quartz的分布式任务调度组件，确保所有任务在集群中不重复，不遗漏的执行。支持动态添加和删除任务。但存在任务的开发必须依赖于springtask的限制。在线交易应用框架在线交易应用框架包括开发者门户、应用引擎以及在线交易定制引擎三方面内容。其中：开发者门户功能主要是实现对应用的开发、构建、部署的跟踪管理；应用引擎功能主要是对现有云平台的公共组件进行封装，提供给应用调用使用；在线交易定制引擎是根据应用公共特点，在应用引擎基础之上，针对各类应用公共特征而定制的一套组件库和服务库，以快速支撑各类应用功能。跨IDC数据同步功能跨IDC数据复制的目的通过加速数据复制控制数据冲突时间范围来减少IDC间的不一致数据。跨IDC数据同步是一种集数据迁移、数据实时同步于一体的数据传输服务。解决远距离、毫秒级异步数据传输难题。跨IDC数据同步组件主要包括以下应用场景：异构数据迁移，增量数据同步，灾备系统。数据能力开放企业集团正在推进IT架构互联网化及智慧运营平台系统集中工程，智慧运营平台系统集中后，各类业务数据如客户资料、用户详单等数据随着系统集中而集中。数据随着集中后，省级系统及合作伙伴等存在数据使用需求，要求集中后系统具备向数据需求方提供数据能力。另外，智慧运营平台域内部系统之间也存在数据共享需求。由于数据分散在集中后的各子系统，数据形态各异，大小不一，数据开放需要考虑数据开放协议、数据安全、认证及数据转换等问题。如果由各子系统独立开放接口，会造成域内系统间、省级系统和合作伴系统依赖混乱，不利于统一协议及管理数据安全。数据能力开放平台就是为了解决集团集中智慧运营平台域内子系统间数据共享、向省级系统及合作伙伴实现数据开放。分布式缓存随着业务发展，需要缓存的数据越来越大，例如计费系统缓存的客户资料数据已达到T以上，这些数据目前集中部署在小型机的共享内存上，数据规模已经达到单台主机的内存瓶颈,后续扩容成本高昂。且在大规模并发访问情况下，系统速度慢和数据利用率低的问题大大制约了整体系统性能;目前迫切需要引入分布式缓存技术，解决以下关键性问题：1.将已有部署在小型机的巨大的共享内存，分别部署到多台pcserve上；形成分布式缓存，节约成本，又便于应用分布化；2.业务不断增长的数据实时扩展需求,系统弹性伸缩性瓶颈;3.大规模并发的数据I/O性能瓶颈，减轻数据库的负载压力，提高事务吞吐率、降低系统延时。项目技术方案总体建设技术方案总体概述系统各项技术应遵循企业相关标准和技术体制；我方应向甲方提供完整、最新而成熟的系统软硬件等技术和产品，并需经过企业的测试验证。其各项技术应保证具有开放性、可移植性、兼容性和可扩展性。系统配置的软件和硬件设备提供开放的应用接口，可以方便地与其他厂家同类型应用系统进行软、硬件平台互连，便于系统未来的扩展；我方应提供快速、有效、功能全面的网络管理系统，包括软硬件管理服务模块和专用工具，具有设备配置、统计分析、告警等管理功能；并具备向上连接到集团网管的能力；本项目涉及的软硬件设备提供商可能不只一家，因此在遵循本技术规范的基础上，要求我方应与各设备提供商在系统集成方面提供充分的合作和技术支持；在工程实施中，不同的承建系统集成商由甲方统一协调，各设备提供商须积极配合，涉及到的互连接口，必须提供具体技术细节资料；我方提供的应用软件保修期两年，保修期自买卖双方签订终验证书之日起开始计算。系统设计企业IT基础架构云服务能力扩容建设项目在总体设计上应满足以下要求：规范和标准符合性：系统应符合其他IT相关规范标准、符合企业IT云服务能力平台规范及各项工程项目标准。技术先进成熟性：采用成熟、合理、先进的技术，在选用系统组件（中间件等）时要在保证其成熟性和可靠性的同时保证系统建设的适度先进性。安全性和可靠性：系统针对主机、数据库、网络、应用等各层次要制定相应的安全策略和可靠性策略，保障系统的安全性和可靠性，应用软件应具有处理各种非正常状态和事件的能力。开放性：系统应采用多层开放式体系结构，具有清晰的体系结构。提供灵活的二次开发手段，在面向对象的业务组件应用框架上，能够在不影响系统情况下快速开发新业务，同时提供方便地对业务进行修改和动态加载的支持。系统集成灵活性：系统采用基于工业标准，如LDAP、WEBSERVICE、J2EE、XML、HTTP、SSL、JSON等技术，与集团相关业务平台或系统对接并集成。松耦合和可扩展性：系统应具有良好的伸缩性，可以随业务规模的增长平滑扩展；要能够支持多个层面的可扩展性，通过负载平衡、快速开发/重组、业务参数配置等多个方面使得系统可以支持企业未来不断变化的业务需求。系统体系结构设计遵循松耦合、模块化的原则，采用软件总线、组件设计方式以保证应用系统的灵活性，适应个性化的需求；我方保证对外接口的开放性，支持与不同厂商设备间的互连（包括支撑系统、业务平台等）；我方应满足系统在大业务量下的实时、并发处理的性能要求；我方应提供设备的在线扩容，包括在线扩展CPU、内存，及扩展集群点；我方所提供系统采用集中式结构（分布采集、集中处理、集中存储），同时提供一定的分级分权管理机制；我方在建议书应对系统所采用的体系结构、采用的技术、实现方式、编程语言进行详细的阐述；我方所提供系统应进行良好的分层和封装，并在建议书中对软件分层和封装进行详细说明。系统质量保障系统可靠性我方向需求方提供成熟的、稳定、容错性和易恢复性俱佳的系统。在我方的应标书中应明确指明其系统的MTTR和MTBF指标（分软、硬件）。排除人为误操作因素，由应用系统自身原因导致的系统崩溃故障,平均无故障时间（MTBF）应大于365天，平均修复时间（MTTR）应小于4小时。排除人为误操作因素，由应用系统自身原因导致的系统错误故障,平均无故障时间（MTBF）应大于100天，平均修复时间（MTTR）应小于30分钟。随系统提交的技术文件必须明确标识出所实现的可度量的功能和性能指标。应用系统必须支持连续7×24小时不间断地工作，应用软件中的任一构件更新、加载时，在不更新与上下构件的接口的前提下，不影响业务运转和服务。系统必须采用增量备份和全备份相结合的方式定期备份重要的系统数据。应用系统在业务处理高峰时，各主机设备的内存利用率应该不大于70%，CPU平均空闲率不低于30%。应用系统必须支持负载均衡能力，支持应用部署在多台服务器上，避免应用系统的单点故障。应用系统应具有良好的并行处理机制，对存取冲突的竞争具有有效的仲裁和加锁机制，充分保证事务处理的完整性，并降低系统I/O开销，提高并发用户查询和存取的性。系统具备完备的功能性系统应依据本规范书实现完善、准确的功能。系统具备完整性和安全性系统提供有效的安全保密措施，确保系统和数据资源的安全，防止对系统资源的非法侵入，入侵检测系统应对违背安全事件记录并报警；我方应提供有关网络安全的详细说明，公网上传输的数据，必须以国家标准的加密算法加密，并在应标书列出算法及相关软件列表。系统应该充分利用防火墙、安全证书、SSL等数据加密技术保证系统与数据的安全。通过防火墙（硬件防火墙）对进入内部网络的数据包进行扫描过滤，能够根据用户、IP地址、访问类型等方式进行访问规则限制。系统必须能够对常见的入侵行为进行判断并阻止。提供地址翻译功能，屏蔽网络内部细节，防止外部黑客利用IP探测技术发现内部网络结构和服务器真实地址，从而实现有针对性的攻击。系统必须能够对网络通讯进行监控，及时发现任何来自于网络内部或外部的黑客入侵或可疑的访问行为，并做到及时报警与阻断。我方提供的方案必需保证传输安全，网络层需认证报文的来源，防止攻击者利用伪装地址来发送报文，确保报文在网络中传输时没有发生变化，确保报文内容在传输过程中未被读取，确保未授权方不能读取报文的内容，确保认证报文没有重复，避免攻击者通过重发截获的认证报文来干扰正常的通信。系统必须周期性地备份系统文件（不含文件传输的接口缓冲区，缓冲区中的内容备份在系统接口数据备份的章节描述），能够在系统崩溃后快速修复系统文件。不同的操作员具有不同的数据访问权限和功能操作权限，系统管理员应能对各操作员的权限进行配置和管理。系统必须支持对系统运行所必须的用户名与密码周期性更改的要求。系统必须强制实现操作员口令安全规则，如限制口令长度、限定口令修改时间间隔等，保证其身份的合法性。系统必须支持操作失效时间的配置。当操作员在所配置的时间内没有对界面进行任何操作则该应用自动失效。系统必须提供完善的审计功能，对系统关键数据的每一次增加、修改和删除都能记录相应的修改时间、操作人和修改前的数据记录。系统的审计功能必须提供根据时段、操作员、关键数据类型等条件组合查询系统的审计记录。系统的审计功能必须提供针对特定关键数据查询历史审计记录。系统易用性系统应易于安装和使用，具备风格一致的用户界面，且为中文操作界面,为方便使用，系统应设置导航栏等内容。系统应能在浏览器中完成基本管理任务，对用户输入错误应尽早发现和提醒系统应具备完善的联机帮助功能。随系统提交的产品文件必须包括完善的、针对不同级别用户的应用系统培训教材、培训考题及培训考核方法建议。厂家可以通过对产品颁发资格认证证书的方式，以确认用户对该产品的某个操作级别的使用资格。对于业务熟练并且熟悉电脑操作的普通用户，应该可以通过现场培训，即可熟练掌握应用系统基本功能的操作技能。对于系统管理员，应该可以通过不超过累计两周的培训，即可熟练掌握应用系统管理相关功能的操作技能。应用系统必须提供一致性的图形用户界面风格。应用系统对普通用户的操作界面应该以B/S方式实现。应用系统应该支持操作员登录系统后，不超过三次鼠标的点击，即可访问到业务所需功能。应用系统必须支持同时打开多个管理窗口以对不同任务进行并行的操作。应用系统应该支持在一个业务过程中的所有功能界面都有返回上一个操作的快捷链接。应用系统应该支持通过键盘即可完成一个界面窗口内的主要操作。应用系统应支持通过Tab键或回车键可访问到同一个窗口的所有控件对象。应用系统应该支持对于常用功能设置快捷键以方便功能间的切换；快捷键的功能定义在全系统保持一致。应用系统必须采用分页机制显示查询结果，并显示返回的记录数目、当前页和总页数。应用系统发现用户提交有误信息，必须以弹出窗口的形式明确提示用户错误的原因，并把界面控制焦点置于发生错误的控件对象上。应用系统的操作界面必须用“*”明确标识出必填的输入信息。当应用系统正在执行用户提交的请求而无法返回时，必须明确标识系统处于繁忙阶段。系统可维护性具备完备的数据备份和恢复机制。系统具备方便且可定期执行、分析结果的业务测试功能。系统应易于修改，对某一个模块的修改，不影响其他模块的正常运行。系统应易于扩展，新增服务时要求对系统做尽可能少的修改。系统应具备自管理和监控功能，能够实时监控各模块的执行。我方提供的系统应具备利用甲方已有时间同步系统进行时间同步和时间自动调整的功能。我方提供的系统应具备在线升级协议及版本的功能，在不中断业务的情况下支持对系统外部接口协议进行在线升级、对修改后的系统版本进行在线升级。系统在运行过程中所发生的任何错误都应该有明确的错误编号，并能在系统的相应维护手册中查到错误处理方法与步骤。应用系统应该支持通过统一的图形界面，监控各应用构件的运行状态。应用系统必须支持通过统一的图形界面，能够监控到应用系统所有的报警、异常信息。应用系统应该采用构件化设计思想，系统框架与业务逻辑分离；要求具备开放的体系结构。应用系统应该支持通过统一的图形界面能够访问到系统各构件、合约的版本信息及相应功能说明。系统完备性我方根据本规范书要求提出的方案及设备配置，必须能完成网络连接及所有要求的功能，不存在电缆、网卡或其它附件的短缺，不存在本期工程设备和软件性能不满足业务需求和系统功能的情况，否则我方须在两周内免费补齐所缺设备和软件。系统可扩展性系统应可以随时增加网络设备或模板来扩展整个网络,可以不增加任何投资，通过选择通讯协议和接入通信速率来提高网络传输速度，降低系统运行费用。应易于扩容和维护。能支持平滑无中断在线扩容或新增业务。系统可测试性随系统提交的技术文件必须明确标识出所实现可度量的功能和性能指标。我方应有固定的测试工程师进行专门的测试工作，每次新功能测试完成后，应提供详细的测试文档，包括测试的用例、方法及其结果等，交付局方人员作验收测试。测试结果应符合实际，测试未通过的项目应及时反馈并进行修改。系统可移植性应用系统应该不需改动或尽可能少的改动就可以在不同的主流UNIX服务器（如IBM、HP、SUN等）或PCserver服务器（包括虚拟机）上方便地移植。系统必须对于存储设备、备份设备及各种网络设备具有完全无关性。应用系统必须支持在不同主流数据库平台（ORACLE、Informix、sybase等）间的移植。移植时不允许修改业务逻辑构件，应该尽可能少地修改直接操作数据库的信息服务构件。应用系统必须支持在不同主流中间件平台（如Weblogic、Websphere等）间的移植。系统易安装性应用系统应该提供图形化的安装与配置界面。应用系统必须支持客户端软件版本的自动升级。功能可扩展性IT内控补充细则我方提供的系统必须符合企业内控的要求，要求至少支持但不限于以下要求。提供多种管理员角色系统管理员：系统管理员负责对该系统所涉及的硬件和软件配置的集中管理，包含性能管理、故障配置、安全管理、配置管理和统计功能等。日志管理员：日志管理员负责检查业务平台应用程序、操作系统和数据库层面安全日志记录（含对于重要的数据增、删、改操作），监督系统管理员和业务管理员执行的敏感操作，可通过浏览管理员操作日志来取得系统的所有管理操作信息。业务管理员：业务管理员负责对该系统所提供的业务的管理，如业务流程管理、业务排行管理、业务版面管理、业务接入管理、业务内容接入管理、业务合作管理业务发展数据和使用情况的分析和统计管理等。系统的数据备份和数据恢复管理系统应提供安全可靠的联机数据备份功能；我方应提供有关数据备份的详细说明，根据局方的备份要求，提出具体的备份机制建议，包括备份方式、备份周期、备份介质、备份保留时间和相关软件的列表，备份策略的制定必须充分考虑到出现异常时数据的恢复。我方应根据1）中对备份的需求以及系统现状，提出备份配置方案，并进行详细的说明。对业务平台的备份，系统必须提供和保留备份日志（自动或手工记录方式），以便运维人员每日复核备份日志，以发现备份错误或其它异常现象。能够在线完成数据备份和恢复的功能。日志管理和监控功能日志包括系统运行日志、系统和业务管理员操作日志两个部分。日志由平台系统生成，并自动进行存档保存。日志应分为几种级别，由高至低，较低级别的日志是较高级别的子集合。系统具备自动监控或人工监控业务平台的生产环境的工具和功能，及时发出系统故障告警，短信、邮件、信息提示等多种方式告警。必须提供自动或人工记录方式的监控结果日志保存功能。信息系统的逻辑访问和物理访问在系统中采用用户身份的验证机制，对系统的访问必须使用用户名和密码或者其他身份验证机制（例如USBKEY），而且每个用户帐号被授予唯一的用户。系统维护部门对访问系统（包括操作系统、数据库和应用程序层面）的用户（含超级用户）制定密码政策，并根据密码政策在系统固化相应的设置，以避免用户使用安全级别低的密码。密码政策应包括:用户密码长度最低位数的规定，密码定期更换的规定，不得使用最近的密码。对于使用密钥棒或动态密码卡的系统，需要配合使用由用户掌握的PIN码。独立于系统管理员的日志管理员负责每周检查平台应用程序、操作系统和数据库层面安全日志记录（含对于重要的数据增、删、改操作），发现异常现象应于3日内跟进或上报。安装平台应用程序、操作系统和数据库的硬件设备存放在安全的机房中。所有出入口均具备电子门禁系统或门锁的保护。只有经授权的人员可对存放平台设备的计算机机房和设备进行物理访问。对机房的访问授权须经系统维护部门主管审批。非授权人员出入机房必须由机房工作人员陪同。人员进出机房会在机房门禁系统或机房进出日志中留下记录。对IPv6的支持我方提供的软硬件应能支持IPv4/IPv6双栈（需支持IPv6功能，支持IPv6终端用户的访问，提供基于IPv6的业务），如暂时不能支持，我方应承诺免费升级至支持IPv4/IPv6双栈的版本。对云计算的支持我方提供的软件应能支持云计算技术，如暂时不能支持，我方应承诺免费升级至支持云计算技术的版本。详细建设技术方案在以下功能要求中，如果系统需进行周期性操作，要求实现周期可配置；如不特别说明，系统所配置的缺省参数均为本规范书所提出的要求。总体设计总体架构主要架构说明：应用展现层Pdf编辑器使用了VC的MFC框架实现，双屏监控及广告播放采用.net的c#实现。页面展示主要是通过客户端浏览器给客户提供服务的，此部分采用了jsp动态页面技术，jquery脚本语言（基于javascript），easyUIFramework提供的前段布局样式。中间件层中间件层主要实现了请求的控制及转发，给客户展现的数据封装等工作。此部分采用了Nginx。管理及服务层在管理及服务层中是实现了系统的主要业务逻辑，系统通过业务逻辑层访问数据层，实现业务处理的事务性，异步性等许多与需求密切相关的业务。同时，业务逻辑子层又对外提供了一个统一的接口，调用者无需了解业务逻辑的具体实现。此部分主要采用了spring的业务Bean的方式，统一用spring容器托管，给对外提供的接口方面采用了ApacheCXF开源的Services框架。应用安全层主要定义object与RDB（表）的映射关系，用xml格式保存映射关系。通过数字证书托管、密钥存储、数字签名及加密算法实现。数据库层数据访问子层是为业务逻辑子层提供数据访问接口，此部分采用了Hibernate框架，通过Hibernate，一方面实现了ORM映射，另一方面可以实现数据库的无缝迁移。系统流程系统数据流程见下图：功能架构服务平台是云化IT架构的核心组成部分，基于统一的共享PaaS使能平台，可以面向企业不同域的业务系统，实现统一的技术架构、统一的运营体系、统一的运维团队，以及组件的分布部署。PaaS平台平台技术以微服务和DevOps为核心理念提供统一的技术架构和运营体系，平台向上提供分布式服务框架与分布式基础技术组件，简化开发分布式微服务应用的过程，提升开发微服务应用的效率，降低开发微服务应用的技能要求。向下提供多租户管理能力，开发运维门户，DevOps系统，管理调度等能力，形成应用从开发到运维的生命周期闭环管理，功能架构图如下。建设原则本工程在建设过程中需要从系统的先进性、可扩展性、安全可靠性、投资保护原则等诸多方面给予全面的考虑：先进性、标准性原则本工程新增设备应具有国际先进性，应符合国内外相关标准、规范。安全、可靠性本工程新增设备应具备高度的安全、可靠性。大容量原则本期系统的建设在设备配置、系统规模等方面应满足大容量、适度超前的原则，综合考虑本期以及未来可能建设的OSS域相关系统的需要。投资保护原则本工程的建设应尽量利用现网及集团同期建设的企业2016年集团云资源池内蒙节点A扩容工程的软硬件设备，以降低建设成本，充分保护企业原有的投资。建设方案用户体验组件用户体验是人对于使用一个产品、系统、服务时的预期和反应。从广义上来看，体验的主体是人，客体可以是一切物体和事情，媒介是我们的感官；当我们的感官作用在一切事物上，会产生相应的心理行为，比如预期，比如反馈，比如情绪，这所有的一切一起作用，形成了用户体验过程。用户体验设计的目标是逐步不断提升用户满意度，对于用户而言，永远没有所谓“最满意”的说法，只有“相较于上一次体验更满意”.所以除非定义一种可量化的终极满意度模型作为指标参照，否则用户体验设计是一个永远都有优化空间的过程。用户体验设计是围绕过程的设计，当前智慧运营平台项目改造中，优秀的用户体验组件不仅要好看而且要好用，不仅仅是视觉上高端大气上档次，使用上也要给人以畅快淋漓，一气呵成之感。为了提供当前系统的用户体验并保证智慧运营平台系统交互体验规范统一，本次组件设计需要遵循以下准则：组件色系风格统一，在整个智慧运营平台系统中，主色调推荐使用蓝色商务色系，正确使用绿色，警告使用蓝色，重要警告使用红色；操作按钮也蓝色为主。示例如下图：

全系统中布局和导航设计规范统一，符合互联网用户使用习惯。控制单次表单的大小，对于负责的业务表单数据，建议分步或分组进行，降低用户受挫感并支持单步表单保存提高使用体验。示例如下：

操作和交互行为规范统一，提供常用的行为组件模型，操作行为流程各子系统中进行规范统一，包括导航、菜单和切换返回的布局位置要协调统一。重要操作需再次确认并警告突出，关键业务数据操作时，一定要对用户进行足够的提醒，避免人为误操作。示例如下：

提供丰富完善的扩展组件,除了提供统一布局导航和常用表单组件外，并提供丰富的高级扩展组件，如日历、时间轴、图表等统计组件。用户体验组件除了满足视觉和交互要求外，同时要保证自身的代码质量并要降低开发人员的使用成本：代码质量高，功能丰富，API灵活友好，快速的交互相应，细致、漂亮的UI，完整的的文档和开发扩展支持。设计原则1.对比（Contrast）对比的基本思想是，要避免页面上的元素太过相似。如果元素（字体、颜色、大小、线宽、形状、空间等）不相同，那就干脆让它们截然不同。要让页面引人注意，对比通常是最重要的一个因素，正是它能使读者首先看这个页面。2.重复（Repetition）让设计中的视觉要素在整个作品中重复出现。可以重复颜色、形状、材质、空间关系、线宽、字体、大小和图片，等等。这样一来，既能增加条理性，还可以加强统一性。3.对齐（Alignment）任何东西都不能在页面上随意安放。每个元素都应当与页面上的另一个元素有某种视觉联系。这样能建立一种清晰、精巧而且清爽的外观。4.亲密性（Proximity）彼此相关的项应当靠近，归组在一起。如果多个项相互之间存在很近的亲密性，它们就会成为一个视觉单元，而不是多个孤立的元素。这有助于组织信息，减少混乱，为读者提供清晰的结构。色彩和布局主色调推荐使用蓝色商务色系，正确行为使用绿色，警告行为使用蓝色，重要警告行为使用红色。我们推进使用以下颜色作为设计和开发规范，以保证页面和组件之间的视觉一致。蓝色作为主色调LightPrimary常用于hover，DarkPrimary常用于active，颜色参照如下：辅助色是具有代表性的颜色，常用于信息提示，比如成功、警告和失败。中性色常用于文本、背景、边框、阴影等，可以体现出页面的层次结构。整体页面布局上，一般主导航放置于页面的顶端，从左自右依次为：logo、一级导航项、辅助菜单（用户、设置、通知等）。通常将内容放在固定尺寸（例如：1200px）内，整个页面排版稳定，不受用户终端显示器影响；上下级的结构符合用户上下浏览的习惯，也是较为经典的网站导航模式。页面上下切分的方式提高了主工作区域的信息展示效率，但在纵向空间上会有一些牺牲。此外，由于导航栏水平空间的限制，不适合那些一级导航项很多的信息结构。示例如下：导航菜单导航菜单基于以下准则进行设计：一级导航和末级的导航需要在可视化的层面被强调出来；当前项应该在呈现上优先级最高；当导航收起的时候，当前项的样式自动赋予给它的上一个层级；左侧导航栏的收放交互同时支持手风琴和全展开的样式，根据业务的要求进行适当的选择。菜单示例如下：

字体和图标框架组件中，对CSS对字体进行统一规范，力求在不同平台、浏览器下能显示出其最佳的效果。当前智慧运营平台系统中，中文字体推荐优先使用微软雅黑。框架组件中提供丰富的针对智慧运营平台和企业业务系统的字体图标库，以满足各中心引擎业务开发的要求。示例如下：按钮当前系统中按钮的设计规范如下：将按钮放在用户希望看到的地方，用户对于页面交互其实是有基本的感知和期望的，也就是说用户对于按钮的位置是有个基本的认知的。不要让用户到处找按钮，它最好在用户所期望的位置出现。按钮上应该加上相应操作的标签，当按钮的文本标签上的内容写的太过于宽泛，或者使用带有误解的内容，可能会让用户感到迷惑。每个标签上的文本标签都应该尽量准确，简明直接地介绍清楚它的真实功能。按钮应该拥有合理的尺寸，按钮的大小应该反映出屏幕上这一元素的优先级，更大的按钮应该意味着更重要的交互。注意按钮的次序，按钮的顺序应该反映出用户和界面之间交互的属性，问问自己用户期望在屏幕上看到什么样的顺序，或者说什么样的顺序更合理，然后进行相应的设计。避免使用太多按钮，当你提供太多的选择的时候，用户往往会无所适从。按钮类型有：默认按钮、主按钮、虚线按钮、文字按钮以及四种颜色按钮。示例如下：图标按钮示例如下：按钮状态示例如下：表单表单按照由小到大，由静到动的策略进行设计。表单之所以复杂，很重要一点是来源于它所服务业务（特别是后台产品）的复杂度。各种业务逻辑的组合，不同“层级”的信息透出，一大达到一定的复杂度就会导致混乱，最后失控。为了让我们自己先不混淆，我们需要把表单的最小单元、单元组合、静态展示、动态反馈拆开分别一步步的递进处理。表单示例如下：表格表格的设计集中体现在可视化（可读性）和易操作两个方面，好的数据表格允许用户对信息进行快速的扫描、查询、过滤、分析等操作，以获取深刻认知并快速准确完成目标任务。其基本设计原则是“全面整合并呈现业务数据，提供顺畅阅读体验，便于用户发掘重要信息，进行便捷操作”，简而言之，即“满足业务需求+符合用户心智模型”。表格示例如下：标签标签用于对不同维度进行简单的标记和分类，标签的增加要在视觉上起到辅助作用，同时又不会让整个页面变得很有负担，因此大多都是对比色或者饱和度比较高的颜色。标签示例如下：提示层提示层示例如下：扩展组件扩展组件示例如下：统一数据访问引擎（数据中间件）优化提供一个数据库分库分表中间层，采用数据库代理方式，形成分布式数据库中间件解决方案，解决分布式系统数据库分库分表带来的数据透明访问难题。整体功能架构如下图所示：图功能架构图DBProxy：UDAL的核心组件，是一个实现了mysql协议的Sever进程，前端用户可以把DBProxy看成数据库代理，可用mysql客户端工具或命令行方式直接访问，其后端以mysql原生协议与多个mysql数据库进行通信，也可以用jdbc协议与大多数主流数据库服务器通信，DBProxy的核心功能是分库分表并对应用层屏蔽分库分表带来的访问难题。网络通讯：提供高并发、低延迟的网络通讯。MySQL协议适配：采用MySQL开源协议，实现前后端网络请求的协议格式。SQL解析：解析SQL语句文本，为节点路由计算提供依据对象。分库分表数据路由：通过用户配置的分库策略，计算数据存取的数据库节点。SQL执行：实现单语句、多语句并发执行SQL功能。SQL结果汇聚：对语句多节点执行的结果进行接收并做二次计算，得到多节点情况下的正确结果。全局序列：实现全局唯一序列。事务控制：同一个事务内的SQL由同一个链接进行处理，保证事务原子性。读写分离：提供数据库节点的读写分离功能。由分库分表中间件根据配置动态判断。安全控制：SQL语句拦截过滤，权限认证等。GiServer：切片索引服务进程，是为了提升非分片键查询（select语句）时的效率（避免广播查询）而开发的，与数据库的索引没有任何关系，是完全不同的两个概念，GiServer是切片索引数据的生产者，真正的消费者是DBProxy进程，假设客户表是以cust_id进行分表的，但应用需要通过客户身份证来查询客户信息，如果没有切片索引，则DBProxy会将查询语句广播到所有节点执行，接收到执行结果进行汇聚后再返回给应用，如果建立了切片索引，则DBProxy首先会根据身份证号码从切片索引中查询到对应的cust_id，再根据分片算法定位到cust_id对应的分片，这样就避免了广播查询。运维管理平台：提供完善的配置、发布和运维管控平台。配置功能及发布：提供在线配置功能、实时发布，无须重启服务，保证不中断在线调 整服务。服务发布启停：提供分库分表中间件服务的发布和启停功能。服务监控报警：提供CPU、内存、IO、连接数、慢SQL、TOPSQL等监控，对于超过阀值提供报警功能。运维操作功能：提供在线查看数据、数据迁移同步、限制应用链接、安全检测等日常运维管理操作。统一数据访问层技术架构如下图所示：图技术架构图基于NIO技术提供高并发、低延迟的网络通讯。采用MySQL开源协议，实现前后端网络请求的协议格式。采用druid开源项目，解析SQL语句文本，为节点路由计算提供依据对象。实现取模、一致性哈希等算法，通过用户配置的分库策略，计算数据存取的数据库节点。基于zookeeper存放DBProxy、GiServer等的配置信息及利用zookeeper的分布式一致性实现全局唯一序列。依赖外部组件分布式缓存，存放切片索引数据。全局序列由于分库分表的主键ID保存在不同的数据库，为了保证全局序列号的唯一性，需要统一提供全局序列号的维护来保证序列号的唯一性。系统提供全局sequence，并且提供包含本地配置和数据库配置等多种实现方式。本地配置方式，将sequence配置到文件中，当使用到sequence中的配置后，获取配置文件中sequence当前的值。数据库方式，在数据库中建立一张表，存放sequence名称(name)，sequence当前值(currentvalue)，步长(incrementint类型每次读取多少个sequence，假设为K)等信息，Sequence获取步骤：

a)当初次使用该sequence时，根据传入的sequence名称，从数据库这张表中读取current-value，和increment到系统中，并将数据库中的current-value设置为原current-value值+increment的值。

b)系统将读取到current-value和increment作为本次要使用的sequence值，下次使用时，自动加1，当使用increment次后，执行步骤a)相同的操作。

c)系统负责维护这张表，用到哪些sequence，只需要在这张表中插入一条记录即可。若某次读取的sequence没有用完，系统就停掉了，则这次读取的sequence剩余值不会再使用。本地时间戳方式，ID=64位二进制(42(毫秒)+5(机器ID)+5(业务编码)+12(重复累加)，换算成十进制为18位数的long类型，每毫秒可以并发12位二进制的累加。分布式ZKID生成器，基于ZK与本地配置的分布式ID生成器，ID结构：long64位，ID最大可占63位：*|currenttime(微秒时间戳38位,可以使用17年)|cluster-Id（机房或者ZKID，通过配置文件配置5位）|instance-Id（实例ID，可以通过ZK或者配置文件获取，5位）|thread-Id（线程ID，9位）|increment(自增,6位)。应用自定义方式，有上层平台框架提供公共的应用服务全局序列支持。事务控制分布式事务处理（DistributedTransactionProcessing，DTP）指一个程序或程序段，在一个或多个资源如数据库或文件上为完成某些功能的执行过程的集合，分布式事务处理的关键是必须有一种方法可以知道事务在任何地方所做的所有动作，提交或回滚事务的决定必须产生统一的结果（全部提交或全部回滚）。X/Open组织定义了分布式事务处理模型。X/OpenDTP模型（1994）包括应用程序（AP）、事务管理器（TM）、资源管理器（RM）、通信资源管理器（CRM）四部分。一般，常见的事务管理器（TM）是交易中间件，常见的资源管理器（RM）是数据库，常见的通信资源管理器（CRM）是消息中间件，下图是X/OpenDTP模型：一般的编程方式是这样的：配置TM，通过TM或者RM提供的方式，把RM注册到TM。可以理解为给TM注册RM作为数据源。一个TM可以注册多个RM。AP从TM获取资源管理器的代理（例如：使用JTA接口，从TM管理的上下文中，获取出这个TM所管理的RM的JDBC连接或JMS连接）AP向TM发起一个全局事务。这时，TM会通知各个RM。XID（全局事务ID）会通知到各个RM。AP通过1中获取的连接，直接操作RM进行业务操作。这时，AP在每次操作时把XID(包括所属分支的信息)传递给RM，RM正是通过这个XID与2步中的XID关联来知道操作和事务的关系的。AP结束全局事务。此时TM会通知RM全局事务结束。开始二段提交，也就是prepare-commit的过程。XA协议，指的是TM和RM之间的接口，其实这个协议只是定义了XA_和AX_系列的函数原型以及功能描述、约束和实施规范等。至于RM和TM之间通过什么协议通信，则没有提及，目前知名的数据库，如Oracle,DB2等，都是实现了XA接口的，都可以作为RM。Tuxedo、TXseries等事务中间件可以通过XA协议跟这些数据源进行对接。JTA是符合X/OpenDTP的一个编程模型，事务管理和资源管理器支架也是用了XA协议。下面两个图片分别给出了XA成功与失败的两种情况，首先是XA事务成功的流程图：然后，是XA事务失败的流程图：安全控制数据库中间件的安全控制主要由SQL拦截和权限认证实现。SQL拦截是一个比较有用的技术，用户可以写一个java类，将传入的SQL进行改写然后再去执行，此技巧可以完成如下一些特殊功能：捕获和记录某些特殊的SQL；记录SQL查找异常；出于性能优化的考虑，改写SQL，比如改变查询条件的顺序或增加分页限制；将某些SelectSQL强制设置为Read模式，走读写分离；拦截所有SQL做智能分析，自动监控节点负载，自动优化路由，提供数据库优化建议。SQL拦截的原理是在路由之前拦截SQL，然后做其他处理，完了之后再做路由，执行,如下图所示：权限认证支持租户、用户隔离，支持平台权限和精细颗粒权限控制。分片规则分片枚举

通过在配置文件中配置可能的枚举id，自己配置分片，本规则适用于特定的场景，比如有些业务需要按照省份或区县来做保存，而全国省份区县固定的，这类业务使用本条规则。固定分片hash算法

本条规则类似于十进制的求模运算，区别在于是二进制的操作,是取id的二进制低10位，即id二进制&1111111111。此算法的优点在于如果按照10进制取模运算，在连续插入1-10时候1-10会被分到1-10个分片，增大了插入的事务控制难度，而此算法根据二进制则可能会分到连续的分片，减少插入事务事务控制难度。范围约定

此分片适用于，提前规划好分片字段某个范围属于哪个分片取模，此规则为对分片字段求摸运算。按日期（天）分片

此规则为按天分片。取模范围约束

此种规则是取模运算与范围约束的结合，主要为了后续数据迁移做准备，即可以自主决定取模后数据的节点分布。截取数字做hash求模范围约束

此种规则类似于取模范围约束，此规则支持数据符号字母取模。应用指定

此规则是在运行阶段有应用自主决定路由到那个分片。截取数字hash解析

此规则是截取字符串中的int数值hash分片。一致性hash

一致性hash预算有效解决了分布式数据的扩容问题。按单月小时拆分

此规则是单月内按照小时拆分，最小粒度是小时，可以一天最多24个分片，最少1个分片，一个月完后下月从头开始循环。每个月月尾，需要手工清理数据。范围求模分片

先进行范围分片计算出分片组，组内再求模优点可以避免扩容时的数据迁移，又可以一定程度上避免范围分片的热点问题综合了范围分片和求模分片的优点，分片组内使用求模可以保证组内数据比较均匀，分片组之间是范围分片可以兼顾范围查询。最好事先规划好分片的数量，数据扩容时按分片组扩容，则原有分片组的数据不需要迁移。由于分片组内数据比较均匀，所以分片组内可以避免热点数据问题。日期范围hash分片

思想与范围求模一致，当由于日期在取模会有数据集中问题，所以改成hash方法。先根据日期分组，再根据时间hash使得短期内数据分布的更均匀优点可以避免扩容时的数据迁移，又可以一定程度上避免范围分片的热点问题要求日期格式尽量精确些，不然达不到局部均匀的目的冷热数据分片

根据日期查询日志数据冷热数据分布，最近n个月的到实时交易库查询，超过n个月的按照m天分片。自然月分片

按月份列分区，每个自然月一个分片，格式between操作解析的范例。路由分发路由能保证sql转发到正确的节点。转发的范围是刚刚好，不多发也不少发。多发会出现两种问题：浪费性能和找不到表。比如一个select*fromorderswherepro=‘wuhan’这个语句，只有dn1节点，能查到数据，如果将语句同时转发到dn1、dn2、dn3三个节点，这样的范围就多发了，性能上是一种浪费。如果新增了一个节点dn4，但是orders的datanode范围只是dn1,dn2,dn3，如果同时转发到dn1、dn2、dn3、dn4四个节点，则发到dn4执行时会返回tableordersnotexists。少发则会出现结果集不全的问题，如select*fromorders如果只转发到dn1，只会返回dn1上的结果集，dn2、dn3上的结果集得不到。单表路由计算流程如下图：多表路由计算中有子流程“单表路由计算”，这个子流程引用了上面的单表路由计算流程，多表路由计算流程如下：消息中间件本期工程整体功能架构如下图所示：图STYLEREF2\s4.2SEQ图\*ARABIC\s28功能架构图如图中所示，本期工程主要对API、Broker消息节点实现、命令行与运维平台进行优化与完善。系统技术架构如下图所示：图技术架构图其中，Producer/consumer与server，broker建立并维持长连接，broker将系统状态，服务统计通过心跳传送给nameserver，供客户端访问获取。消息重复处理在实际CRM、计费需求中，部分业务场景如：订单，不能有重复消息，因此需要进行消息去重处理。在分布式架构下，单纯依赖消息中间件难以实现完全去重，因此采用消息中间件增加消费去重处理+应用幂等性+运维手段结合的方式来达到消息完全不重复的目的。发送阶段，消息中间件对网络超时等不确定失败进行记录。方便运维排查重复。消费阶段，通过在服务端记录消息的消费状态，避免消息被重复消费与签收客户端返回中间状态处理消息中间件是通过持久化磁盘和主备机制来保证消息高可靠不丢失。当前消息中间件支持同步/异步刷盘，以及主从节点的同步/异步复制模式。在强同步模式下，生产者发送消息到消息中间件可能存在如下中间状态：1、主节点刷盘超时(FLUSH_DISK_TIMEOUT)2、主节点写Slave超时(FLUSH_SLAVE_TIMEOUT)3、写Slave失败(SLAVE_NOT_AVALIABLE)4、生产者与Broker之间网络超时上述状态之所以称为中间状态，是因为消息中间件发送消息并非强一致性的事务，因此出现上述状态时，消息可能成功，也可能失败；为了确保应用消息处理逻辑，消息中间件需要有对应上述状态的处理机制。增大超时时间,减少超时错误对于超时状态：增加超时消息确认机制，尝试查询服务端，确认消息是否成功，如果成功返回成功，如果失败返回失败，如果无法确定，则返回timeout，并记录异常消息对于其他中间状态（刷盘，写slave超时，写slave失败）：发送失败，提供明细错误码，供应用根据可靠性要求选择处理，并记录异常消息，告警并人工介入，进行主备切换或者禁写broker（提供处理脚本和文档说明）。消息签收超时处理当前CtgMQ中，没有消费超时的处理，即如果消息派发给应用消费，但应用不返回消费结果也不抛异常，那消息中间件会一直等待消息完成，而此种情况下，无序/有序消费都会出现堆积，堵塞所在同一消息分区的后续消息的消费。据了解，阿里的设计初衷是考虑到此类情况一般都是应用逻辑发生问题，必须应用告警（应用自身告警，或根据堆积量告警）介入处理，因此MQ自身不提供处理机制。计费应用提出，希望能够提供机制，保证在消息处理无法返回（如消息数据、逻辑等问题导致消息处理线程卡住）的情况下，能够继续后续消息的消费。提供可选的签收超时处理机制打开超时处理，自动签收超时消息。按GroupId分片有序场景队列扩容需求队列按GroupID多分片部署，消息有序，订单按照CustID取模分发到不同的分区。队列在线扩容后，可能相同CustID的不同订单同时在新、老分片都存在，可能导致消息短暂无序，在严格要求消息有序场景下，需要有相应机制处理；消息中间件队列扩容过程中，由于消息新老分发规则变更，可能出现消息无序。建议解决方案为通过运维手段，在扩容前暂停消息写入，待队列消息全部消费完成后再扩容，最后恢复消息生产消息中间件运维控制台增加功能：监控队列深度停止和恢复生产消息写入创建新队列在线扩容通过运维控制台手工进行，具体操作步骤为：停止需要扩容的队列消息写入；查看队列深度，直至全部消息消费完成；队列深度为零后，创建新的队列；新增加消费端应用启动；恢复生产消息写入，扩容完成。消费者扩容当增加新的消息队列时，希望能增加新的对应的消费端。消息中间件提供按Topic查询队列使用明细API，应用调用该API可以获取该Topic下的队列情况，灵活对应消费端。提供《消费线程机制说明文档》，详细说明消息中间件消息消费线程机制。单队列不同业务类型消息消费需求计费应用单个队列中可能存在不同业务类型的消息，希望能够相互之间不影响消息的消费，一个业务的消息不消费、签收，不会影响其他类型业务消息的处理。能够对不同类型的消息，设置不同的tag，不同消费者指定tag消费。从而相互不影响支持跳跃签收，由应用的逻辑来处理不同类型业务消息。提供无序模式下消息跳跃性签收处理功能计费应用一个队列中可能包含多个分片的消息，导致部分消息之间存在顺序依赖，但是并不是完全顺序。消息中间件现有的机制，在消费客户端保存了一些消费相关状态，因此1) 由于客户端可能频繁重启和数量变化，以及MQ的rebalance机制，这些状态可能会丢失，从而可能导致状态丢失后的消费重复2) 滑动窗口机制下，如果消息长时间不签收，将导致无法消费后续消息，否则存在大量消息重复的风险此问题的本质是当前MQ实现为了性能和设计简化，没有对每条消息记录状态，而只是记录一个标量的消费进度，导致客户端需要记录额外的状态，而客户端可靠性较低(尤其是在测试环境下)。服务端存储消费状态，保证客户端重启或变化不丢失状态增加滑动窗口，保证消息不签收情况下，仍能继续拉取新消息。用户名密码接入认证API在创建连接的时候，做用户名密码认证，认证通过才可以发送和消费消息服务端增加用户名、密码配置文件，保存加密后的认证信息客户端初始化时，连接服务端将用户名密码加密发往服务端认证，认证成功才能进行后续的发送和消费操作动态增减nameserver为了保证消息中间件nameserver模块的高可用，nameserver可能包含多个进程，且可能动态调整增减。希望能够有机制设置并在运行过程中自动调整。基于RocketMQ的http方式获取nameserver地址，并与管理控制台结合，在创建集群后，能够自动生成http服务地址，并可用于API使用。增加相应配置的校验完善连接管理，关闭不存在的服务连接完善监控平台为了提高消息中间件的使用体验，MQ管理台需要进行优化与完善。消息数量、消费深度等信息查询Broker服务扩容、缩容流程节点、生产者、消费者在线监控消费积压监控消息吞吐量监控消息回溯批量创建主题重置消费进度增加关键操作日志方便查看用户操作删除topic和消费组关系消息回溯消息综合查询。监控运维提升支持监控中心对接，支持应用运营平台对接。支持消息中间件接入易监控平台支持消息队列监控支持消息队列查询提供消息中间件概况信息点指标完善版本自动发布和自动测试流程梳理测试、发布流程，并进行自动化，减少人工测试、发布过程中的错误。版本自动发布：提交某个版本最终代码后，补充相应的部署文档、API说明文档、changlog说明以后，可以通过jenkins自动完成版本的编译、部署、自动化测试和发布最终版本等工作。最终获取的发布包不用做修改可以直接发送给客户使用。自动测试流程：通过jenkins定期根据主干代码编译、部署消息中间件，同时运行自动化测试用例进行测试。当发现缺陷时，模拟缺陷的场景补充自动化测试用例。多集群的主备自动切换，备机自动拉起支持MQbroker服务的自动切换与备机自动拉起。Broker分组的备机故障后，可以自动拉起Broker分组的的主机故障后，从broker升主后可以继续对外提供服务整个broker分组中的机器被重启后broker可以重新被拉起。主备切换过程中不一致数据的回滚主备切换前主从数据不一致，主从切换后可以对不一致的数据进行回滚。支持主从切换过程中新从上面的多余Commitlog、ConsumeQueue等消息数据回滚、消费进度和消费状态数据的回滚。支持从升主后消息数据和消费进度数据不一