随着数字化和互联网时代的来临，云计算、大数据、微服务、物联网、移动互联等各种新兴技术为IT产业带来无限机遇的同时，也为企业业务不断发展带来支撑，伴随着企业规模不断扩大、业务多元化、创新化的发展，“大中台、小前台”的技术架构模式出现，由于公司的发展要求，笔者经常接触大中台这一理念，结合公司主打SOA集成平台、数据治理等产品和方案，在学习过程中有自己一些的理解，本文主要与大家分享笔者的认知，希望能够对有需要的朋友们提供参考和帮助。

1. 定义阐述

       中台概念出现之前，在信息化模式上，前端为支撑业务的应用端，后端为各个应用系统，为前端用户，如：客户、供应商、伙伴、社会提供服务，但随着市场、用户需求、业务的多变性，底层僵硬的应用无法及时提供支撑。企业需要一个强大的中间层为高频多变的业务提供支撑，为不同的受众用户提供多端访问渠道，基于此类需求“中台”概念出现，不过凑巧是阿里提出，接着开始对企业客户、中间件厂商、数据平台厂商、甚至传统应用软件厂商都有较大的概念冲击。恰逢此时，微服务技术和架构、容器化的生态、Devops概念和工具处于大发展的阶段，然后基于“大中台、小前台”的信息化建设模式开始流行。

1.1 概念产生

        对于大中台来讲，现在并没有十分严格的定义，每个企业对其的理解都是不同的，有的在技术上使用大中台模式，有的在业务上使用大中台模式，有的将两者相结合。“大中台，小前台”的机制最初阿里提出的时候，主要应用于O2O线上线下协同、电商等场景，对于电商来说，市场环境是瞬息万变的，而前台是主要的一线业务，这时就需要一个强大的技术中台提供快速设计方法和系统性后端服务，去应对市场变化，灵活快速的做出应对策略。

1.2 应用模式

        就阿里平台与个体商家的关系而言，虽然互相为独立的主体，但因为业务之间存在的联系，一定程度上已经分不清彼此，对于阿里来说，“大中台，小前台”理念中的前台强调创新和灵活多变，包括云计算、大数据、零售电商、广告业务、物流配送、售后维护以及其它业务；中台强调协调和规划管控，为前台业务开展提供底层技术、数据等资源支撑，多为平台类体系产品，一般都是外购、开源、自研相结合、不同的企业比重不同。

2. 中台划分

        如今大中台模式不再拘泥于电商行业，随着发展和演变逐渐走向集团型、大型企业，为整个集团提供运营数据能力、技术能力、支撑能力、产品能力等，这时对于大中台的运用与划分也不再只是技术中台，还包括基础中台、数据中台、业务中台共同构成。

2.1 基础中台

        基础中台为大中台模式的底层基础支撑，也称之为PaaS容器层，而对于中台模式来说，要求平台灵活高效，这就意味着对容器集群管理与容器云平台的选择十分重要，技术运用的是否到位直接影响平台的开发效率和运维程度，在这方面目前Docker和K8S独占鳌头，同时对应的DevOPS与CI/CD理念也随着兴起。

        敏捷开发和DevOps都是为了更好更快的发布产品而提出的一种理念，而CI/CD是实现这两者理念的一种方法，即持续集成、持续交付。这些理念、工具、方法论作为基础中台组成部分来支撑中台模式。

2.2 技术中台

        中台技术不是空穴来风，是随着平台化架构的发展所演进的产物，从技术层面来讲，大中台技术延续平台化架构的高聚合、松耦合、数据高可用、资源易集成等特性，之后结合微服务方式，将企业核心业务下沉至基础设施中，基于前后端分离的模式，为企业打造一个连接一切、集成一切的共享平台，技术中台架构如下：

        从技术中台架构中可以看出，底层为应用提供层，即企业信息化系统或伙伴客户相关信息化系统等；上层为集成PaaS层，将服务总线、数据总线、身份管理、门户平台等中间件产品和技术融入，做为技术支撑；DaaS数据层通过数据中台，结合主数据、大数据等技术，发挥数据治理、数据计算、配置分析的能力，服务中台层与共享服务层共同支持应用层中的行业业务，为用户提供个性化的服务。

2.3 数据中台

        随着数字化时代到来，互联网、云计算、大数据、人工智能等技术推动着传统企业的数字化转型，未来企业对人、事、物的管理必定会被数字化全面替代，在数据中台部分，帮助企业进行数据管理，打造数字化运营能力。数据中台中不仅包括对业务数据的治理，还包括对海量数据的采集、存储、计算、配置、展现等一系列手段，数据中台架构如下：

        从下至上可以看出，主要从系统、社交、网络等渠道采集结构化或半结构、非结构化数据，按照所需的业态选择不同技术手段接入数据，之后将数据存入到相应的数据库中进行处理，通过主数据治理清理脏数据，保证所需数据的一致性、准确性、完整性，之后将数据抽取或分发至计算平台中，通过不同的分析手段根据业务板块、主题进行多维度分析、加工处理，之后得到有价值的数据用于展现，辅助决策分析。

