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

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

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

一、引子

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

• 起源自2008年阿里巴巴三大電商體系的技術支持架構

  • 1688、淘寶、天貓三套電商體系架構完全獨立

  • 三座煙囪分別矗立支撐阿里巴巴最核心的電商業務

• 煙囪式系統建設系統對企業的“三大”弊端

  • 重復功能建設和維護帶來的重復投資

  • 打通“煙囪式”系統間交互的集成和協作成本高昂

  • 不利于業務的沉淀和持續發展 =>?對企業傷害最大

• 企業信息中心的組織職能是業務支持？

  • 問題核心在于IT信息部門在現有模式下大多被高管定位為業務支持的部門 => 一個花錢的成本中心

  • 問題原因在于IT信息部門的人員不懂業務 => 這里的懂業務是指“能對業務的下一步發展有著自己的理解和看法，對業務流程如何進一步優化能更好的地提升業務，甚至對企業現有的業務提出創新的想法，為企業帶來新的業務增長點。”

  • 問題結果導致了IT信息部門的人員很少能在一個業務領域做足夠的業務沉淀 => 對業務知其然而不知其所以然

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

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

• SOA架構的核心價值

  • 服務重用?=> 從服務重用到共享服務

• 共享服務體系的建設：克服“煙囪式”架構的三大弊端

  • 避免重復功能建設和維護帶來的成本浪費 => 沒有實現系統業務互通的訴求

  • 最大程度避免打通不同系統間實現業務交互帶來的集成和協作成本 => 各個應用在核心業務層已經實現了統一和暢通

  • 能夠很好地培養出特定領域的專家 => “既精通業務，又熟悉技術”的復合型人才

• 企業信息中心組織陣型的調整

  • 針對共享服務體系重新組織人員，使成員有機會成為業務領域的專家（復合型人才）

  • 最核心的角色是架構師，他們會是各服務中心的業務負責人

  • 信息團隊會從“業務支持”的組織職能轉向基于企業核心業務和數據進行運營的團隊

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

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

正如鐘華老師所示，未來在整個社會進入開放共享的時代，企業最大的價值將會是基于核心業務和數據進行對外開放的運營，到那時信息部門的共享服務體系將成為企業最為寶貴的資產。

二、共享服務體系的搭建

Part?3 分布式服務框架的選擇

• “中心化”與“去中心化”服務框架的對比

  • 服務調用方式的不同帶來業務的響應和擴展成本：基于ESB的響應速度慢（因為網絡開銷大一倍），而要擴展ESB需要承擔軟硬件的不小投入（比如巨大的授權費）

  • “雪崩”效應束縛了“中心化”服務框架的擴展能力：不適合互聯網企業的根本原因，因為一旦雪崩故障恢復的時間和成本都非常高昂！

• 阿里巴巴的分布式服務框架HSF

  • 組成部分：服務提供者、服務調用者、地址服務器（Nginx）、配置服務器（服務注冊&發現）、Diamond服務器（類似于Zookeeper）

  • 工作原理：服務節點對配置服務器列表的獲取、服務的注冊發布、服務的訂閱、服務規則的推送（如果需要）、服務交互

  • 核心能力：Netty+Hession數據序列化協議實現服務交互（大并發量下的高性能）、容錯機制（長連接+秒級感知）、線性擴展（增加服務實例即可擴展服務能力）

• 關于微服務

  • 微服務化的應用架構的有效服務管控？

  • 分布式事務的難題？

  • 自動化運維和平臺穩定性？

  • 微服務的服務設計？=> DDD

  • 傳統SOA架構基于“中心化”的ESB構建，而微服務采用的是系統提供服務的方式實現系統間的互通；

  • 傳統SOA實施的方式是項目制，而微服務是以做產品的方式讓服務在業務發展過程中快速演化；

  • 阿里巴巴2009年開始的共享服務體系算得上是微服務實踐的先驅

  • 從本質上說，微服務是SOA的一種演變后的形態，與SOA的方法和原則沒有本質上的差別

  • 微服務與SOA的兩點最鮮明差異在于：

    • 傳統SOA架構基于“中心化”的ESB構建，而微服務采用的是系統提供服務的方式實現系統間的互通；

    • 傳統SOA實施的方式是項目制，而微服務是以做產品的方式讓服務在業務發展過程中快速演化；

  • 概念一時爽，問題一堆堆：

    • 微服務化的應用架構的有效服務管控？

    • 分布式事務的難題？

    • 自動化運維和平臺穩定性？

    • 微服務的服務設計？=> DDD

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

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

• 服務中心的三個特征

  • 服務中心是伴隨業務不斷發展的：不做過于超前的設計，也不做過于理想化的架構

  • 服務中心的服務形態多樣化：接口、工具、數據...

  • 一個服務中心還可以進一步劃分：單個服務模塊、多個服務模塊...

• 服務中心的劃分原則

  • 更多靠的是架構設計經驗總結，很難給出精確的量化指標

  • 一般來說會兼顧3個方面的需求：

    • 設計 => 遵循面向對象的分析和設計方法論

    • 運營 => 服務中心應該是一個完整額業務模型

    • 工程 => 綜合評估業務層對服務中心在DB、業務以及運營方面的需求和技術上需要的投入

  • 實際中的一些基本原則：

    • 高內聚、低耦合原則

    • 數據完整性原則：特別強調大數據思維

    • 業務可運營性原則：服務中心是承載業務邏輯、沉淀業務數據、產生業務價值的業務單元

    • 漸進性的建設原則：小步快跑，服務化從簡單開始！

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

Part?5 數據拆分實現數據庫能力線性擴展

• 數據庫分庫分表的實踐

  • 阿里巴巴分布式數據層平臺發展演變：Cobar(2006) => TDDL(2008) => DRDS(2014)，更多阿里中間件的簡介可以轉向這里：http://jm.taobao.org/about/

  • 數據盡可能平均拆分：需要結合業務數據的結構和業務場景來決定

  • 盡量減少事務邊界：“事務邊界”指單個SQL語句在后端數據庫上同時執行的數量

  • 異構索引表盡量降低全表掃描頻率：“拿空間換時間”，阿里巴巴的精衛填海產品

  • 將多條件頻繁查詢引入搜索引擎平臺：采用專業搜索引擎平臺提供搜索服務，Lucene、Solr、ElasticSearch

  • 簡單就是美：“數據盡可能平均拆分”作為第一優先考慮，82法則

我們都有一個印象就是在數據庫開發和調用時，要充分利用索引，避免全表掃描。但是，作者說到在真實的業務場景中很難完全避免全表掃描，比如對于訂單進行復雜的分布式條件檢索的時候，就會需要采用全表掃描，將查詢語句同時推送到后端的數據庫中才能實現該場景。但是，因為調用量不會很頻繁，而且計算的數據量并不大，所以整體上不會給DB產生太大的影響。另外一個點就是，從系統風險的角度來看，以82法則，在實際中，作者建議僅對那些在80%情況下訪問的那20%的場景進行如數據異構索引這樣的處理，達到這類場景的性能最優化，而對于其他80%偶爾出現跨庫join、全表掃描的場景，采取最為簡單直接的方式往往就是最有效的方式。

---

總結

以上是生活随笔為你收集整理的从阿里中台战略看企业IT架构转型之道（上）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。