基于大数据的集团共享服务中心建设的构想

欧阳凌云

摘要： 该文分析我集团公司内信息化建设面临的问题，引用共享服务模式，建议在集团公司信息化建设中，构建共享服务中心，可以为整个集团提供资产管理、项目管理、知识管理、流程管理、客户管理等方面的标准化服务，有效降低运营总成本，快速响应集团公司的信息化、智能化业务发展，支持集团公司开展落实互联网+转型的相关工作。

关键词：共享服务；共享服务中心

中图分类号：TP311 文献标识码：A 文章编号：1009-5039（2018）16-0245-03

1 引言

在2015年7月，国务院出台了《国务院关于积极推进“互联网+”行动的指导意见》，意见指出，“互联网+”是把互联网的创新成果与经济社会各领域深度融合，推动技术进步、效率提升和组织变革，提升实体经济创新力和生产力，形成更广泛的以互联网为基础设施和创新要素的经济社会发展新形态。

我集团公司积极响应国家号召，开展落实互联网+转型的相关工作，积极探索和引用互联网的新技术、新方案、新模式、新理念，尤其是对如何利用“大数据”创造商业价值作为集团研究信息化的主要课题。大数据以及“数据即服务”是展示企业核心竞争力，并挖掘新商业模式，从而推动企业发展的强大技术手段。集团将“大数据”作为信息化工作的重心与着力点，集团内的项目都是按“大数据项目”的要求来建设。但部分大数据项目的匆匆上马仅是形式上采用了大数据，项目带来的成效并没有达到集团信息化的预期目标。各项目中数据分布广，格式不统一，技术规范不标准，缺少能基于数据有业务建模能力的专家等。为解决目前存在的这些问题，我建议在集团公司信息化建设中构建共享服务中心，重新分析业务需求，分解业务为事务，事务再细化为微服务，最终将项目或管理以无数微服务方式呈现。共享服务中心可以为整个集团提供各应用系统的标准化服务，降低运营成本，提高集团业务快速响应能力，使集团更高效地向信息化、智能化方向发展。

2 集团内信息化建设面临的挑战

目前集团内信息系统建设的模式是由各公司业务部门提出业务需求，研发部门进入到需求收集、需求分析、开发、测试、上线、运维的项目周期中。每个新系统的上线都预示着一座新的信息孤岛的建立，这种完全基于业务需求建设系统的方式，已经成为过去集团内建设信息化系统的标准流程，导致集团内部系统繁多、各自堆砌、独立运维。这些系统的问题总结来说就是业务重建率高，业力扩展响应能力差，维护成本高。

传统项目的模式如下图1。

面对这种业务需求和处境，孕育而生了面向服务的架构（SOA），重点是解决这些异构系统之间的交互问题。SOA是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些之间定义的接口和契约联系起来。SOA里面最核心的價值是松耦合的服务带来业务的复用，通过服务助力业务的快速响应和创新。我集团在实施SOA项目上，目前仅仅是采用服务的形式，通过服务接口技术等实现了各系统的互联，不利于集团中的各业务服务的持续发展和沉淀。

随着大数据的涌入，如何让我们的项目达到一个最优化并发的访问量成了我们研究的一个课题。我们需要对SOA架构进行再次细化拆分，让我们的项目成为面向服务的分布式架构。但分布式框架还是有很多问题，比如，要掌握的工具太多，部署网络复杂，网络设备类型多，完全掌握难度大，手工操作太多等等。谈到分布式服务框架，还要提到又一热门名词“微服务”。微服务架构是一种使用很多小服务组合开发的方式，使用轻量级机制通信。这些服务是基于业务的需求，并通过自动化部署机制独立部署，这些服务可能使用不同的编程语言，不同的数据存储，但保持着最低限度的集中式管理。但这也不是最完美的解决方案，即使是基于Docker的容器技术，也存在服务管控、分布式事务、平台稳定性等问题。

从传统架构到分布式架构，以这些方式建设起系统，对企业存在以下几点弊端：

1） 重复功能建设和维护带来的重复投资。

2） 打通各系统间交互的集成和协作，成本高昂。

3） 不利于业务的沉淀和持续发展。

