728
技術社區[雲棲]
阿裏巴巴中台架構的建設原則——走進《企業IT架構轉型之道》係列2
上一篇提到，阿裏巴巴以共享服務體係來作為其“中台”戰略的核心支撐，那麼應該選擇什麼樣的框架構建這個共享服務體係？
我們先來簡單回顧一下淘寶平台“服務化”曆程。發展到2007年，淘寶成為了一個由超過500人的技術團隊共同維護的WAR包（幾百兆字節），大小功能模塊超過200個，飛速發展的業務（當時的淘寶基本上幾個月業務就會翻倍）與傳統的應用架構碰撞帶來了下麵幾大問題：
1）團隊間協同成本高，業務響應越來越慢。超過200個功能模塊的包，必然分項目進行開發以及維護，這樣每次係統功能升級後新版本上線會出現各種衝突以及不一致的情況，需要耗費大量的成本來溝通協作。
2）錯誤難隔離，應用複雜程度已超出人的認知負載。200多個功能模塊中核心模塊如用戶、商品、交易等比較穩定，一些前端頁麵交互、廣告展示等非核心模塊則可能每天都有新的發布。錯綜負責的模塊雜糅在一起導致每一次的發布都蘊藏著巨大的風險，淘寶曆史上發生過幾起因為非核心功能設計不合理而導致整個業務受到影響的事件，整個平台給人一種“牽一發而動全身”的感覺。
3）拓展成本高。當係統出現業務瓶頸時，由於所有的功能模塊都打包在一起，無法單獨對負載較高的功能模塊進行拓展，隻能將整個完整的應用拓展而帶來額外配置的消耗。
以上問題驅使淘寶團隊於07年開始進行架構的改造，最終選擇了“去中心化”服務框架（共享服務體係）來搭建整個中台，關於為什麼沒有選擇當時盛行的“中心化”服務架構（ESB模式下的SOA架構）除了在係列一中提到幾點外，還有下麵兩點考慮：
第一，由於服務調用方式不同，ESB模式下的SOA架構所需的網絡帶寬要求非常高，對於具有一定量級用戶的應用來說，采用ESB方式將會導致在網絡設備上的超大額投入；
第二：企業服務總線承載了越來越多的服務路由壓力，這是必然會采取集群部署的方式進行負載均衡以提供可用性，卻因此也埋下了巨大的隱患，當業務訪問峰值時，假設每個總線的負載達到80%，日常運行中不會產生問題，但是如果一台服務器出現了故障將會施壓給其他即將滿載的服務器，這就要求所有的服務器狀態都非常“健壯”，否則在業務高峰時就會被各個擊破從而導致企業服務總線全軍覆沒，給整個平台帶來災難性的後果。
阿裏巴巴集團目前的分布式服務框架HSF（Hign Speed Framework，也有人戲稱“好舒服”）支撐著2000多個應用的運行，以服務化的方式構建整個應用體係的同時也保證了在高並發的情況下，服務依然保持高穩定、高效交互以及強大的拓展能力。
按照ESB模式下的SOA模式，很多人認為服務中心是一個固化的概念，每個服務中心提供某項服務後便一勞永逸，實際上大部分企業的SOA都是作為一個項目，項目結束後服務中心基本也就固化了，當有新的需求產生時，服務中心如果不能滿足，就不得不產生新的“煙囪”。實際上服務中心應該是一個充滿生命力的個體，是一個承載業務邏輯、沉澱業務數據、產生業務價值的平台，隨著公司的業務不斷發展進化。
下麵介紹在阿裏巴巴中台架構建設的實踐中總結出來的一些原則：
1.高內聚、低耦合原則——高內聚是指同一個服務中心內的服務模塊應該相關性、依賴性很高，而服務中心之間應該隔離性較大，盡可能追求低耦合。
2.數據完整性原則——與上一條原則一脈相承，讓業務相關的數據統一起來，盡可能讓數據模型統一，為以後的大數據建設做好基礎。
3.可運營性——這裏的可運營性包含2層含義，一是指能快速滿足上層業務的需求，同時利用業務不斷滋養平台，二是指共享服務中心這個平台的可運營性，數據模型統一之後可以較低成本的引入大數據技術，讓數據來源、數據分析、數據業務價值自然行程閉環，所以通過服務中心引入大數據來產生業務價值也是服務中心建設原則之一。
4.漸進性原則——該原則是從降低風險和實施難度的角度出發，有些人可能會覺得服務中心是基礎建設，所以從一開始設計了太多的原則從而導致項目周期延長，數據過於分散也會產生數據庫性能以及分布式事務的問題，其實服務化架構就是一種敏捷實踐，我們推薦小步快跑而不是推倒重來，通過真實的業務需求鍛煉出高價值高可靠的共享服務。
共享服務最基本的目的就是要把普通的服務能力升級為組件化服務並對服務本身加以管理，我們可以依次按照下麵來實踐共享服務平台的搭建：
第一、找到合適的服務化對象。這個對象要能夠涵蓋各種各樣的業務流程、業務數據又要便於封裝。為了保持對現有係統的兼容性，目前阿裏巴巴集團的共享服務中心的功能支持粒度都是API，但是並不意味著隻能把API作為服務對象，也還可以有其他粒度的服務。
第二、建設對象服務化的基礎設施。有了服務話對象之後，需要製定製定相關的服務組件規範以及對應的服務治理平台與工具，以便對服務進行封裝。一個完整的服務應該包括的基本功能有服務的描述元數據、服務注冊與發現機製、服務訪問控製與安全策略、應用服務portal、服務依賴與運維管理、服務SLA協議、服務消費者的管理與支持工具、服務化輔助工具支持、服務調用分析與報表、服務成本核算與服務能力變現、文檔與開發工具支持。
第三、服務化實施。阿裏巴巴中台把推進服務化實施過程化分為三個階段：API as Service, Product as Service, Solution as Service。API as Service 解決了存量API的服務化問題，Product as Service是基於API初級服務的深加工，服務更麵向場景，更專業化。這兩個階段實現了阿裏巴巴從基礎能力到業務能力的共享開放，Solution as Service的目標是讓各種業務場景和解決方案在共享服務平台上達到最大程度的複用，讓業務的拓展是基於服務的方式而不是基於代碼的方式。
當然業務中台是前端應用所需服務的提供者，中台的需求需要前端應用來提供，兩者需要在對接過程中相輔相成，共同發展。在阿裏巴巴業務中台過去的幾年發展中出現了多種與前端應用協作的模式：建立業務中台對前端核心業務的緊密溝通機製，及時、準確地了解核心業務需求；建立分歧升級機製；崗位輪轉推動真正換位思考；業務持續沉澱及業務共建等。
內容摘錄於《企業IT架構轉型之道》
作者：鍾華（古謙）
阿裏巴巴中間件首席架構師，15年中間件領域行業經驗。對傳統企業IT建設和互聯網架構都有較為深入的理解，有著紮實的理論基礎和豐富的實戰經驗，多次作為總架構師協助大型傳統企業打造業務中台項目，為企業實現“互聯網+”轉型提供了科學的發展方向和強有力的技術支持，項目涉及政府、製造業、金融、交通、媒體等多個領域。
本章主要介紹了共享服務體係建設的原則，接下來將分篇介紹共享服務體係搭建的過程、技術選擇、組織架構以及金融行業的應用實踐等。敬請期待！
來源：阿裏金融雲
原文鏈接
最後更新：2017-09-05 19:02:48