此文是我閱讀《企業IT架構轉型之道》一書的學習筆記，所有內容出自鍾華老師的這本書。

零、為何讀《企業IT架構轉型之道》

　　在加入X公司後，開始了微服務架構的實踐，也開始了共享平臺服務的建設，在這方面阿里巴巴的中臺戰略是一個較好的參考。於是，領導就贈了這麼一本《企業IT架構轉型之道》給我，希望我學以致用，更多的是有這樣的一個眼界去指導我們的中臺架構設計。因此，我花了兩週時間快速地閱讀了一下此書，總結了此文作為學習筆記以供日後複習用。此書的確講了一些乾貨，雖然很多內容留於表面，但是對於中臺的定義和思考，建設中臺的方法以及阿里中介軟體有比較完整的描述，和多年前出版的《淘寶技術這十年》以及《大型網站技術架構-核心原理與案例分析》一樣，是一本值得學習的好書。

一、引子

Part 1 阿里中臺戰略引發的思考

• 起源自2008年阿里巴巴三大電商體系的技術支援架構
  • 1688、淘寶、天貓三套電商體系架構完全獨立
  • 三座煙囪分別矗立支撐阿里巴巴最核心的電商業務
• 煙囪式系統建設系統對企業的“三大”弊端
  • 重複功能建設和維護帶來的重複投資
  • 打通“煙囪式”系統間互動的整合和協作成本高昂
  • 不利於業務的沉澱和持續發展 => 對企業傷害最大
• 企業資訊中心的組織職能是業務支援？
  • 問題核心在於IT資訊部門在現有模式下大多被高管定位為業務支援的部門 => 一個花錢的成本中心
  • 問題原因在於IT資訊部門的人員不懂業務 => 這裡的懂業務是指“能對業務的下一步發展有著自己的理解和看法，對業務流程如何進一步優化能更好的地提升業務，甚至對企業現有的業務提出創新的想法，為企業帶來新的業務增長點。”
  • 問題結果導致了IT資訊部門的人員很少能在一個業務領域做足夠的業務沉澱 => 對業務知其然而不知其所以然

“煙囪式”的系統建設模式

Part 2 構建業務中臺的基礎—共享服務體系

• SOA架構的核心價值
  • 服務重用 => 從服務重用到共享服務
• 共享服務體系的建設：克服“煙囪式”架構的三大弊端
  • 避免重複功能建設和維護帶來的成本浪費 => 沒有實現系統業務互通的訴求
  • 最大程度避免打通不同系統間實現業務互動帶來的整合和協作成本 => 各個應用在核心業務層已經實現了統一和暢通
  • 能夠很好地培養出特定領域的專家 => “既精通業務，又熟悉技術”的複合型人才
• 企業資訊中心組織陣型的調整
  • 針對共享服務體系重新組織人員，使成員有機會成為業務領域的專家（複合型人才）
  • 最核心的角色是架構師，他們會是各服務中心的業務負責人
  • 資訊團隊會從“業務支援”的組織職能轉向基於企業核心業務和資料進行運營的團隊

阿里巴巴的“大中臺”體系建設

PS：在閱讀這一部分時，個人最大的感觸就在於企業資訊中心的境遇，我所在的公司是一個傳統行業，我們部門是從2018年末開始擴建的資訊中心，和廣大企業資訊中心一樣，雖然無一不被認可資訊部門對企業發展的重要地位，行政級別也和核心業務部門的級別相當，但是實際情況卻是沒有同樣平等的話語權，因為在高層領導的眼裡就只是單純把資訊中心定位為了業務支援部門，是一個花錢的成本中心。而造成這樣處境的原因，也很贊同鍾華老師在書中的觀點，那就是資訊部門的員工不懂業務，這裡的不懂業務是指能對業務的下一步發展有著自己的理解和看法，對業務流程如何進一步優化能更好的地提升業務，甚至對企業現有的業務提出創新的想法，為企業帶來新的業務增長點。而要提高資訊部門的員工對於業務的精進，需要建設類似阿里巴巴的共享服務中心，服務需要不斷的業務滋養才能足夠強大地支援前線的士兵，也只有在滋養中才能從最初提供單薄業務功能的服務元件成長為企業最為寶貴的IT資產。正如鍾華老師所示，未來在整個社會進入開放共享的時代，企業最大的價值將會是基於核心業務和資料進行對外開放的運營，到那時資訊部門的共享服務體系將成為企業最為寶貴的資產。