从成本和效率的角度来看，这样的建设项目的模式，除了带来前面所提到的传统架构建设的一系列弊端，信息化部门只是做业务支持的部门，信息化建设只是为了满足业务部门需求而进行建设的实施和运维。这样的模式下，造成我们今天看到的很多信息化部门的员工，大部分工作内容就是进行项目管理，负责开发商招投标，开发商和业务团队间的协作沟通，紧盯项目进程， 当一个项目顺利上线验收后，这些员工开始投入到下一个项目工作中。在这过程中，往往只突出了员工的工作能力，他的价值是可以负责更大的项目，或是同时负责多个项目，而这些只是个人增加了项目经验，并不能在某一专业领域得到知识和经验的积累。

从发展的角度来看，传统架构系统的方式以及项目制的建设方式，业务得不到持续发展，从而造成服务不能真正成为可重用的组件，无法为业务的快速响应和快速创新带来价值。服务不应追求业务稳定，如果服务不能满足业务需求，那么当业务发展时，也就是这个服务消亡的时刻。

3 共享服务中心的定义

3.1 什么是共享服务

哈佛大学教授Bryan Bergeron在《共享服务精要》一书中给出了共享服务的定义：“共享服务是一种将一部分现有的经营职能集中到一个新的半自主的业务单元的合作战略，这个业务单元就像在公开市场展开竞争的企业一样，设有专门的管理结构，目的是提高效率、创造价值、节约成本以及提高对内部客户的服务质量。”

共享服务是通过梳理企业内部的业务，重新整合资源，沉淀出共有服务，再被多个部门或系统重复利用，达到资源优化，降低成本。

3.2 什么是共享服务中心

MBA智库提出，共享服务中心的概念，始于20世纪的美国，其原理是将公司（或集团）范围内的共用的职能/功能集中起来，高质量、低成本地向各个业务单元/部门提供标准化的服务。共享服务中心所集中的通常是诸如财务、信息系统、人力资源、法律、采购、研发等职能，通过这种方式，既可以发挥规模效应、节约成本，同时也有助于保证这些职能的质量和一致性。

我集团公司的转型工作更倾向于信息化建设，因此共享服务中心就是要把集团内现有的、各自独立运维的系统“整合”起来，把系统服务变成微服务的组合，微服务重现业务及复用业务的同时，还可再自由组合，提供更多种服务帮助集团组建新业务新系统，促成面向业务的可持续的改进和扩展。

4 共享服务中心的意义

我集团公司在落实互联网+转型的工作中，涌现出了新一批的业务需求。业务的数据量成n次幂的速度在增长。各项目之间，各系统之间的信息交互，及大数据带来的难维护、难监管、难分析等问题，急需一种方式来应对。而共享服务是一种商业模式，电商如淘宝，业内如特来电，已经有很多成熟的框架和成功的应用案例。通过建立共享服务中心，可以为整个集团提供资产管理、项目管理、知识管理、流程管理、客户管理等方面的标准化服务，有效降低运营总成本，快速响应集团公司的信息化、智能化业务发展，支持集团公司开展落实互联网+转型的相关工作。

如果企业打造了共享服务体系，一方面会彻底改变现在传统方式系统建设的模式，新的项目都会基于共享服务体系建设，在项目的建设周期和投入上，会相比之前带来很大的效率提升，信息部门员工也无须把精力更多投入到负责项目管理的事务中，接下来对整个共享服务体系中的微服务进行运维，按微服务重新编制人员，让员工在各自业务服务中持续发展，提高员工对所提供的业务理解和专业技能，这样对员工的工作积极性和创造意识的提升，都将会创造一个很好的氛围。

4.1 提高效率

通过将系统分解为单一责任、高内聚、松耦合、独立部署、自主运行的微服务，可以极大提升系统的灵活性与扩展能力，大大降低系统间的耦合度以及整体复杂度，各个团队可专注于各自的業务模块。

4.2 业务重组

共享服务层的建立，很好地对横向业务提供了统一的数据和服务收口，比如“财务会计”“人力资源”“信息技术”“供应存储”等主营设备、业务等依赖共享服务，通过共享服务，得到了业务输出的一致性和统一性，业务拆分后，减少了对单一数据库的依赖，提升了数据库集群连接能力。

4.3 安全、容错

对数据做统一治理、统一帐号管理、单一访问，提高了数据的安全性、故障独立性，一个单元内的故障不会传染到其他单元，提高了服务的可用性。

4.4 技术扩展

