《企業IT架構轉型之道》讀書筆記

阿新 • • 發佈：2018-12-30

1 出發點：企業IT系統建設普遍面臨的問題和處境

很多企業面臨的問題和處境：

『煙囪式』系統建設模式。

當業務部門提出業務需求，資訊中心部門進行系統整合商的招投標，再進入到需求收集、需求分析、開發、測試、上線的專案週期中。某種程度上，每個新系統的上線都預示著一座新的煙囪矗立而成。這種完全基於業務需求建設系統的方式，已經成為過去20多年企業建設IT系統的標準流程，導致IT系統建設早的企業內部系統煙囪林立。這正是今天很多企業面臨網際網路轉型難的根結所在。

它帶來三大弊端：

重複功能建設和維護帶來的重複投資。因為大量的功能和業務在多個系統中同時存在，單單從開發和運維兩個方面成本投入的角度，對於企業來說就是一種很顯性的成本和資源浪費。
打通『煙囪式』系統間的整合和協作成本高昂。業界早前就提出了SOA的理念，多家廠商推出了ESB產品及解決方案，重點就是來解決此類異構系統之間的互動問題。
不利於業務的沉澱和持續發展。在傳統IT系統建設模式下，上線的系統就進入了系統維護期，這個時間段實際上是系統對業務需求響應非常不敏感的階段，一般半年或一年才會進行一次系統的升級。也就是說，系統業務需求響應的能力和企業本身業務發展對系統建設的要求不成比例。如果說過去，業務需求的增長態勢還算比較平滑，沒有體現出系統的響應能力有多大差距，那麼在今天，網際網路時代業務需求的增長越來越迅猛，原有系統對業務響應的能力就顯得更加捉襟見肘了。

企業資訊中心的組織職能只停留在『業務支援』上

各個企業都認可資訊科技部門對於企業發展的重要地位，但是，該部門往往不具有與核心部門同等的部門話語權。該問題的核心是，IT資訊部門在現有模式下已經被更高的領導層定位成了業務支援部門，是一個花錢的成本中心。

作者認為，造成這種困境的原因是因為IT資訊部門的人員不懂業務。作者所說的『懂業務』是指能對業務的下一步發展有著自己的理解和看法，對業務流程如何進一步優化能更好地提升業務，甚至對企業現有的業務提出創新的想法，為企業帶來新的業務增長點。

而其根本原因，是因為很多大型企業的IT資訊化部門已經存在了20多年，一成不變的就是專案制的系統建設模式，這樣建設專案的模式除了帶來『煙囪式』建設的一系列弊端，同時使得IT資訊化部門一直處於『業務支援』的職能位置，即只為了滿足業務部門需求而進行IT系統建設的實施和運維部門。這種模式下，很多企業的IT資訊化部門的員工大多數的工作內容都是專案管理。當一個專案順利上線驗收後，這些員工開始投入到下一個專案的工作中。因此，其結果是，員工增長了專案經驗，但並不能在某一專業領域得到了知識和經驗的沉澱，其最終結果是IT資訊中心的員工很多少能在一個業務領域做足夠深入的瞭解和業務沉澱。

這些問題是如今大多數企業都遇到的問題，阿里巴巴在2008年業務系統的建設模式、組織架構以及遇到的問題，都和大多數企業是一樣的。

2 解決之道：共享式業務中臺

阿里巴巴電商系統的架構經歷了煙囪式架構，到分散式架構，再到共享式架構的轉變。

當前的阿里巴巴『厚平臺，薄應用』架構形態如下圖所示。目前阿里巴巴集團前端超過了25個業務單元，比如淘寶天貓聚划算等，均不是獨立地構建在阿里雲的雲平臺之上。在後端阿里雲技術平臺和前端業務之間有了一個『共享業務事業部』，將阿里巴巴集團前端業務中公共、通用的業務沉澱到了這個事業部，包含額使用者中心、商品中心、交易中心、評價等十幾個中心。共享業務事業部正是『厚平臺』的真實體現，為阿里巴巴各種前端業務提供著相應服務中心領域內最為專業、穩定的業務服務。

3 價值：擺脫『煙囪式』系統建設帶來的各種困境

共享服務架構的建設，使得阿里巴巴擺脫了因為『煙囪式』系統建設方式帶來的各種問題，最終成為阿里巴巴業務中臺戰略的核心組成。

