3.1.3　技术中台

不管是业务中台还是数据中台，都离不开技术架构的支持。脱离了技术，所有我们谈的业务与数据能力都无从实现。

3.1.3.1　技术演进路线

在谈技术中台时，我们不妨先来看一下技术架构的演进路线。

随着互联网业务的发展，应用的规模不断扩大，常规的企业级垂直应用架构已无法应对，服务式的应用架构以及分布式服务框架势在必行，用户亟须一个治理系统确保架构有条不紊地演进。

从企业架构演变路线来看主要有单一应用架构、垂直应用架构、服务式应用架构和分布式服务架构，目前基本演进到第四阶段，当然国外已经开始研究第五阶段，但是分布式服务框架还有很长的生命周期。

第一阶段：单一应用架构

当使用量不大时，只需一个应用，就可将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架（ORM）是关键。这是企业为了增加效益而开发的应用，这种架构下没有做任何拆分，应用系统很臃肿，维护和版本升级开销非常之大，一旦出问题就是整体的崩溃。但其实现在有很多企业应用系统仍然停留在第一阶段。

第二阶段：垂直应用架构

当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的Web框架（MVC）是关键。

随着企业运维的复杂性的提高，WEB容器、B/S结构出现，企业给予部门或业务开发了许多垂直应用，采用了一些除数据库之外的中间件技术。

在这个阶段很多企业是把应用服务和数据完全隔离，对企业来说有了一定的能力去增加吞吐量。这些垂直应用提升了企业效率，加强了企业管理。但是，各应用中存在重复的业务功能和代码，甚至在一个应用中也会存在冗余的代码逻辑，应用系统依然很臃肿，业务逻辑处理和界面交互的代码还是堆放在一起，维护和版本升级开销都很大，稳定性不够理想。

这是企业架构的第二个阶段——垂直应用架构。

但是当垂直应用越来越多，应用之间交互不可避免，这个时候企业面临着进行业务融合，数据打通的问题，因此催生了面向服务架构（SOA），用以解决企业应用、业务调整和数据共享的问题。服务式应用架构阶段将核心业务抽取出来作为独立的可以复用的服务，使前端应用能更快速地响应多变的市场需求。

但是各应用中存在许多重复的业务功能和代码，甚至在一个应用中也会存在冗余的代码逻辑，应用系统很臃肿，业务逻辑处理和界面交互的代码放在一起，在信息化的维护和版本的升级层面开销都很大，稳定性不够理想。

第三阶段：服务式应用架构

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来作为独立的可以复用的服务，使前端应用能更快速地响应多变的市场需求。此时RPC技术是关键。

在服务式应用框架中，把冗余的代码和可以服用的业务应用进行拆分提取，封装成服务。这样系统架构更加清晰，代码质量提高，利于升级和维护，稳定性高。应用层可以更专注在与前端用户如何交互，业务处理放在服务层来进行，服务和应用的管理不是自动化，服务层能够实现HA的功能。

但是，在服务式应用的阶段，仍然存在实施过程只站在局部业务，单个项目角度考虑的问题，缺乏全局思维，业务系统之间更多的是交换，而缺乏共享和协同。

第四阶段：分布式应用架构

第四阶段能够监控原来看不到的服务状态，把分布式服务架构做到自动化注册和解析的过程当中。在这个过程中，企业横向扩展变得越来越灵活，这也是很多互联网公司在高峰期能支撑那么多订单量的原因。

当服务越来越多，容量的评估，小服务资源的浪费问题逐渐展现，此时需要增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高设施利用率的资源调度和治理中心（SOA）是关键。基于服务式应用架构基础上，引入服务注册中心，用于保存服务列表，实现自动化服务体系框架。

分布式服务架构的优势：

首先，分布式架构，应用层和服务层可根据需求进行动态水平扩展，应用与服务实现负载均衡，通过随机、轮询、权重等策略。

其次，开放式、标准化的框架，满足接口调用的服务都可以接入服务框架（RPC）。

最后，监控服务调用情况，可进一步对服务层再分层，根据业务需求和对服务运行情况对服务进行编排和梳理，以及服务治理。

3.1.3.2　技术中台架构支撑

我们看到，随着互联网业务的发展，应用的规模不断扩大，常规的企业级垂直应用架构已经无法应对，服务式的应用架构以及分布式服务框架势在必行，用户亟须一个治理系统确保架构有条不紊地演进。企业必然走向互联网的分布式服务和架构，而这套架构已经在多个行业中遍地开花，这是互联网技术的红利在慢慢向企业赋能的表现。

分布式服务架构解决的核心问题就是服务调用，未来企业新增加一项业务或服务，通过整个服务中心可以很好地对外发布，调用者可以迅速地完成相应的调用，整个过程变得非常敏捷。这也是为什么很多互联网公司能够快速地适应业务的变化，能够做敏捷的交互的原因，因为拆分得很细。如果哪一个服务出现不好的问题，可以做服务的升降级，可以做平滑的切换，系统应用整体感受会有很大提升。

通过分布式架构，一方面是在解决业务支撑能力的问题，另一方面，实现真正地去中心化系统实现系统的弹性，降低耦合性，突破系统“瓶颈”，提升灵活性，以便使业务能够不受技术能力的约束实现快速创新，从而形成“技术拓展商业边界”的能力。

