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

上半部分Part1~Part5請點擊這里

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 共享服務中心對內和對外的協作共享

• 共享服務平臺的建設思路

  • API as Service => 服務化的第一步

  • Product as Service => 大量業務API升級為服務化平臺的組件服務

  • Solution as Service => 經過長時間的沉淀可以形成解決方案，如海外淘寶解決方案

  • Step1.找到一個合適的服務化對象：比如API

  • Step2.建設對象服務化的基礎設施：比如結構化包裝，讓API成為治理良好的組件服務

  • Step3.服務化實施階段：循序漸進的過程，三個階段參考

  • 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架構轉型之道的思考》

---

總結

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

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