2.4 业务中台

        技术中台从技术角度出发，数据中台从业务数据角度出发，业务中台站在企业全局角度出发，从整体战略、业务支撑、连接用户、业务创新等方面进行统筹规划，由基础中台、技术中台、数据中台联合支撑来建设业务中台，业务中台架构如下：

        底层以PaaS为核心的互联网中台作为支撑，通常将开源的、外采的、内研的信息化系统、平台等作为基础的能力封装成核心技术层，通过系统整合、业务流程再造、数据治理分析等一系列活动为企业的业务提供支撑，形成特有的业务层，连接上下游伙伴、内外部客户、设备资源系统、建立平衡的生态环境，支撑业务的发展与创新。

3. 前置条件

        随着“大中台，小前台”模式的演进，很多企业开始纷纷效仿大中台这一业务模式，但并不是所有企业都可以成功实行中台策略，事实上大中台的构建如同大数据平台的建设一样，要具备特定的前置条件，下面主要从行业特性、企业体量、技术实力等几个方面进行分析。

3.1 行业特性

        大中台策略的产生是基于互联网背景之下，虽由电商行业兴起，但用户群体面向ToBs，用于打造产业生态链、衔接上游供应商、下游代理商/经销商业务，帮助企业前台贴近用户，提供更好、更人性化服务，提升用户体验、加快业务交互频率，中台和后台提供管控协调和技术支撑。在当前阶段，“大中台、小前台”这一模式在金融、银行、政府、能源等行业领域已经开始展开建设了。

3.2 企业体量

        大中台模式建设对企业体量有较高的要求，通常为龙头企业、行业楚翘，组织结构庞大而复杂，存在众多有实力的子公司或下级单位，并且整体业务上多元化：多板块、多业态。集团内部拥有较为充足的资金力量、能力较强的技术团队，良好的信息化基础设施建设，具备强大的能力去整合业务和上下游的业务和信息化系统。

3.3 技术实力

        对于构建大中台业务模式的企业来说，内部需要具备一定的技术实力，首先要对自身业务领域及业务流程模式具备较深的了解，之后对中台需要的技术/产品（开源的/非开源的）具备扎实的基础，以便后续对中台成果维护的同时发现问题并进行改进，如果当前企业暂时不具备独立构建或维护中台成果的能力，那么可以与一些技术实力强的厂商共同合作完成，在构建的过程中能够迅速地学习对方的能力。

4. 构建模式

        在满足上述前置条件之后，企业对于大中台的构建通常分为三种模式，一种为全部外采，外包给实施团队；一种为吸收开源融合业务，之后将成果开源；一种为自研、开源相结合，下面将具体阐述每种模式。

4.1 外部采购

        排除信息化团队的能力不谈，使用该种模式的企业通常拥有雄厚的资金，或是在行业特性、业务方面与外采的大中台产品或技术框架有一定的相似度，业务内容具备较高的复用性，否则在独有业务定制开发方面会花费更高的人力、时间、金钱成本，得不偿失。对于外采模式，通常不会购入成品中台，而是购入开放的中间件平台类产品，如ESB、Portal、IDM、MDM、BI等作为技术中台、数据中台提供能力支撑。

4.2 基于开源

        该种模式企业通常拥有自己的信息化团队，当然不排除一些企业注重时间成本而直接高薪聘请专业信息化团队打造大中台架构，对于底层技术，不需要花费过多时间去自研，使用开源框架及产品作为支撑即可，对于专有业务结合扩展开发，打造属于自身业务发展的大中台架构。部分企业基于这种模式，会将研究成果全部或部分开源出去，供其他类似行业使用借鉴。

4.3 自主研发

        使用该种模式的企业同样具备信息化团队，在大中台技术架构上，不想全部采用外部吸收的技术，也不愿将平台后续的扩展与维护受限于他人，在特有业务或主营业务方面的技术产品选择自研，底层通用框架方面选择当前开源的技术与产品，部分技术中台、数据中台中涉及产品选择外采，并基于在外部技术团队实施的过程中，吸收、学习产品使用的能力，后期维护扩展。

4.4 最佳实践

        无论是微服务还是大中台理念，都是基于中国市场特有业务，根据传统架构模式演变而来，无论是构建成果还是发挥的作用都更加适应中国模式的发展，当前对大中台的构建也应该遵循中国市场独有的最佳实践。

        大中台模式不仅对企业内部进行整体管控，还是商业模式的支撑手段及营销渠道，构建时应当注重对中台建设整体的管控能力，在具备充足人力、财力的情况下，也不必采用全部自建的模式，对于通用类软件在满足开发性前提下考虑外采，由原厂商提供技术支持，对主营业务建设则以自建为主，结合外采一些技术平台类产品、整体解决方案来实现，着重衡量产品的开放性、敏捷性、扩展性、维护性，实施团队的成熟度、专业性、知识传递性等，企业在建设过程中完成技能培训、知识转移，沉淀最佳实践，后续独立进行平台搭建、扩展、改造、维护，最终实现中台建设自主可控。