二、共享服務體系的搭建

Part 3 分散式服務框架的選擇

• “中心化”與“去中心化”服務框架的對比
  • 服務呼叫方式的不同帶來業務的響應和擴充套件成本：基於ESB的響應速度慢（因為網路開銷大一倍），而要擴充套件ESB需要承擔軟硬體的不小投入（比如巨大的授權費）
  • “雪崩”效應束縛了“中心化”服務框架的擴充套件能力：不適合網際網路企業的根本原因，因為一旦雪崩故障恢復的時間和成本都非常高昂！
• 阿里巴巴的分散式服務框架HSF
  • 組成部分：服務提供者、服務呼叫者、地址伺服器（Nginx）、配置伺服器（服務註冊&發現）、Diamond伺服器（類似於Zookeeper）
  • 工作原理：服務節點對配置伺服器列表的獲取、服務的註冊釋出、服務的訂閱、服務規則的推送（如果需要）、服務互動
  • 核心能力：Netty+Hession資料序列化協議實現服務互動（大併發量下的高效能）、容錯機制（長連線+秒級感知）、線性擴充套件（增加服務例項即可擴充套件服務能力）
• 關於微服務
  • 阿里巴巴2009年開始的共享服務體系算得上是微服務實踐的先驅
  • 從本質上說，微服務是SOA的一種演變後的形態，與SOA的方法和原則沒有本質上的差別
  • 微服務與SOA的兩點最鮮明差異在於：
    • 傳統SOA架構基於“中心化”的ESB構建，而微服務採用的是系統提供服務的方式實現系統間的互通；
    • 傳統SOA實施的方式是專案制，而微服務是以做產品的方式讓服務在業務發展過程中快速演化；
  • 概念一時爽，問題一堆堆：
    • 微服務化的應用架構的有效服務管控？
    • 分散式事務的難題？
    • 自動化運維和平臺穩定性？
    • 微服務的服務設計？=> DDD

PS：微服務不是“免費的午餐”，阿里巴巴2009年開始的共享服務體系建設歷程算得上是微服務架構的建設過程。正如鍾華老師所說，“羅馬不是一天建成的”，企業如果要構建微服務架構體系，也是需要多一份耐心的，通過服務能力在業務發展過程中的不斷沉澱，當業務的能力沉澱到一個階段後，才能真正感受到微服務架構給企業的業務發展帶來的長遠價值。

Part 4 共享服務中心建設原則

• 服務中心的三個特徵
  • 服務中心是伴隨業務不斷髮展的：不做過於超前的設計，也不做過於理想化的架構
  • 服務中心的服務形態多樣化：介面、工具、資料...
  • 一個服務中心還可以進一步劃分：單個服務模組、多個服務模組...
• 服務中心的劃分原則
  • 更多靠的是架構設計經驗總結，很難給出精確的量化指標
  • 一般來說會兼顧3個方面的需求：
    • 設計 => 遵循面向物件的分析和設計方法論
    • 運營 => 服務中心應該是一個完整額業務模型
    • 工程 => 綜合評估業務層對服務中心在DB、業務以及運營方面的需求和技術上需要的投入
  • 實際中的一些基本原則：
    • 高內聚、低耦合原則
    • 資料完整性原則：特別強調大資料思維
    • 業務可運營性原則：服務中心是承載業務邏輯、沉澱業務資料、產生業務價值的業務單元
    • 漸進性的建設原則：小步快跑，服務化從簡單開始！

 PS：記得張逸老師在《領域驅動戰略設計實踐》課程中的開篇提到他向DDD大師Eric Evans提問“如何正確地識別限界上下文？”，結果Eric Evans思考了一會兒，嚴肅地回答了一句：“By experience！”。這是一個正確的廢話，但好像又蠻有道理。對於共享服務中心的建設和劃分來說，也同樣如此，更多的是依靠架構設計經驗的總結，作者也很難給出一些具體問題給出一個精確的量化指標。正如作者所說，架構本來就是一個追求平衡的藝術，不僅是設計原則上的平衡，還要在技術、成本、資源、效能、團隊等各方面進行平衡，以最高效地解決主要問題。

