| 编辑推荐: |
主要讲解了企业为什么要建设中台，不适合建设中台的企业，如何建设企业的中台，企业中台的建设方案等相关内容。
来自于大数据csdn,由火龙果软件Anna编辑、推荐。 |
|
一、引言
近期阅读了钟华的有关阿里巴巴中台战略的资料，阿里中台战略中的共享服务的实践对自己有非常大的启发。结合多年建设IT系统的经验，以及目前国内众多企业建设中台的需求，谈一下自己对企业建设中台的思路和建议，供大家参考。
二、企业为什么要建设中台 （1）何谓企业中台？ 企业中台是指为企业前端业务应用提供共享服务的平台，该平台可以快速的响应企业业务需求，支撑企业业务的运营和创利。 （2）建设中台的意义？ 企业的中台可以避免以往烟囱式的系统建设模式，降低IT系统建设以及系统间交互成本，能快速响应前端的业务需求，同时实现持续的业务沉淀，形成企业的核心资产，推动企业业务创新。 （3）建设中台必要性 若企业的业务种类多，而且随着近年来互联网的冲击，客户对企业业务的个性化需求增多，时效性要求高，这种情况下，企业建设中台是有必要，因为只有中台才能有效快速的满足客户的个性化需求。
三、不适合建设中台的企业 企业中台的建设源于互联网业务的驱动。互联网业务具有用户众多，个性化需求多，需求变化快等特点，企业建设中台最初目的是为了适应互联网业务的特点，使自己具备快速的响应客户需求，提供符合用户需求的产品能力。 企业中台的服务中心具备快速开发和部署能力，因此能快速响应客户需求；且中台按需服务特征，能持续为前端应用提供服务，可以不断的进行业务沉淀，反过来驱动中台能提供稳定优质的服务，同时中台的业务沉淀能力也提升了企业新业务的试错能力，极大促进了新业务的创新。 近年来阿里等国内大型互联网巨头建设中台后服务质量有了明显的改善，同时也促进了其业务发展。在这种情况下，国内互联网公司以及一些传统行业的公司趋之若鹜的开始建设各自的中台。 由于中台的服务中心众多，而且相对独立分散，由此也会给中台服务的开发运营带来技术困难和维护成本，如分布式数据库事务管理，服务故障的定位，以及服务链能力优化等困难，这就要求企业不仅有良好的业务能力，还需要有较好的IT技术储备。 鉴于上面的分析，笔者认为并不是所有企业都适合建设中台。假如企业的业务相对比较单一，且企业运营的目标是提升管理效率，降低管理成本，这种企业没有必要建设中台。另外，企业运营管理通常划分为两部分，一部分是运营目标是快速响应客户需求，为客户提供符合需求的产品，这部分业务运营需要建设中台；另一部分的运营目标是实现管理的降本增效，用户的需求相对稳定，这部分就是通常所说的企业后台，不需要建设中台。?
四、如何建设企业的中台
1、明确建设中台的目的 企业建设中台的目的就是快速响应客户业务需求，并且随着业务发展具备便捷的业务扩展能力；使企业拥有持续的业务沉淀能力，为企业新业务的创新提供支撑。
2、建立中台开发运营团队 中台的建设与以往IT系统建设模式完全不同。传统的IT系统是按照项目模式建设，企业只是系统建设的项目管理方，保证项目按期验收交付；系统交付后由开发商负责维护。而中台采用的是“按需服务（Service
on Demond）”的建设模式，即在中台框架搭建完成后，前端应用方提出业务需求，由业务专家分析梳理需求后，业务架构师和开发人员需快速设计、开发、部署相应的服务，及时的响应前端的业务需求；前端又有新的业务需求，再次以同样的方式快速的进行分析、设计、开发和部署服务，快速满足前端的业务需求。中台就是按照这种模式持续的响应前端应用需求，快速提供满足需求的服务。 中台的“按需服务”的建设模式，决定了建设中台运营团队的组织结构。中台运营团队按照中台服务中心进行布阵，团队成员由负责运营中台的企业信息中心管理人员和开发维护人员组成，团队也包括中台承建方的业务架构设计师，需求分析师和开发人员。
3、调研业务及其支撑需求
中台承建方的需求分析师和业务架构师在制定中台建设计划前必须详细调研企业业务和IT环境，调研的内容包括：业务流程及其IT支撑需求，遗留业务支撑系统、后台管理系统，以及企业的IT基础设施等。另外，在调研过程中，企业的信息中心业务专家和维护人员务必参加。
4、提出企业中台建设计划
在调研企业业务及其支撑环境的基础上，提出建设中台的计划和初步的方案。经企业方认可后，方可开始实施企业中台的建设。
5、企业中台的建设方案 企业中台的软件架构主要由共享服务中心和服务化基础设施组成，共享服务中心响应前端应用的业务需求，提供服务支撑企业的业务运营；服务化基础设施支撑共享服务中心快速的响应业务需求，为前端应用提供稳定优质的服务。
（1）中台共享服务中心 中台服务中心就是为前端应用提供服务的功能实体，具备快速响应前端应用需求，按需求提供服务的能力。中台的共享服务中心，不仅能满足当前业务应用的需求，还具备伴随业务发展持续提供服务的能力。 开发中台服务中心的前提条件是准确的划分服务中心。服务中心是以业务流程为界，每一个服务中心都有完整的业务流程和独立的业务数据。中台建设初期，一个共享服务中心是一个微服务，具有微服务的快速迭代开发独立部署的敏捷性，能快速响应前端应用的需求；将来随着业务的不断沉淀，可能一个服务中心包括多个这样的微服务，通过服务的柔性编排提供场景式或平台式的服务，见后面《五、企业中台与微服务架构》。 建议服务中心构建在Docker Tomcat容器上，采用私有云或X86虚拟服务器的集群方式实现均衡负载。另外，在划分服务中心时，不仅考虑业务维度，还得考虑服务的运营和维护的成本，见后面《中台服务中心划分原则》。
（2）中台服务化基础设施 中台服务化基础设施是指建立服务的开发、维护、治理和运营环境和工具，让中台的服务中心能快速响应前端业务需求，提供稳定高效的服务。 中台的基础设施主要包括：服务的元数据、服务注册与发现、服务访问控制和安全策略、服务依赖与运维管理、应用服务门户、服务调用分析报表，以及分布式事务管理、限流和降级管理等，这些基础设施均是建立在Docker
Tomcat容器、MQ消息中间件和分布式数据库等之上。
企业中台基础设施是建立在企业现有的IT设施基础上的。若企业有私有云，在企业的私有云上构建中台基础设施；若企业没有私有云，建议在X86服务器上构建中台的基础设施，当然也可以在阿里等公共云上构建中台基础设施。
五、建设企业中台的一些建议
1、建立完备的中台基础设施框架 与传统的单体系统不同，中台众多的服务中心是相互独立部署的服务实体，别人只有发现了你的服务才能享受你提供的服务；有了服务的访问控制才能有效避免恶意访问造成服务的破坏；只有实时的跟踪服务调用链路才能准确定位服务故障；只有具备了服务的限流和降级才能保证提供稳定的服务；因此只有建立了完备的中台基础设施，中台的服务中心才能有效的提供服务。 中台的基础设施是在中间件平台或工具上开发形成的，基础设施主要由如下几个部分构成：
（1）服务元数据 服务元数据是指对服务的属性、操作和组件的描述信息。整个中台必须有统一标准的服务元数据，需要制定规范。在中台的都是依据这些服务的元数据实现服务注册、发现、维护和运营等功能。
（2）服务注册与发现 服务注册于发现是指服务提供者可以通过在中台注册服务，服务消费者通过订阅发现这个服务，并能调用这个服务满足业务应用的需求。
服务注册流程 具体流程：启动容器中的新服务后，该服务从地址服务器中查找配置服务器地址，然后向配置服务器注册服务（服务接口类名、服务版本、所属服务组等，以及服务实例所在服务器IP地址、服务端口号等），配置服务器形成该服务列表（同一服务多个实例），并且向调用该服务的服务消费者节点推送服务列表。
服务发现流程 具体流程：服务调用（消费）者通过服务访问控制服务器的安全认证，访问地址服务器获取配置服务器地址，向配置服务器订阅服务（服务接口全名、服务版本、所属服务组），配置服务将“服务接口全名+服务版本”进行匹配查找服务注册信息，一旦获得服务注册信息，配置服务器将注册服务组IP地址和端口号列表返回给服务调用者。
地址服务器 在上述服务注册和发现流程中，地址服务器保存配置服务器和规则服务器的地址，一般由Ngnix（高性能HTTP和反向代理服务器）提供服务能力。
配置服务器 在上述的服务注册和发现流程中，配置服务器是保存着服务注册列表信息。为了及时更新和读取服务列表信息，配置服务器采用内存存储方式保留服务列表信息。建议采用多台配置服务器进行负载均衡，并进行实时同步保证服务注册和订阅列表的一致性。
（3）服务访问控制和安全策略 在中台一般采用如下规则进行服务的访问控制和安全策略：
通过白名单方式，设置某些服务或服务中心的方法只能让特定IP地址的服务器调用。
通过用户认证的方式控制服务是否能被调用。
设置不同的服务器的权重，以控制服务调用者对多个服务提供者服务节点的访问。
设置某些服务的QPS能力上限，一旦该服务的QPS达到该阈值，则拒绝服务的继续调用。 中台的运营维护人员在规则服务器上设置这些访问控制规则和安全策略，同时将其推送到各个服务节点，实现服务的访问控制。
规则服务器 规则服务器承担了服务调用过程中对于服务调用安全管控的规则、服务路由权重、服务QPS阈值等配置规则的制定和保存（持久化到MySQL)。规则服务器可以提供规则设置界面（Google
Blockly），对制定服务的服务提供者和调用者设置相关的规则，一旦保存规则，则此规则配置将会在5秒钟内推送到与所设置服务相关的服务节点上。在生产环境中，一般会设置多台规则服务器提供均衡负载服务。
（4）服务依赖与运营管理 服务依赖管理是指中台具备跟踪服务调用链路的能力，即能查看一个请求经过的所有服务节点，能查看这个服务调用链路的处理时长以及每一个节点处理耗时、数据量大小，以及调用结果等。服务运营管理是在服务调用链路跟踪的基础上，定位和诊断服务故障，通知运维人员。
埋点日志管理 实现服务依赖与运营管理的核心是每个服务的埋点日志管理。埋点日志实现服务交互过程中记录服务调用和各种资源访问的日志，并传递SLID（服务链路ID，由服务请求端IP、服务请求创建时间、服务请求顺序自动生成)等功能，埋点日志程序一般植入到服务交互的框架中，在服务交互过程中可以调用埋点日志打印调用的日志信息，并向下一个调用传递SLID。每一个服务请求都会生成唯一的服务链路SLID，这个SLID会贯穿服务链路的每一个服务调用，另外在服务调用过程中还会生成服务调用顺序ID（SSID），最终服务链路靠SLID和SSID服务链路串起服务链路并对其进行跟踪。 埋点日志信息包括：SLID、SSID、开始时间、调用类型、调用端IP，处理耗时、处理结果代码、请求和响应的数据传输量等。每一个服务节点都植入了埋点日志代理程序，负责将日志信息推送到日志分析平台。
日志分析平台 每一个服务节点都有埋点日志代理程序，该代理程序负责将日志信息推送到日志分析平台。在日志分析平台上对日志信息进行实时的解析和定期汇总，统计分析每一个服务调用链路的性能数据。当服务出现故障，可以及时的定位故障点，向平台人员发出告警信息。在生产环境中，一般设置多台日志平台服务器提供均衡负载服务。
（5）应用服务门户
应用服务门户为中台提供统一的Web界面，让服务提供者注册服务，让服务消费者订阅服务，让平台的开发和维护人员运营平台。
（6）服务链路分析报表 服务调用链路分析报表按照一定时间对服务调用数据进行统计和分析，用于优化服务性能，使服务消费者更快获取自己所需的服务。服务调用分析报表至少包括如下内容：服务调用链各服务的嵌套调用层级关系，服务调用链中所调用的服务方法、服务以及服务所属应用、不同服务类型操作，各个服务请求平均QPS值和该时间段内的峰值，同一个服务调用的次数、各个服务调用的平均耗时以及本地耗时（不考虑传输），服务链路中依赖的强弱等。 在生产环境中，一般设置多台服务链路分析平台服务器将提供均衡负载服务。
（7）分布式事务管理机制 在中台，每一个服务中心都拥有自己独立的数据库，为了提升数据库读写性能会采用读写分库和分库分表存储数据，形成了分布式数据库。众所周知，数据库性能和吞吐率的瓶颈是强事务带来的资源锁，对于分布式数据库而言，其事务管理就更加困难。 传统的分布式数据库事务管理采用两阶段提交实现分布式事务（第一阶段准备、第二阶段提交，只要有一个数据库没准备好事务回滚）。建议中台的分布式数据库事务管理不采用传统的分布式数据库事务管理，采用最终一致的分布式数据库柔性事务管理，即不同数据库之间数据一致性可以有延迟，但数据最终会保持一致。分布式数据库柔性事务管理有两种模式：
乐观锁 乐观锁是基于数据版本记录机制实现的，在事务开始前获取到该数据记录的版本号，在事务处理最后对数据记录更新Update时与之前获取的版本号对比，若版本号一致，则更新数据成功，然后修改改数据的新的版本号，如果笨笨号不一致，则表示数据已经被其它事物修改了，则重试或放弃当前事务。乐观锁还基于系统中数据存储逻辑，据有局限性，假如一个应用采用乐观锁，另一个应用不采用可能会造成脏数据。在中台，若采用乐观锁务，务必放在服务中心，统一对数据库进行操作，以避免事务异常引起脏数据。
消息分布式事务 消息分布式事务是基于MQ的事务消息功能达到分布式事务的最终一致。具体流程如下，事务发起方执行第一个本地事务前，会向MQ服务端发送一条事务消息（不同于普通消息），事务消息在MQ服务端处于正在执行状态，MQ订阅方无法感知该消息；发起方开始对第一个数据库进行事务操作，当本地执行成功后，发送提交消息，MQ服务端消息状态变更为已提交，消息订阅方通过消息里的事物和业务信息执行第二个数据库的本地事务，第二个本地事务成功，则最终实现两个不同数据库上的事务成功，若第二个失败，重试（正向补差）或人工干预完成事务，或可通过消息通知发起方，对第一个本地事务进行回滚（很少执行）。假如MQ服务端一段时间（如5分钟）未收到发起端事务执行结果，服务端会发一个请求到发起端确认第一个事务是否成功，若不成功，抛弃事务消息；若成功，改变事务消息状态，第二个事务开始执行。
分布式事务管理平台 上述的消息分布式事务都是在中台的分布式事务管理平台上实现的。在生产环境中需要设置多台分布式事务管理平台服务器，将提供均衡负载服务。 （8）服务限流降级机制 当在特定时段前端应用对中台服务请求飙升，影响到中台对用户请求的正常响应时，中台需要采用限流和降级措施，以保证中台能提供稳定的服务。
限流措施 服务限流是指当业务请求超出服务的处理能力时，中台会掐掉一部分请求，以保证该服务能正常处理其它业务请求。衡量服务的处理能力关键指标是QPS，也是限流判断的关键指标。
降级措施 服务降级是指当某个核心服务依赖于一个非核心服务，这个非核心服务的响应时间过长，导致核心服务的处理性能出现瓶颈，核心服务将会关闭与这个非核心业务的依赖，以保证核心服务的正常处理能力。降级判断的关键指标是服务的响应时间。
限流降级平台 通过限流平台实现限流和降级功能。限流平台由控制台和客户端组成，控制台设置限流指标（QPS）和降级指标（响应时间）的阈值以及服务的强弱依赖关系，通过规则服务器将阈值推送到服务节点，同时控制台实时采集埋点日志，并将服务节点的QPS和响应时间等性能数据推送给客户端；客户端依据收到的服务节点实时性能数据，对比性能指标阈值，再看是否采取限流或降级的措施。在生产环境中需要设置多台限流降级平台服务器，将提供均衡负载服务。
（9）服务流量调度机制 在云平台上，为了提升机器的资源利用率，采用超配的方式配置机器，即一台物理机上创建的虚拟机CPU核数的总和会超过物理机实际的CPU核数。云平台的超配必然会导致一个问题就是资源争抢，尤其是当个别或局部应用出现服务器响应慢或挂起，将资源的争抢最终会影响整个业务链。为了避免这种单机或局部故障带来大面积的业务故障，有效的措施是发现服务器负载飙升，即可下线该服务器。流量调度平台就是为此建立的。
服务流量调度 流量调度机制的核心是实时采集服务器（服务实例）运行指标和业务指标，与流量调度平台事先设置的流量调度阈值进行对比，发现服务器的指标超出阈值，对服务器进行流量调整或下线操作。
流量调度平台 流量调度平台通过服务器对外的指标信息接口采集指标数据，这些指标包括：CPU占用率、系统负荷（进程队列）、服务调用响应时间、QPS、线程池占用率等。 中台维护人员可以在流量调度平台上设置运行指标和业务指标的阈值。流量调度平台会实时对比采集到的性能指标，当发现指标数超出阈值，立刻通知配置服务器，配置服务器将调整服务提供者（服务器）列表中服务调用权重，服务调用者按照权重调用服务，以控制服务器被服务请求的流量大小。当服务器资源负载飙高时，降低该服务器的服务路由权重，直至降为零，最终实现通过流量隔离服务器故障。在生产环境中需要设置多台服务流量调度平台服务器，提供均衡负载服务。
2、准确的划分中台服务中心
企业中台由共享的服务中心和服务基础设施组成，如上所述，服务基础设施是为服务中心提供服务的，因此服务中心的构建是建设中台的核心。构建服务中心的前提是从企业的业务领域准确的划分出服务中心，这个服务中心既要满足现在前端应用的需求，也要考虑适合未来业务的发展，使服务中心能持续提供稳定高效的服务。
（1） 服务中心主要特征
具有业务的完整性 业务完整性是指服务中心具有能完成明确业务目标的端到端的业务流程，只有服务中心的业务具备了完整性，才能具备独立开发、独立部署的敏捷特征，才能具备快速响应前端应用需求能力。
具有数据的独立性 由于服务中心业务的完整性决定了其数据的相对独立。数据独立性是指服务中心进行业务数据的变更和存储，不会影响到其他服务中心业务数据的一致性，也是服务中心独立开发独立部署的敏捷性的体现。
具有多种服务的形态 一个服务中心可以包含多个服务节点提供多种形态的服务。除了有依赖于API接口的形式外，有依赖于工具的服务，如配置业务流程、配置业务规则等服务；还有依赖于数据的接口，提供统计分析数据的服务。
服务中心由子模块组成 服务中心由子模块组成，这些子模块是从业务功能和系统设计层面考虑，能更有效的实现服务中心的业务功能，以及服务中心业务功能的运行维护。
（2）服务中心划分维度 服务中心的划分应该兼顾三个维度的需求，一是设计，服务中心应该遵循面向对象的分析和设计理念和方法，实现系统灵活的扩展性；二是运营，服务中心应该是一个完整的业务模型（有完整的业务流程），还应该有数据运营和业务整合的价值，也就是将来服务中心的数据应能形成为企业带来价值的资产，而且随着业务发展，服务中心可以不断的整合和沉淀业务，为前端应用提供稳定优质的服务；三是工程，中台由分布式的服务中心组成，必然会带来分布式管理的开发和维护成本，如分布式数据库事务管理、服务调用问题定位等，因此在考虑前端应用对服务中心的需求时，也应该考虑技术、开发、维护上的投入成本。
（3）服务中心划分原则 从兼顾设计、运营、工程的需求去划分服务中心，形成如下划分规则： 高内聚低耦合原则 高内聚低耦合是面向对象设计的基本原则。按照业务维度划分服务中心，就是考虑服务中心的业务完整性，这样形成的服务中心内部必然是高内聚，服务中心之间必然是低耦合。在考虑高内聚和低耦合的原则同时，还应该考虑运营和工程因素，有些业务之间隔离性虽然较大，业务量比较小，可以将其与业务量大的业务（业务隔离性相对较小）合并成一个服务中心。将来随着业务量增大在独立构成服务中心。
数据的完整性原则 服务中心的数据应该独立完整的，其等同于业务的完整性。服务中心的数据完整性有两个方面的考虑，一是服务中心具有独立完整的存储数据的能力，以支撑服务中心内的业务流程；二是服务中心的业务沉淀形成的业务价值体现在业务数据上，数据必须完整才能形成相应的业务价值，借大数据分析支持企业的业务创新。
业务可运营性原则 服务中心的可运营性体现在两个方面，一是，服务中心不仅可以支撑现有的企业业务应用，而且随着业务沉淀能稳定持续支撑业务应用；二是，随着业务不断沉淀和服务中心数据的运营（大数据分析）能孕育出新的业务，为企业创造价值。
渐进性的建设原则 企业中台架构就是一个敏捷的最佳实现。中台是通过快速迭代不断改进的逐步建设的，这样不仅快速满足业务应用的需求提供服务，同时通过不断沉淀业务，提升服务能力稳定性，必然会降低中台的开发维护的成本和建设风险。在建设初期，可以粗粒度划分服务中心，快速的满足现有业务应用的需求，随着业务发展和对业务认知加深（业务沉淀），逐步精确划分服务中心，最终具备提供稳定优质服务的服务中心。
（4）服务中心与事件编排 企业中台架构中，建议跨服务中心的业务流程采用事件编排模式。在中台的服务中心划分时，已经将核心的相对短的业务流程纳入到服务中心，而针对一些跨服务中心的长流程，建议采用事件协作方式，即业务流程中的涉及的各个服务中心在完成任务后是必须发出事件，其它服务中心订阅事件并执行流程后续任务，服务中心也负责将事件转化为执行任务的命令。当业务流程需要调整时，只需相应的服务中心改变订阅，重启进而实现流程的改变。 通过事件编排，可以最大限度的实现业务流程中各个服务中心间的解耦，保证每一个服务中心开发部署的敏捷性，不失服务中心快速响应前端应用需求的特征。
3、开发中台服务中心功能
根据中台服务中心业务和数据完整性和独立性，以及可运营性的要求，服务中心至少包含如下功能：
（1）实现完整的业务流程 在中台，服务中心是一个独立运营的业务单元，必须具有完整的业务流程，包括端到端的业务流程流转，以及流程环节对业务数据的处理和存储，因此一个业务流程对应一个服务中心。 业务流程服务中心应能响应前端应用流程操作请求能力，前端应用查看流程状态和流转详细信息能力，具备在流程出现超时或异常，能发出流程违例预警信息的能力；服务中心也应具备设置流程引擎的能力，提供优化业务流程的能力。 建议在规则服务器中设置流程异常的违例预警阈值，设置完成后，规则服务器将阈值实时推送到业务流程服务中心。 对于一些大型的企业，如中国移动，业务流程流转范围广，部分业务流程的一些环节会在企业后台的系统中，这种情况下需要建立业务流程接口中心，具备向后台系统推送流程流转数据能力，同时从后台接收流程流转数据的能力，而且必须具备数据完整性和一致性的验证，以及接口数据异常的预警能力。
（2）建立独立的业务数据 独立的业务数据是指服务中心的业务数据必须具备完整性和独立性，数据的完整性是建立在业务完整性的基础之上，除此之外还得保证数据相对独立，也就是服务中心的业务数据可以独立维护和存储不会影响其他服务中心，也就是不会出现脏数据，如在投诉与故障工单服务中心，故障工单在服务中心流转时形成的工单数据变更不会影响到故障服务中心提供的故障告警信息准确性和及时性。 对于一些大型的企业，部分业务流程涉及部门范围广，服务中心的业务流程的一些环节会在企业后台系统中流转，建议上述的业务流程接口中心从后台系统获取到流程的流转数据后，通过MQ方式方式推送到相应的服务中心，服务中心处理后入库，以保证业务数据的完整性和独立性。??????
（3）具备基础设施服务接口能力 中台的基础设施是各个服务中心提供稳定优质服务的前提条件，因此每一服务中心需要具备与基础设施服务交互的接口，以及相应的客户端程序或代理程序（见上述《中台服务化基础设施》），以支撑中台对服务中心的运营管理。
六、企业中台与微服务架构
企业中台共享服务架构就是微服务架构。每一个服务中心有高内聚低耦合的特征，独立的存储，服务中心之间通过调用API实现交互，具备独立开发独立部署特征，且中台具备为支持服务中心提供服务的基础设施，因此中台服务中心就是一个微服务。 在网上流行的微服务概念中，强调微服务代码量小。之所以强调代码量小是在表明一个微服务应该与企业的敏捷团队相匹配，避免大代码库引起的开发和部署问题。在这一点上中台的服务中心与微服务也没有本质上的区别。服务中心由单独的团队负责开发，可以实现两周内完成服务中心功能的优化和部署。 微服务具有很好的弹性，也是一个微服务实例出现不可用，不会影响到其他微服务。中台的服务中心也具备很好的弹性，服务中心独立开发部署，服务中心之间通过调用API实现交互，因此一个服务中心实例出现不可用，不会影响到其他服务中心，而且服务中心实例部署在集群上提供均衡负载，一个服务中心的实例出现不可用不会影响整个服务中心的正常运行。 微服务具有很好的扩展性，微服务的独立性使其能部署多个实例，扩展性强。中台的服务中心也可以在集群上部署多个实例，而且可以根据服务负载情况，灵活的删减实例数量，有较强的扩张性。 微服务具有组合性，可以根据服务的需求，组合不同的微服务提供相应的服务。中台架构中的服务中心也具有较强的组合性，随着企业业务发展，当出现跨服务中心的业务场景需求时，通过柔性编排组合服务中心，提供业务场景式的组合服务。 在中台的共享服务架构中，拥有微服务架构理念中的基础设施，如服务注册、服务发现、分布式事务管理、服务链路跟踪、限流降级，以及熔断（中台的流量调度）等基础设施功能。
七、企业中台与组织结构
企业的中台是按照共享服务模式响应前台应用的需求，也就是根据前台应用的需求持续进行开发优化服务，不断的提供稳定优质的服务，这种按需服务的模式彻底颠覆了企业按项目建设IT系统的模式，必然促使企业组织阵型发生改变，带来组织效能的提升。 （1）企业的信息中心 在企业建设中台过程中，企业信息中心必须改变原有按项目组织的阵型，建立适应中台建设的需求的与服务中心相匹配的组织阵型。 在过去“烟囱式”的系统建设模式中，信息中心的职能是“业务支持”，每一个系统从立项到项目验收，信息中心都是项目的甲方，负责协调各方推进项目实施，最终按期验收，新的项目立项，再重新开始项目管理工作，周而复始的进行项目的管理。信息中心“业务支持”角色没有发挥出对企业业务发展和创新应用的价值。 在企业中台共享服务的建设中，项目的建设模式发生彻底改变，项目是基于共享服务体系的建设，不再是一个一个建设新项目，而是持续运营服务，不断提供满足业务需求的服务，因而在项目的周期和资源的投入上的效率上有了大幅度的提升。相应的信息中心的组织阵型必须围绕按需服务模式进行调整，按照每一个服务中心建立相应的运营团队，使信息中心的角色从“业务支持”转变为“业务运营”。通过对中台持续服务运营，信息中心具备了直接为企业创造价值能力。这样信息中心人员也不再单单是项目经理的角色，他们可以在一个业务上持续理解和沉淀，成为业务专家，为企业的业务创新的贡献自己的价值。
（2）第三方开发集成商
企业中台的建设会迫使第三方开发集成商的服务形式发生转变。随着中台的建立，开发集成商会从过去项目建设、验收、维护的模式变为持续提供服务开发的模式。中台的共享服务的建设模式，要求第三方公司从项目中标开始，必须具备快速的响应业务的需求能力，具备持续不断的提供和改进服务的能力，企业将会按照开发集成商提供的服务质量计价。这种模式有点像中国移动的代维公司，但中台服务的开发涉及到企业的核心数据，因此企业与第三方开发集成公司的关系会比代维公司更加紧密。
|