5. 延展分析

        随着“大中台，小前台”模式的出现，很多人会与前段时间炒得很火的微服务与PaaS平台、SOA相比较，今天笔者在这里将当今较火的几个词语，PaaS平台、微服务、SOA与大中台之间的关系做对比分析。

5.1 中台与微服务

        笔者之前的文章中曾提到过，微服务架构是云时代下应用系统的技术架构、建设方式，基于微服务将复杂臃肿的单体应用进行细粒度的服务拆分，经过组件分离各自拥有独立的生命周期，并按需进行扩展，微服务的实现有效打破了组件之间的技术依赖，使每个服务各自选择最合适的技术进行实现，微服务模式下控制层访问到服务层，典型方式是单体应用基于“前后端分离”模式来开发。

        而大中台服务架构是微服务架构的升级，策略为“大中台、小前台”，打造共享服务平台的模式，中台的最终效果为前台单体应用构建灵活的业务服务开发、治理体系，基于集成平台产品套件，融合集成后台各应用系统、支撑业务创新变化。这种思路实现基础和共性能力的下沉和剥离，相对于整体来说，各个基于大中台中的单体应用从数据库到服务层再到前端展现都需要纵向独立的拆分松耦合的微服务模块。微服务架构“大中台、小前台”模式的特性，同时要求技术中台、数据中台都有强大微服务提供能力。

5.2 中台与PaaS平台

        云计算通常来说包括IaaS、PaaS、SaaS三个层面，在中国IaaS发展相对来说较为成熟，阿里云、腾讯云、华为云其实更多都是IaaS层面的产品；SaaS发展在前几年（2010-2016）都是看起来很风光的、尤其是看到SaaS模式的Saleforce以460亿美金高价位被Oracle收购后，中国的SaaS 厂商都像打鸡血似的，踌躇满志以为会成为中国的Salefore，然而喧嚣过后一地鸡毛，在更多的炮灰倒下之后，残留更多是挣扎在生死线上。

        PaaS作为云计算的服务模式之一，是位于IaaS和SaaS模型之间的一种云服务，早些年在中国发展一直很迟缓，究其原因一方面是相关技术不够成熟、另外一方面没有合适的业务模式、盈利方式。现在基于Docker、K8S为代表的容器技术和生态，微服务的理念和相关工具、DevOps的相关产品和方法体系逐渐成熟起来，再加上“大中台，小前台”的概念抛出，实际的需求呼唤，PaaS开始在中国这片古老的大地野蛮生长。

        “大中台、小前台”其实也是PaaS平台技术具体落地的一种实现方式。PaaS平台引入Docker技术后，采用虚拟机技术实现了对应用程序、系统以及资源之间的有效隔离，保证了资源的独立性，不被其他人占用。而大中台的建设与PaaS的容器层CaaS、K8S、Docker等技术相结合，将具有PaaS能力应用服务器、数据库、应用支撑平台，如Portal、MDM、ESB等以私有镜像模式封装在Docker容器中，供K8S来调度、编排、治理，最终形成一个可以具有集成性、开发扩展性、支撑快速创新的中台模式。

5.3 中台与SOA架构

        SOA（Service OrientedArchitecture ）面向服务架构，它是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。对于SOA架构来说不同的人有不同的定义，它曾被称之为一种架构体系、一种方法论、治理理念等，大中台模式与SOA架构在理念上是一脉相承的，SOA相关产品套件可以作为技术中台与数据中台支撑大中台策略，大中台策略从技术角度来看，也可以作为SOA中开发集成模式的一种演化变形。

        技术中台中的相关产品，如：服务总线、数据总线、身份管理、门户管理等技术的实现，都是SOA综合集成方案的拆分与变形，数据中台中的数据治理、分析能力同为SOA集成方案的重要组成部分。同时在开发集成方案中，采用SOA整合套件作为基础技术框架及应用支撑平台，梳理、制定出面向行业业务的标准接口和管理体系，根据标准接口规范集成行业的典型应用系统，对于个性化业务进行快速定制开发，之后通过前端平台展现。

        随着“大中台、小前台”技术架构、业务模式的兴起，的确为企业带来新的治理思路及支撑业务创新的方案，企业根据自身业务发展构建大中台从方向来说无疑是正确的，但要遵循前置条件及适合企业的最佳实践，根据自身当前的业务模式、技术平台来合理选择底层框架、引入开源和商用产品，结合内部研发来打造符合企业特色“大中台、小前台”技术架构体系，满足众多受众（内部用户、高管、供应商、分销商、客户、银行以及政府监管部门等）的高频变化，满足业务发展、支撑产业链建设升级，不断强化企业在行业内、生态链中的江湖地位。