Part 5 資料拆分實現資料庫能力線性擴充套件

• 資料庫分庫分表的實踐
  • 阿里巴巴分散式資料層平臺發展演變：Cobar(2006) => TDDL(2008) => DRDS(2014)
  • 資料儘可能平均拆分：需要結合業務資料的結構和業務場景來決定
  • 儘量減少事務邊界：“事務邊界”指單個SQL語句在後端資料庫上同時執行的數量
  • 異構索引表儘量降低全表掃描頻率：“拿空間換時間”，阿里巴巴的精衛填海產品
  • 將多條件頻繁查詢引入搜尋引擎平臺：採用專業搜尋引擎平臺提供搜尋服務，Lucene、Solr、ElasticSearch
  • 簡單就是美：“資料儘可能平均拆分”作為第一優先考慮，82法則

PS：阿里巴巴的分散式資料層平臺發展的演變可謂是一部技術驅動變革的歷程，經歷了一個又一個的技術難題，出現了一個又一個的開源/商用產品，提高了阿里巴巴的效率。印象深刻的地方在於，我們都有一個印象就是在資料庫開發和呼叫時，要充分利用索引，避免全表掃描。但是，作者說到在真實的業務場景中很難完全避免全表掃描，比如對於訂單進行復雜的分散式條件檢索的時候，就會需要採用全表掃描，將查詢語句同時推送到後端的資料庫中才能實現該場景。但是，因為呼叫量不會很頻繁，而且計算的資料量並不大，所以整體上不會給DB產生太大的影響。另外一個點就是，從系統風險的角度來看，以82法則，在實際中，作者建議僅對那些在80%情況下訪問的那20%的場景進行如資料異構索引這樣的處理，達到這類場景的效能最優化，而對於其他80%偶爾出現跨庫join、全表掃描的場景，採取最為簡單直接的方式往往就是最有效的方式。

Part 6 非同步與快取原則

• 非同步化
  • 業務流程非同步化：服務非同步呼叫，提升大量遠端服務線性呼叫帶來的效能問題
  • 資料庫事務非同步化：將大事務拆分成小事務，提升吞吐量和事務操作的響應時間
    • 事務 => 核心是ACID
    • 柔性事務 => 基礎是CAP理論和BASE理論，因為網際網路應用最核心的需求是高可用（BASE中的BA）
      • 解決分散式問題的機制：①日誌和補償機制、②可靠的訊息傳遞、③無鎖實現（避免事務回滾、輔助業務變化明細表、樂觀鎖等）
    • ACID與BASE一般在系統中會結合使用，追求最終一致性
• 快取
  • 小庫存商品秒殺典型架構
    • 核心問題：處理好商品的庫存的扣減，不出現超賣的情況
    • 核心方案：
      • 快取商品的詳細資訊（包括庫存），不直接訪問後端資料庫
      • 商品庫存使用樂觀鎖，避免出現超賣
      • 商品庫存控制業務流，只在下單環節才對資料庫訪問，降低資料庫訪問頻率
  • 大庫存商品大促架構
    • 核心問題：處理好庫存更新的準確與使用者等待時間的平衡
    • 核心方案：
      • 將快取提升到為庫存操作提供事務支援的角色 => 將訂單交易建立環節在快取伺服器中執行，提高響應速度
      • 藉助訊息佇列實現快取伺服器中的庫存修改線性處理
      • 快取服務故障時通過快取資料和資料庫訂單資訊還原訂單處理的最新狀態