1. 迴歸 SOA 的本質 - 服務重用

作者非常認可SOA的理念，但是SOA在落地時候變了味。具體表現在：

SOA 在企業落地時，無一例外都是通過ESB（企業服務匯流排），使各個系統以服務封裝或服務呼叫方式實現了不同系統見的業務互動。其本質上，僅僅是採用了服務的形態，以技術的視角選擇了一個科學的方式實現了系統互聯。
這對於企業中業務服務的持續發展和沉澱沒有任何幫助，根本就沒有實現SOA理念最核心的架構：鬆耦合的服務帶來業務的複用，通過服務的編排助力業務的快速響應和創新。
SOA 理念的提出，原本是真正為企業的IT系統建設指出一條光明大道，真正提現SOA核心價值的正是這些服務，只有這些服務在業務發展過程中得到持續的演進、功能逐步完善和增強，最終變為企業在該領域最為專業的IT資產時，才能真正打到SOA中所描述的業務的快速響應，更好地支援業務創新。但實際上，SOA的專案都淪為了實現多個系統之間的整合。

而阿里巴巴已經將集團20多個核心業務中的公共的、通用的業務以服務的形式沉澱到了共享業務事業部。整個集團的核心業務能力均建立在這樣一套共享服務體系之上，使得SOA架構的核心價值 - 服務用重用得以實現和發揮。

2. 服務被業務不斷滋養

要解決的問題：『煙囪式』系統方式以及SOA『專案制』的建設方式，導致了業務得不到沉澱和持續發展，從而造成服務不能真正成為可重用的元件，為業務的快速響應、支援業務快速創新帶來業務價值。

原因：SOA專案是一種整合專案建設的方式，就很容易造成服務提供者面對業務提出更多要求時，考核指標、工作回報都不能得到很好提現，服務提供者主觀上沒有太大的積極性來滿足新的業務需求；再加上如果當初服務設計的功能擴充套件性和業務前瞻性不足，導致有心無力滿足新的需求，結果是這些服務無法再進行功能擴充套件，成為企業『業務穩定』執行的『服務』。

結果：如果一個服務一味追求功能的不變，一定程度上就是固步自封，這樣的做法是在逼著其它系統去建設同樣的輪子。當越來越多的系統都建設自己輪子的時候，之前的服務就慢慢少有人問津，它就會逐步退出歷史舞臺了。

解決之道：服務不需要『業務穩定』，而是需要不停的滋養。只有在滋養中才能從最初僅提供單薄業務功能的服務，逐步成長為企業最寶貴的IT資產，而服務所需的滋養正式來自新的業務不斷進行服務的接入。

做法：阿里巴巴共享事業部的『服務』『滋養』『穩定』這三大價值定位，定義了共享服務的真諦。服務能力的沉澱和體現的業務價值是完全成正比的，需要一個長期、持續的過程。企業不能再走入『專案制』實施SOA專案的誤區，而是需要更多一些耐心，在接下來的業務發展過程中打造這些服務。這就要求新的業務必須接入這些已經產生的服務，為這些服務能夠變得更加專業和穩定帶來急需的需求養分。

3 共享服務體系是創新的土壤，業務中臺賦予業務快速創新和試錯能力

需求：今天所有的企業，應該在網際網路時代具備一種跟網際網路公司一樣的業務快速創新，甚至是試錯的能力。

問題：傳統企業中，一定是需要申報預算和立項來落實業務創新的想法，傳統『煙囪式』的系統建設方式對專案投入的資金和資源自然不會少。在申請大量資金而且專案還有失敗的可能性的情況下，有業務創新想法的人在考慮到失敗帶來的影響時，一定會權衡其中的利弊，大多數人會選擇退縮。

解決之道：利用業務中臺為業務創新提供一個堅實的中臺。通過中臺資源的優勢，支撐業務的快速創新和業務試錯。有了業務中臺後，利用原本就建設好了的專業服務，使得企業在投入少的情況，快速收穫了更多的結果。

4 為真正發揮大資料威力做好儲備

需求：大資料會是展現企業核心競爭力併發掘新的商業模式的推動器。

問題：很多企業的大資料專案並未帶來期望的成效，因為有以下兩個主要問題：

