隨著數字化和網際網路時代的來臨，雲端計算、大資料、微服務、物聯網、移動互聯等各種新興技術為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整合套件作為基礎技術框架及應用支撐平臺，梳理、制定出面向行業業務的標準介面和管理體系，根據標準介面規範整合行業的典型應用系統，對於個性化業務進行快速定製開發，之後通過前端平臺展現。

        隨著“大中臺、小前臺”技術架構、業務模式的興起，的確為企業帶來新的治理思路及支撐業務創新的方案，企業根據自身業務發展構建大中臺從方向來說無疑是正確的，但要遵循前置條件及適合企業的最佳實踐，根據自身當前的業務模式、技術平臺來合理選擇底層框架、引入開源和商用產品，結合內部研發來打造符合企業特色“大中臺、小前臺”技術架構體系，滿足眾多受眾（內部使用者、高管、供應商、分銷商、客戶、銀行以及政府監管部門等）的高頻變化，滿足業務發展、支撐產業鏈建設升級，不斷強化企業在行業內、生態鏈中的江湖地位。