利用共享服务，解决了业务扩展性的问题，但也面临着系统采用分布式框架后分布式管理带来的新问题。为了解决单库性能瓶颈问题，使用分库分表的技术，为了解决分布式事务的性能的问题，把原来一个事务里的工作拆分成了异步执行，同时必须要保证最终数据的一致性，我们采用了消息发布订阅的方式来解决，这些方式有效地解决了应用分布式后带来的技术扩展问题，同时让整个系统的技术框架更具有技术扩展能力，如果系统负载能力不够，只需要增加装载相关业务的微服务的服务器即可。

4.5 成本

降低不同系统开发团队间的协同成本，可以使业务响应更加敏捷。首先，通过抽取现有系统的公共元素，提取出共享服务，降低了创新和试错成本。其次，形成一套业务的中间件。中间件的意义在于像采用了同一种语言一样，降低了学习研究和运维的成本。做到针对业务能力扩展，减少不必要的资源浪费。

从设计层面来看，主要是要采用面向对象的分析设计方法，即业务和系统建模，遵循面向对象的基本原则。

从运营的层面来看，服务中心是一个完整的业务解决方案，必须有数据运维和业务整合的能力和价值。

从工程层面来看，共享服务的架构是基于分布式架构，分布式架构解决了一体化架构在大规模应用上的问题，但是也引入了分布式事务、问题排查等方面的一些难题，所以在规划服务中心的时候，不要只注重业务拆分，一定要综合评估业务层对数据服务中心的需求。

5 搭建共享服务中心的建议

共享服务体系以业务为核心，所提供的每一个服务都应持续更新，一直保持着该领域的业务的专业与高效，且每一个服务不单在一个项目系统中发挥作用，应在不同项目不同应用中也同样能发挥“统一”、“专业”、“高效”的服务。但相对的，一旦某一服务发生故障，可能同时影响数个系统和应用，因此对服务中心的服务的稳定性、服务能力的扩展性、服务需求的快速响应能力，提出了前所未有的更高的要求。

在服务体系建设中，应积极探索和引用互联网上的新技术、新方案、新管理、新概念，核心推荐采用云计算设计原理，对集团的所有存储资源抽象表示和统一管理，灵活调配来满足单个服务器不能满足的存储要求，满足数据操作对性能，可靠性，安全性和简单性等的要求。采用实现统一的自动管理平台，真正实现低能耗、高效率、自动化的云计算基础平台。

共享服务中心的核心是将业务服务拆分成一个个更小的微服务。通过对多个系统对同一业服务的总结，提炼成统一的规范服务，达到业务复用，帮助建设其他系统项目快速迭代，减少新建系统项目时间，从而达到面向业务的持续运营。

共享服务中心的架构，目的是通过业务拆分来降低系统的复杂性，通过服务共享来提供可重用性，通过服务化来达到业务知识的敏感性，通过统一的数据较好的消除数据交互的屏障。

5.1 分布式服务组成的系统

首先实现业务、数据重构，从各个系统中抽取公共元素，沉淀出共享服务。

数据上，可以采用数据库复制技术，复制是一组技术，用于在数据库间复制和分发数据和数据库对象，然后在数据库间进行同步操作以维持一致性，实施的是数据库读写分离，单表数据如果很大，可以采用分库分表的方式，既同一个表中的不同数据拆分到不同的数据库中，以业务数据为例，可以按业务ID取模拆分成均衡表，实施的是数据库命中分散，这些，提升了数据库的读写能力。

业务上，将大业务分成小业务。比如，读取某个员工的日业务，先读员工表查员工ID，再去各个业务表抓数据，在内存中分组、聚合、排序等，这个消耗很大的操作，可以采用异构索引表的方式，建立员工ID和业务表ID的对应关系。

这些细分的设计便于实现分布式服务，把服务当作组件，服务能够独立部署后，各个系统都将由多个分布式的服务组成，底层调用多个分布式共享服务，当负载超限时，只需要扩展共享服务资源。

5.2 按照业务面而不是技术来划分组织，做有生命的产品而不是项目

共享服务要不断更新完善，能满足不断创建的新业务。

在微服务模式下，开发团队全面负责“微服务”的研发，他们要能了解熟练自己的“微服务”所涉及的业务，持续不断的了解用户的需求，迭代改进服务。这样产品意识与业务能力就紧紧联系在一起。业务中不管是服务中心的建立，还是各服务中心的能力都是一个不断沉淀、不断完善的过程。如果这一共性的功能业务覆盖面比较大，甚至会成立一个新的服务中心时对该业务的服务执行独立的运营。通过业务共建的模式，既能在最快时间内实现业务功能，很好地满足了前端业务方的需求，又能让业务中心人员在共建过程中，对原来不熟悉的业务领域近距离地接触，培养了这些人在该业务领域的专业能力，为该业务能力在持续运营和能力增强提供了很好的人才储备和技术积累。

