企業IT架構轉型之道筆記

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

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的服務調用方式的問題：

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

阿裡巴巴分布式服務架構 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%。

謝謝您的閱讀，也歡迎關注本公衆号：

  分類: 企業上雲 好文要頂 關注我 收藏該文 

SammyLiu

關注 - 31

粉絲 - 1067   推薦部落格 +加關注 0 0       « 上一篇： 我的一點企業做雲經驗

» 下一篇： 容器雲平台企業落地之向左走和向右走 posted on 2018-10-10 20:57  SammyLiu  閱讀(8260)  評論(1)  編輯  收藏  

評論:   #1樓 2019-01-30 17:41 | Rabbit_Dale 最近也在看這本書，使用分布式服務相比EBS總線的優勢更明顯 支援(0) 反對(0)        重新整理評論重新整理頁面傳回頂部 注冊使用者登入後才能發表評論，請 登入 或 注冊， 通路 網站首頁。   【推薦】了不起的開發者，勢不可擋的華為，園子裡的品牌專區

【推薦】有道智雲周年慶，API服務大放送，注冊即送100元體驗金！

【推薦】超50萬行VC++源碼: 大型組态工控、電力仿真CAD與GIS源碼庫

【推薦】免費下載下傳 | 超全算法題精解，一本能“線上”程式設計的面試寶典  

相關博文：

· 《企業IT架構轉型之道：阿裡巴巴中台戰略思想與架構實戰》-總結

· 金融企業架構

· .net 大型分布式電子商務架構說明

· Net分布式系統之五：微服務架構

· 企業"資訊化建設"價值

» 更多推薦... 最新 IT 新聞:

· 李國慶釋出忏悔信：我立誓接管當當，不是為自己維權

· 西安交警官宣！“電子證照”＝紙質證件 适用于路面核查

· Lyft将向駕駛員分發約6萬個汽車隔闆 以抵禦冠狀病毒

· Thunderbird 78 穩定版釋出

· 女子被騙後找程式員朋友破解詐騙網站 發現千條受害者資訊

» 更多新聞...   昵稱： SammyLiu

園齡： 5年7個月

榮譽： 推薦部落格

粉絲： 1067

關注： 31 +加關注

《企業IT架構轉型之道》讀書筆記 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%。