数据中台要求可以对数据进行海量的数据化运算，海量的数据化处理和分析，对于传统的系统架构来说，很难满足海量的采集、计算、存储等一系列的大数据操作。另外，在数据的基础上，还需要对数据进行数据模型、算法服务、数据产品、数据管理。这些数据跟业务中台具有很强的关联性。所以为了满足数据中台的实时、在线、高效地数据化处理和运营分析，对于技术架构提出了分布式、高并发等大数据的处理要求。

所以说，技术中台是能力支撑。通过分布式服务架构来实现，解决传统烟囱式的问题。在中台设计的过程中，技术是核心的一环。而我们现在谈的中台，在技术能力上，有着异于传统的改变。

这种改变在技术中台上还表现为技术架构要超前于现有业务。业务布局在现时变化太快，但系统不能实时跟随变化。从技术架构上要支持中台的业务沉淀和服务复用，实现前台业务的快速组合和低成本创新。

3.1.3.3　技术中台能力

以百胜软件的企业中台为例，我们可以看到，百胜软件的中台技术架构可以分为四层：资源层、公共服务层、应用层和用户访问层。聚焦于公共服务层来看，将开源的、基础的能力封装成核心技术层；在技术层之上是与行业无关的核心业务，因为每个行业都会有订单、库存、营销等业务，封装起来形成核心业务层；在业务层之上还有一些服务，我们给它赋予行业的属性，形成了行业层服务，针对鞋服、珠宝、日化等行业都有相关的服务。这样的分层体系相对来说比较清晰，具备较强的专业度，同时能够聚焦不同行业。

百胜软件中台技术架构为了满足业务发展还具备以下特性：

分布式服务架构：当服务越来越多，容量的评估，服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高设施利用率的资源调度和治理中心（SOA）是关键。

基于服务式应用架构基础上，引入服务注册中心，用于保存服务列表；实现自动化服务体系框架。

分布式架构，应用层和服务层可根据需求进行动态水平扩展，应用与服务实现负载均衡，通过随机、轮询、权重等策略。

开放式、标准化的框架，满足接口调用的服务都可以接入服务框架（RPC）。

监控服务调用情况，可进一步对服务层再分层，根据业务需求和对服务运行情况对服务进行编排和梳理，以及服务治理。

分布式服务管理：通过分布式服务管理，统一了RPC调用框架，从技术上让开发人员提升开发效率，保障我们的开发质量。

服务监控管理：有了自动化的服务治理之后，就可以对服务进行有效的监控，这样很容易发现哪些服务是存在并发压力的，哪些服务会容易产生故障，哪些服务可能耗时比较长，存在系统“瓶颈”。更深入地，我们可以把服务监控到在哪个时间段，针对哪个物理区域的服务器。到最后我们还可以针对某一个单台服务，监控它的整体资源的情况。

异步解耦：同时我们还利用互联网的技术去解决平常业务中的一些痛点。传统软件有一个很大的痛点是业务操作都是同步的，同步之后容易形成堵塞，往往容易形成系统的崩溃，我们通过基于MQ的消息机制，把同步的机制解耦变成异步机制，保障在电商活动期间，当海量订单红利来的时候，可以缓冲订单红利，避免系统崩溃。

一对多，多对多异步解耦：基于发布订阅模型，分布式应用异步解耦，可以增加应用的水平扩展性，增加前端应用快速客户反应能力。

削峰场景：大促等流量洪流突然来袭时，MQ可以缓冲突发流量，避免整个系统崩溃。

日志监控：作为重要日志的监控通信管道，将应用日志监控对系统性能影响降到最低。

数据缓存：我们通过像Redis这样的缓存机制减少数据库的压力，通过内存计算提高计算效率，我们还可以通过MQ消息机制实现事务补偿，同时我们通过一些集群技术去增加系统健壮性。这里有一个很经典的场景，即大促活动（例如“双11”）这时候有海量的订单进入，而大量的订单处理都要去访问数据库库存这张表，要进行频繁的访问并交互，数据库的压力是显而易见的，很容易导致数据库压力传导到系统上，导致系统卡顿，变得特别慢或者崩溃，而像“双11”时期系统卡顿对业务造成的伤害是很大的。现在如果品牌几百万订单可能还可以接受，但是到千万订单的时候，现在的机制肯定解决不了，就需要这种新的机制，所以未来只有这样一种数据缓存的机制能解决这个痛点。

库存缓存：通过缓存减少数据库读写压力，通过内存计算提高计算效率。

消息推送：MQ异步处理数据库库存增量变更，实现事务补偿，解决数据一致性问题。

集群部署：缓存集群部署，和数据库读写分离；增加系统健壮性。

数据库水平拆分：单表的业务容量到千万级或者更高的时候，就需要对表进行拆分，因为单表已经支撑不了，整个访问会导致它的数据衰减很快。现在有一些工具能帮我们进行这样的水平拆分，当然具体拆分还要跟我们的业务规则结合。

技术开放共享：对于企业中台来说，由于涉及面广，百胜软件的中台技术未来是能给其合作伙伴开放共享的，通过这样一个体系，未来能够跟品牌、平台与合作伙伴共享，一起推动中台发展，发挥各自的力量，不断优化完善企业中台。