資料分佈廣、格式不統一、不標準。這還得歸咎於『煙囪式』系統建設方式，使得相關業務領域的資料分佈在不同的系統中。這位大資料平臺專案初期資料的抽取和同步帶來了很多的複雜工作。
缺少具有能基於資料進行業務建模的專家。大資料平臺的威力，要有人知道怎麼利用它來發揮出真正的業務價值，這是很多大資料平臺難於落地或真正讓企業感受到器價值的最大障礙。

解決之道：共享服務體系是解決這兩大問題的不二法門。

一方面，通過業務中臺，在各相關領域在業務和資料層做了很好的融合。
另一方面，共享服務體系能幫助企業資訊部門培育出懂業務的專家，這些人有技術功底，隨著業務能力提升，他們能成為能發揮大資料平臺價值的『資料科學家』。

5 改變組織陣型會帶來組織效能的提升

問題：大多數企業的資訊中心部門的職能還停留在『業務支援』的程度，是為企業的業務部門提供IT系統支援的組織。

解決之道：有了業務中臺，整個共享服務體系中的這些服務中心進行持續的『運營』的職能勢必會落在企業資訊中心這個部門。這時，可以將資訊中心部門的員工按照服務中心的方式進行人員組織的重新編排，讓員工在各自擅長和感興趣的業務領域持續發展。

結果：讓資訊中心部門從之前在企業中『業務支援』的組織職能，轉變為基於企業核心業務和資料進行運營的團隊，逐步培養出企業最稀缺的『既精通業務，又熟悉技術』的複合型人才。

4 建設：分散式框架選擇

2007年，淘寶已經擁有超過500人的技術團隊規模，整個淘寶網站是一個幾百兆位元組的WAR包，大小功能模組超過200個。

這帶來了以下幾個問題：

專案團隊間協同成本高，業務響應越來越慢。
應用複雜度已超出人的認知。
錯誤難於隔離。
資料庫連線能力很難擴充套件。
應用擴充套件成本高。

解決以上問題的根本在於業務的拆分。結果，在應用部署形態上，由之前一個幾百兆位元組大小的WAR包部署模式改造成為上百個WAR包獨立部署的服務化架構。

好處：

降低不同模組開發團隊間的協同成本，業務響應更加迅速。
大大降低系統間的耦合度以及整體複雜度，各個開發團隊可專注與各自的業務模組。
避免了個別模組的錯誤給整體帶來影響。
業務拆分後解放了對單資料庫叢集連線數的能力依賴。每一個核心服務中心都擁有各自獨立的資料庫，緩解了之前的資料庫連線瓶頸。
做到針對性的業務能力擴容，減少不必要的資源浪費。

技術選型：SOA ESB 架構還是分散式架構？

SOA 主要特徵：

面向服務的分散式計算
服務間鬆散耦合
支援服務的組裝
服務註冊和自動發現
以服務契約方式定義服務互動方式

傳統SOA ESB的服務呼叫方式的問題：

每一次服務的呼叫者要向服務提供者進行服務互動請求時都必須通過中心的ESB來進行路由。
從邏輯上看，所有服務呼叫都通過服務匯流排，服務匯流排的訪問和計算壓力會非常大。
企業所有的業務都通過服務匯流排方式，則服務呼叫量比較大，所需的網路頻寬要求非常高，企業需要在網路上投入更大的成本。
基於企業匯流排構建的服務體系，會成為企業服務排程的核心樞紐，這可能會導致『雪崩』效應，給整個平臺帶來災難性後果。

阿里巴巴分散式服務框架 HSF：

主要元件：

服務提供者。為了保障服務高可用，一般都是叢集部署。每個HSF應用均是以War包的形式存在，執行在Tomcat容器中。在Tomcat 容器層，已經集成了HSF服務框架對服務提供者或服務呼叫者進行配置伺服器發現、服務註冊、訂閱、失敗轉移等功能。目前，淘寶內部大部分應用的部署方式，還是一個虛擬機器執行一個tomcat容器，每個tomcat執行一個服務應用。
服務呼叫者。這是服務的消費者，大多數也是以WAR應用包的方式執行在 tomcat 容器中。
地址伺服器。由 Nginix 實現。
配置伺服器。負責記錄所有服務釋出和服務訂閱資訊，並將服務相關資訊推送到服務節點上。
Diamond 伺服器。本質上也是一個通用的統一配置管理服務。

