企業IT架構轉型之道
2018-6-23 張子陽 推薦: 3 難度: 4
近期公司在做一些後臺架構方面的改造，例如對數據中心，數據採集/傳輸/清洗/存儲方面的優化，因此，我想有必要了解一些其他公司是如何做系統架構和轉型的，於是購買了這本書。通讀完以後，對阿里的中臺架構有一個鳥瞰式的瞭解，也瞭解到了其中的龐大和複雜。這樣的系統規模，對於大多數公司都是難以實現的，既難以開發也難以維護，畢竟很少有公司達到阿里這樣的量級（不管是面對的客戶訪問量還是技術人員的數量）。但是，從這本書中，至少看到了架構的一些演化過程、可能遇到的問題、可選的解決方案。這樣，在公司逐步發展時遇到類似問題時，至少有一個解決問題的方向，然後按這個方向再去尋找具體的解決辦法。
下面是書中講到的一些對我有所啓發的知識點：
共享事業部
這本書主要講“中臺戰略思想與架構”，那麼什麼是中臺？在這本書中，中臺的概念主要是指“共享服務”，負責的部門是一個獨立的事業部：共享業務事業部。這個事業部主要包含的幾大部分有：用戶中心、商品中心、交易中心、評價中心、店鋪中心、搜索中心、營銷中心等。它的上游，是天貓、淘寶、1688、阿里去啊、菜鳥物流等前端業務部；下游，是阿里雲平臺，包括彈性計算服務、關係型數據庫服務、消息隊列服務、開放存儲服務、開放緩存服務等IT基礎設施。
企業項目架構的演化
- 傳統的“煙囪式”的架構方式，項目林立，各自擁有孤立的數據，彼此之間數據打通和同步耗時費力。
- 採用SOA的架構方式，各個項目和系統通過ESB（企業服務總線）進行消息通信。
- 去中心化的微服務架構，各個服務彼此獨立和自治，服務之間直接調用。
怎麼叫懂業務？
當說到開發人員“不懂業務”時，開發人員往往會說：系統都是我們開發的，具體流程、操作、數據模型方面，甚至比業務部門更懂。而實際上所謂的懂業務，應當是指：能對業務的下一步發展有自己的理解和看法，對業務流程如何進一步優化能更好地提升業務有獨到的見解，甚至對企業現有的業務提出創新的想法，爲企業帶來新的增長點。
集羣雪崩
假設有一個5臺服務器的集羣，負載都達到了80%；此時如果1臺故障，那麼其餘4臺負載都將達到100%，這樣其餘4臺也變得不穩定，此時如果1臺掛掉，就會引發雪崩效應：其他三臺負載（133%）全部掛掉。當集羣因爲不堪重負掛掉之後，此時又會面臨一個重啓的難題：除非5臺同時啓動，否則，當1臺先啓動時，就會立即因爲過載而掛掉。因此，就需要先關閉前端的網關，待集羣中的服務器全部啓動後再打開。
異構索引表
當數據量很大時，通常都會進行分庫分表，比如說企業中常見的訂單表。常見的訂單表包含下面的字段：
訂單號，賣家Id，買家Id，訂單金額，下單時間。
常見的一種分表方式，就是對單號哈希後取模，例如分8張表，則對單號除以8，根據餘數存到對應的表中。這種方式在對單號查詢時異常迅速，因爲只要根據單號得到要查詢的分區表，然後去分表中查詢就可以了。
但是，對於其餘幾種常見的查詢，卻要進行全表掃描。例如，查詢某位買家、某位賣家，或者某個時間段內的訂單。此時，可以通過構建一個冗餘的異構索引表來完成。例如，建這樣下面一張表：
買家Id，訂單號
然後再根據買家Id進行哈希後取模進行分表。這樣當需要查詢某個買家的訂單時，則分爲了三個步驟：1、先根據買家Id，到異構索引表的分表中取得訂單號；2、根據訂單號，到主表的分表中取數據；3、將查詢的訂單結果進行聚合返回給調用者。
分佈式事務
CAP理論：一個分佈式系統最多隻能同時滿足一致性（Consistency）、可用性（Availability）和分區容錯性（Partition tolerance）這三項中的兩項。
實現的機制是擁有一箇中心的事務協調服務。假設有一次客戶端的請求，需要依次調用兩個服務A、B，這兩個服務分別修改各自數據庫中的表 X，Y。
- 在調用服務A，執行對錶X的操作前，解析 Insert/Update/Delete語句，將要修改的記錄保存一份，標記爲Undo，用於將來回滾。
- 執行實際的SQL語句，執行完成後，將修改後的記錄保存一份，記爲Redo。作爲回滾前的校驗（可能存在其他線程在回滾前將數據修改了，此時記錄值將會與保存的Redo記錄不一致）。
- 調用服務B，如果服務B執行成功，則刪除 Redo/Undo 記錄；如果服務B執行失敗，則對服務A進行回滾。
回滾的步驟爲：
- 對比Redo與當前記錄是否一致，如果一致，則使用Undo日誌進行回滾。
- 如果不一致，說明數據被其他線程更改了，此時無法自動回滾，應該拋出異常（或者發出提醒），需要人工干預。
服務調用路徑和記錄
設想一下，當一次請求調用了數十個微服務時，排錯和調試將會是非常困難的一件事情。因此，需要一個統一的方法，來記錄服務的調用鏈路（通過唯一的TraceId）。
類似於高速公路，幾點幾分到達了哪個收費站，交了多少費用（行駛了多少里程）。對於微服務而言，則是幾點幾分調用了哪個服務，上一個服務執行了多長時間。與高速公路不同的時，服務還有有個“並行度”的概念，即幾個服務同時執行。
這個很類似於當我們使用Chrome瀏覽器時，按下F12鍵時，看到的資源加載的順序、並行度和調用時長。
Chrome瀏覽器查看資源加載的順序、並行度和時長
阿里有一個鷹眼系統專門進行這件事，但是我們公司暫時還沒有實現，以後如果全面微服務話，這樣的基礎組件也是必不可少的。
服務能力輸出
書中的最後介紹了兩個案例，即阿里的技術能力輸出，幫助大型企業進行互聯網技術的轉型。實際上，阿里雲已經是阿里進行技術輸出的一個典型了。之前這些技術都是阿里內部使用，最終成熟穩定後，開始向外部輸出。對於企業來說，減少了運維的工作，對阿里來說，創造了新的業務點，可以說是雙贏的。
對於普通規模的公司而言，雖然不一定像阿里那樣輸出IT基礎設施服務（雲服務、數據庫、緩存等），但是卻可以將一些業務服務打包起來，向下遊或者同業的小型公司輸出，提升其開發效率和穩定性，做得好的話也是雙贏的。
感謝閱讀，希望這篇文章能給你帶來幫助！