5.3 智能化服务端点与傻瓜式服务编排

利用友好的运维工具，把微服务的协调统一傻瓜化。

微服务是一种协作式架构风格，无数微服务组成完整的业务流程。在微服务架构下，每个业务分解成多个微小的服务，各服务可由不同团队开发。微服务经过沉淀，发布API给其他微服务或业务。在这中间，业务是感之不到变化的，微服务架构中的服务编排起了还原业务的作用，服务编排的质量決定了业务的稳定和效率。

服务编排的核心能力包括很多，服务路由、RPC、限流降级、容错熔断、安全访问控制、服务注册与发现等等，即灵活，也难调试，所以管理这些复杂的协作服务，需要采用友好的运维工具，搭建统一的监控平台，由服务平台来完成编排，简化分布式服务调用的复杂度。

5.4 自动化运维，系统容错

把部署运维的平台做成“一键式”，方便对业务需求扩展的敏捷响应，便于移植，提高平台可用性和稳定性。

基础设施自动化在过去的几年里取得了巨大的进步。云特别是 AWS（亚马逊云服务） 的进化格外地降低了构建、部署和运行微服务时的复杂度；Docker容器以及进行部署使运维更加安全、方便 ，减少人工操作的错误，减化人工操作的难点等。自动化运维就是把周期性、重复性、规律性的工作都交给工具完成，包括系统维护自动化，巡检自动化和故障处理自动化等。自动化运维依赖于具体的智能管理平台，最终达到提升运维效率的目的。市场上已涌现出大量成熟的商业化工具和开源工具，商业化工具的优势在于有产品团队的服务，响应快，可选择的数据模型较多，开源工具的优势在于无成本，可进行二次开发。

把服务用作组件的一个结果是应用在设计之初就要能容忍技术故障，既可以容忍人工操作错误，又能兼容不同品牌的硬件错误。因为服务随时都可能发生故障，所以能够监测并自动恢复服务尤其重要。微服务的各种监控可提供查询、预警，便于开发团队的排查和解决。

5.5 服务快速演化

紧跟业务需求的脚步，通过服务中心的方式，不断试错、创新。

业务创新如同创业，一旦成功，可以给企业带来超出预期的回报，但也可能有失败的风险。快速跟进的信息化建设，不能只考虑尝试创新带来的影响，权衡利弊，成功了继续优化，失败了立即中止并分析原因。建议组建7人的小团队进行业务试错，一旦业务出现方向性错误时，不管是调整方向还是放弃

该业务，对于集团所需投入的资源都是在可控范围内。

6 结束语

我集团要改变传统的设计思路，积极探索和引用互联网上的新技术、新方案、新管理、新概念，通过构建共享服务中心，对集团的所有存储资源抽象表示和统一管理，灵活调配来满足单个服务器不能满足的存储要求，满足数据操作对性能，可靠性，安全性和简单性等的要求。采用自动化运维监控，建设自动化管理平台。但设计这样的平台，需要掌握数据库相关知识，以及任务调度、平台管控等技术，甚至需要在实际应用中，逐步提升和完善技术。任重而道远，希冀共享服务中心的建设可以更好、更快地帮助整个集团进行业务的构建和业务拓展，为整个集团提供各应用系统的标准化服务，降低运营成本。

参考文献：

[1] 钟华. 企业IT架构转型之道：阿里巴巴中台战略思想与架构实战.

[2] 徐子沛. 大数据.

[3] 李智慧. 大型网站技术架构.

[4] 建立共享服务中心，发挥企业集团规模优势. 博文.

[5] 大数据时代面临的挑战与其应对策略. 博文.

[6] 什么分布式架构？分布式架构如何设计？分布式集群/系统如何设计？如何应对大数据的三大挑战？ 博文.

[7] 微服务编排之道. 博文

[8] 分布式任务编排调度框架设计. 博文

[9] 深度剖析微服务架构的九大特征. 博文

[10] 微服务架构（Microservice Architecture）. 博文

[11] 浅谈服务治理与微服务. 博文

[12] 微服务（Microservice）那点事. 博文

[13] 组件化、模块化、集中式、分布式、服务化、面向服务的架构、微服务架构. 博文

[14] 微服务架构的特点. 博文