5 建設：共享服務中心建設原則

關於『服務中心』的概念：

服務中心一定是不斷髮展的。業務架構是能反應業務變化的，服務中心作為共享架構的核心元素一定也會提現出這種變化。
服務中心的服務形態的多樣性。有人理解的服務中心是狹義的介面服務，這比較片面化，雖然介面是服務最重要的形式。服務中心提供的服務能力，可以分為三類：

依賴於介面的服務
依賴於工具的服務
依賴於資料的服務

服務中心設計的一些原則：

高內聚、低耦合。
資料完整性原則。
業務可運營行原則。服務中心應該是承載業務邏輯、沉澱業務資料、產生業務價值的業務單元。
漸進性的建設原則。服務化架構本來就是一種敏捷的實踐，推薦小步快跑的方式逐步推進。

6 實現：資料拆分實現資料庫線效能力擴充套件

需求：

服務中心需要能很好地支撐將來任何業務場景的訪問效能的要求，而資料庫是最容易產生效能瓶頸的服務元件。

幾個步驟：

淘寶的做法是基於資料庫分庫分表的方式，利用分散式資料庫平臺解決資料庫瓶頸問題。

第一步：資料庫的讀寫分離。拓展了資料庫讀讀的處理能力，整體上也提高了資料庫的讀寫能力，但這樣的架構在主資料庫上的寫能力依然沒法擴充套件。

第二步：當出現單個表的資料量很大的情況，則需要採用水平分割槽的方式對資料進行拆分，即將同一個表中的不同資料拆分到不同的資料庫中。比如，對使用者資料按照使用者 ID 進行 has 取模的方式實現使用者資料平均分到 8個數據庫中，確保了單個數據庫中儲存的資料量在單機資料庫能提供良好讀寫效能的範圍內。

第三步：在2008年，阿里巴巴內部開始了分散式資料庫的研發。

一些最佳實踐：

開發了分散式資料層框架TDDL。針對分庫分表場景，提供了對各種業務場景的支援更加完善，開發人員體驗更加友好，管控能力大幅提升。
資料儘可能平均拆分。在分庫分表場景下，最重要的一個原則就是被拆分的資料儘可能的平均拆分到後端的資料庫中。如果拆分不平均，還會產生資料訪問熱點，這就同樣存在熱點資料因為增長過快而面臨資料單表資料過大的問題。
儘量減少事務邊界。
異構索引表儘量降低全表掃描概率。一個解決思路是『拿空間換時間』。
將多條件頻繁查詢引入搜尋引擎平臺。
簡單就是美。

7 實現：使用非同步化與快取

業務流程非同步化

問題：淘寶的訂單建立流程需要呼叫超過200個服務。如果是全線性呼叫，即使每個服務的響應時間都在20ms之內，那麼全部流程也會超過4秒。這對客戶來說難以接受。

解決之道：流程非同步化。

總結：在分散式服務架構中，通過業務流程非同步化，即通過服務非同步呼叫的方式讓業務流程中業務邏輯上允許同步執行的服務同時被呼叫，從而解決了大量遠端服務線性呼叫帶來的效能問題。

2 大促秒殺活動催生快取技術的高度使用

需求：平臺如何完美支援大促秒殺場景是一個體系工作，牽涉到應用架構設計的合理、平臺穩定性報障、極強的系統擴充套件能力等多個方面。其中，利用快取技術實現商品資料的高效能讀取，以滿足秒殺活動中對商品資料訪問的同時不會出現商品超賣等嚴重的業務問題。下圖是商品秒殺架構示意圖：

示例：在小庫存商品秒殺場景下的示例：

流程：

1.1：使用者通過商品詳情頁檢視商品時，獲取的商品基本資訊以及庫存是從快取Tair 中獲取的。
2.1：當用戶檢視到當前商品還有可賣庫存時，進入到 Buy 商品下單介面，此時商品的相關資訊依然還是從快取獲取。
3.1：使用者在進行下單操作後，此時就通過資料庫本機事務操作的方式，通過商品中心的服務（IC）獲取到當前商品的真實庫存資訊。
3.2：當此時獲取的庫存大於 0 時，則進行庫存的扣減操作。
3.3：通過該步驟更新了商品資料庫中的庫存資訊
3.4：在3.3 步驟的同時，也更新快取中該商品的庫存資訊。此時，前方使用者再訪問該商品資訊時，看到的就是已經更新了的資訊。