PS：非同步化與快取兩個技術都和我們的系統性能有很大的關聯，在分散式應用架構中，如果沒有這兩項技術的引入，相信設計出來的應用很難有優質的效能表現。淘寶平臺是一個典型的分散式服務架構，通過業務流程非同步化提升了效能，分庫分表後又在非同步操作場景下實現了事務一致性與資料庫處理效能的平衡。最後，通過適當使用快取技術實現了商品秒殺場景下的技術架構，這都是我們需要學習和借鑑的。

小庫存商品秒殺場景訂單處理流程圖

大庫存商品秒殺場景訂單處理流程圖

Part 7 打造數字化運營能力

• 業務服務化帶來的問題
  
  • 服務呼叫關係紛繁複雜，難以定位問題
  • 不同角色的技術人員需要一些列的管控
• 分散式服務呼叫鏈路平臺
  • 阿里巴巴內部實現：“鷹眼”平臺，JStorm流式計算引擎
  • 核心思路：埋點和輸出日誌
• 海量日誌分散式處理平臺
  • 阿里巴巴內部實現：TLog平臺，日誌處理流程“所見即所得”
  • 日誌收集控制：遇到大量請求時只記錄其中一部分資料，而非全量收集

PS：實現初步的分散式服務體系之後，我們的平臺必然會變成一個比較複雜的互動鏈路網，這會對我們的管控帶來一些問題，比如服務呼叫鏈監控、服務執行狀態是否正常，如何提供關鍵指標以實現精準營銷等等。好在無論是商用產品還是開源產品，都有了比較成熟的技術方案，我司已經在調研學習Skywalking和ElasticSearch，以後有機會做這方面的分享。

　　在此推薦一波Skywalking：

　　在 ASP.NET Core 中整合 Skywalking APM （from savorboard 楊曉東）

　　Apache SkyWalking 為.NET Core帶來開箱即用的分散式追蹤和應用效能監控 （from Lemon 劉浩楊）

　　使用docker-compose 一鍵部署你的分散式呼叫鏈跟蹤框架Skywalking （from 一線碼農 黃星辰）

　　更多Skywalking分享：https://github.com/OpenSkywalking/Community

Skywalking中的請求呼叫鏈拓撲檢視

Part 8 打造平臺穩定效能力

• 提高穩定性的實踐
  
  • 限流和降級：限流相當於電路保險絲，而降級則是為保證核心服務而犧牲自己，阿里巴巴自研Sentinel限流平臺
  • 流量排程：通過實時指標監控，對預計發生故障的服務進行下線等操作，以避免單點或區域性故障
• 業務開關：通過集中化管理業務API操作開關，阿里巴巴自研Switch平臺
• 容量壓測及評估規劃：將線上真實流量引到壓測伺服器，並差異化分析對線上伺服器的增減提供實時參考決策
• 全鏈路壓測：每個環節都參加的實戰演習，例如雙11實戰演習
• 業務一致性平臺：保證業務與資料一致的業務穩定性，實時檢測業務不一致的問題，阿里巴巴自研BCR業務審計平臺

　　＃Sential Github: https://github.com/alibaba/Sentinel （輕量級的流量控制、熔斷降級 Java 庫）

　　＃Sential Wiki：分散式系統的流量防衛兵

Sentinel 的主要特性

Part 9 共享服務中心對內和對外的協作共享

• 共享服務平臺的建設思路
  • Step1.找到一個合適的服務化物件：比如API
  • Step2.建設物件服務化的基礎設施：比如結構化包裝，讓API成為治理良好的元件服務
  • Step3.服務化實施階段：循序漸進的過程，三個階段參考
    • API as Service => 服務化的第一步
    • Product as Service => 大量業務API升級為服務化平臺的元件服務
    • Solution as Service => 經過長時間的沉澱可以形成解決方案，如海外淘寶解決方案
  • Step4.增強服務和基礎設施實現服務的精細治理