7 服務治理：通過鷹眼平臺跟蹤服務呼叫鏈

業務服務化帶來的問題：

分散式服務體系建設後，整個淘寶平臺變成了一個複雜無比的服務互動鏈路網。這會帶來很多問題，比如：

如何對每天發生的幾千億次服務調用出現報錯時快速定位問題。
如何實時監控到服務的執行狀態是否正常。
如何給運營團隊關注的業務指標提供實施呈現以便他們進行實時的精準營銷。

解決之道：

對於分散式服務呼叫跟蹤方面的需要，阿里打造了針對分散式服務呼叫鏈的跟蹤平臺 - 鷹眼。它通過一套分散式日誌平臺實現對服務呼叫鏈路的跟蹤，基於阿里巴巴海量日誌分散式處理平臺 TLog。
它是JStorm 流式計算引擎，對應用叢集接收到的日誌進行內容的解析拆分，按照不同業務場景的需求將拆分後的資料儲存到不同的儲存系統中。
其原理是通過服務呼叫鏈各服務處理節點生成相應的日誌資訊，通過同一請求中生成的日誌具有同一個ID將不同系統或服務孤立的日誌串在一起，重組還原出更多有價值的資訊。

價值：

服務實時監控。通過在應用的不同層次進行埋點日誌的列印，鷹眼平臺可以實現從應用入口、服務層、服務方法層的精細管控。結合監控報警能力，鷹眼可以實現異常報警。
服務呼叫鏈跟蹤：鷹眼可以幫助運維人員在Web介面上清晰還原出每一次業務請求所產生的服務鏈呼叫情況。該功能著重於對業務鏈路資料的實時監控。這既能幫助快速定位問題，還能對應用的優化分析帶來幫助。正是有了呼叫鏈跟蹤功能，阿里巴巴的服務化平臺從一個無服務管控狀態變成為一個具備真正可管可控的狀態，形成了完善的服務化管控體系。
服務呼叫鏈分析。這是針對業務架構訴求的服務呼叫鏈分析功能，讓業務架構師對於自己設計的業務鏈路在實際生產中的執行狀況有一個直觀的瞭解。該功能著重於對服務呼叫資料按照不同維度進行離線的統計和分析。利用分析出的資料，可以更針對性地優化業務鏈路流程，或提升某些服務的服務質量，給使用者提供更好的使用者體驗。
業務全息排查：這本質上是將服務鏈路資訊與業務事件進行了整合，將業務事件通過服務呼叫鏈的 traceID&rcpID 進行雙向關聯。
業務實時監控：將發生的業務指標變化在秒級就體現在業務大屏上。有了這樣的業務實時大屏，給市場運營人員提供有價值的參考資料，真正對企業的運營提供了精準有效的資料支援。

8 服務治理：通過多種措施保證平臺穩定性

1. 限流與降級：

阿里巴巴的 Sentinel 平臺提供了限流和降級功能。它為整個服務化體系的穩定執行行使著警戒任務，是對資源呼叫的控制平臺，主要涵蓋了授權、限流、降級、呼叫統計監控四大功能模組。
限流：其作用在當過載的時候掐掉一些流量，讓系統有能力集中資源以較快的速度處理平臺處理範圍內的業務請求。
首先需要採用壓力測試的方法對系統進行壓測。阿里巴巴開發了線上壓測鞏固，來獲取該服務所能提供的最大處理能力。
然後對服務資源的使用情況進行監控。在實際中，都會通過服務的QPS作為限流的關鍵判斷指標。
將資源監控的指標與之前獲得的服務處理上線進行比較，如果超過服務處理上限，則啟動限流。
阿里巴巴是通過在 Nginx 上實現的擴充套件元件 TMD 實現了接入層限流。
降級：判斷依賴的資源的響應情況，當依賴的資源響應時間過長時進行自動降級，並在指定的時間後自動恢復呼叫。
監控：提供了全面的執行狀態監控，實時監控資源的呼叫情況，包括QPS，響應時間，限流降級等資訊。

2.流量排程：

目標：針對分散式服務系統的流量排程平臺，用於遮蔽所有機器的軟硬體差異，根據機器的實時服務能力來分配機器的實時流量。

原理：通過秒級獲取伺服器系統執行指標以及業務指標，通過流量排程平臺設定的決策演算法以及規則，當發現滿足規則條件的指標狀態發生時，對線上環境的伺服器進行下線等操作，以遮蔽這些單點或區域性出現故障的應用例項對整體平臺產生擴充套件式的影響。

3.業務開關：

Switch 是一個輕量級的開關整合框架，用來集中管理叢集各應用的開關，統一業務操作業務開關的方式和API，方便進行集中化管理。

4.容量壓測及評估規劃：

需求：要知道一個平臺的處理能力是否能支援大促活動的訪問量，最常見的方式是對平臺進行效能測試。
容量壓測：將線上真實的流量引流到壓測目標伺服器上，來獲取單機QPS能力。
容量規劃：利用服務的單機QPS資料，結合對各種伺服器機型處理能力的差異化分析，對到底需要部署多少線上伺服器資源才能滿足大促活動有更準確的預測。

5.全鏈路壓測：

這是阿里全系統每個環境都參與的雙11實戰演習，主要對零點峰值流量進行評估，以及網站承壓能力進行測試。

6.業務一致性平臺：

平臺還是偶爾會出現業務與資料不一致的問題。
阿里巴巴利用BCP 平臺來解決該問題。

9 服務治理：治理平臺 - 共享服務平臺

服務化野蠻發展帶來的問題：

服務的數量和業務覆蓋範圍越來越大。
應用和業務架構越分越細，服務越來越專業化，跨領理解的成本越來越高。
服務安全控制層缺乏。
開發體驗很不友好，產品在接入流程，開發使用手冊建設非常之差。
整體服務體系缺乏一個統一的服務治理層。

上面這些問題，可歸結為一個問題，服務治理。針對這些問題，集團的共享服務平臺 SPAS 應運而生，其目標是對阿里巴巴集團的服務更好地進行治理和共享。

主要功能：

服務的描述元資料
服務註冊與發現機制
服務的訪問控制與安全策略
應用服務 portal
服務依賴與運維管理
服務SLA協議
服務消費者的管理與支援
服務化輔助工具支援
服務呼叫分析與報表
服務成本核算與服務能力變現
文件與開發工具支援

SPAS 也是一個協作的平臺，是以服務為物件建立的一個線上市場。其中有三個角色：服務共享平臺、服務提供者、服務消費者：

三個角色之間的協作方式：

示例：業務中臺與前端應用協作：

業務中臺對前端核心業務的緊密溝通機制。各個服務中心的核心架構師和運營人員會定期參與前端業務方的業務會議或重大專案的研討會。這樣，讓業務中臺對於前端重要應用的業務發展動向有一個準確及時的瞭解，從而為業務中臺如何更好地支撐這些業務做好準備和服務能力的提升。
建立分歧升級機制：因為兩方所處崗位和訴求的差別，有時難免對於講一個業務功能的實現放到業務中臺還是在前端應用中實現存在分歧。此時，一般按照業務負責的層級關係依次升級。
崗位輪動推動真正換位思考：將業務中臺某服務中心的負責人與對口業務的負責人進行崗位對調，讓雙方在實際工作中更真切地感知到出於不同崗位時對業務的理解和出發點。
業務持續沉澱及共建模式：業務中臺是一個不斷沉澱，不斷完善的過程。在進行業務沉澱到中臺的過程中，又會出現兩種情況：

一種是業務中臺現有的人員對於要沉澱的業務功能自身就有較強的業務能力，能夠很好地完成將業務功能沉澱和融入到業務中臺的能力，這是一種業務沉澱的典型方式。
另一種則是對於要沉澱到業務中臺的業務，業務中臺現有人員沒有足夠的業務理解和能力，此時，就會採取共建的模式，業務中臺和前端應用方各自派出人員共同組建一個團隊，一起負責該業務功能的實現，以及到中臺的能力沉澱。

業務中臺的考核機制：

服務穩定是重中之重。40%。
業務創新推動業務發展。25%。
服務接入量是衡量服務價值的重要考核。20%。
客戶滿意度促動服務的提升。15%。

謝謝您的閱讀，也歡迎關注本公眾號：