• 對內：共享服務平臺的協作
  • 與業務方的協作：以服務為物件建立一個線上市場，三大角色
    • 共享服務平臺 => SPAS
    • 服務提供者 => 商品、交易、店鋪、物流等
    • 服務消費者 => 商品、交易、店鋪、物流等 （消費者通常也是提供者）
  • 與前端應用協作：服務提供者與消費者，相輔相成，共同發展
    • 阿里巴巴的一些實踐：緊密溝通，分歧升級、崗位輪轉（換位思考）、業務沉澱及共建
• 對內：業務中臺績效考核
  • No.1 服務的穩定：比如一年只允許兩次P1故障
  • No.2 持續業務創新：鼓勵業務中臺運營團隊業務創新，包容業務創新引起的故障
  • No.3 服務接入量：考量服務能力的專業度以及對外的服務運營能力
  • No.4 客戶滿意度：對中臺服務運營團隊起到督促作用
• 對外：開放能力構建生態
  • 核心內容：將自身平臺中的資料以服務的方式對外進行開放，從而吸引眾多外部群體基於這些服務提供增值服務，持續地為客戶提供優質的運營平臺能力，從而最終構建基於開放平臺的生態體系。

PS：在這部分內容裡邊，印象最深刻的還是作者提到在網際網路轉型時，很多人想要構建生態，但卻沒搞清楚“生態”和“上下游”的關係，它們之間的最本質的區別在於：在“上下游”模式中整個體系中所有的參與者都是被動的使用者，而“生態”模式中的參與者確是主動使用者，他們會持續地往整個體系中注入自己的智慧和創新的源泉，不斷貢獻自己的價值，只有這樣的模式才能打造出企業所希望的生態效果。而傳統企業現在應該著眼於企業內部的核心業務能力的打造，等到有一天需要通過能力開放的方式拓展企業業務邊界或構建生態的時候，這些沉澱的服務會是企業最大的資產，而資訊中心部門也不會只是一個成本中心，而有可能變為對外進行能力輸出的關鍵運營部門。

三、阿里巴巴的實踐案例

Part 10 大型央企網際網路轉型

　　阿里巴巴協助國內某大型央企在90天構建出了一個B2B電商平臺，整體平臺架構基於阿里巴巴的共享服務理念和阿里雲飛天Aliware的一系列產品，現在已經成為了國有大型企業進行網際網路業務成功轉型的標杆性專案。

Part 11時尚行業品牌公司網際網路轉型

　　某服裝品牌民營企業基於阿里巴巴的共享服務架構完成了企業全渠道分銷平臺的重構，解決了高庫存和高流單率的難題，實現了O2O的融合，建立了以客戶體驗為中心的系統架構，為企業在同行業的競爭中建立了差異化的競爭能力。

PS：2014年開始，國家就開始倡導“網際網路+”的轉型，越來越多的傳統企業加入到網際網路轉型的浪潮，像我司一樣的傳統家居企業也開始了轉型，於是開始建設資訊中心，於是我就來了... 幸運的是，我司已經在成都地區小有名氣，並且是一個知名的品牌，接下來要做的，借用作者的原話就是需要我們資訊中心能夠更好地使用網際網路技術、利用網際網路服務、借鑑網際網路企業的運營模式，更好地實現價值鏈中各節點的連線，讓流程更加透明，業務更加可視，最終能夠挖掘企業的瓶頸，更好地滿足消費者的需求，以獲得更好的成長。對我個人而言，在此期間能夠積累和沉澱更多的經驗是最重要的，加油！

參考資料

鍾華，《企業IT架構轉型之道-阿里巴巴中臺戰略思想與架構實戰》

James，《給架構師的推薦-企業IT架構轉型之道》

馬崇，《企業IT架構轉型之道的思考》

作者：周旭龍

出處：http://edisonchou.cnblogs.com

本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段宣告，且在文章頁面明顯位置給出原文連結。