一、微服務概述

　　1、SOA：

　　　　SOA的核心內容是ESB，全稱是 Enterprise Service Bus，SOA 通過 ESB 將企業中各個不同的異構服務連線在一起，是 SOA 架構的核心，但是SOA架構是成也 ESB，敗也 ESB。

　　　　ESB的目的是鬆耦合馬也就是減少各個服務間的依賴和互相影響，但是隨著服務越來越多，ESB自身的問題也逐漸顯現，例如邏輯臃腫、效能低下、擴充套件困難等

　　　　　　　　

　　2、微服務：

　　　　微服務的三哥重要特點就是：1、將系統拆分為 Small 服務；2、服務之間通過輕量級機制通訊，例如 HTTP；3、服務能夠快速自動化的部署

　　　　下圖是從服務粒度、服務通訊、服務交付、應用場景和技術本質五個角度對比SOA與微服務的差別。

　　　　　　　　

　　　　目前SOA和微服務並非其中一家獨大，在傳統行業中，由於歷史原因，系統多是外包出去，導致各種語言、協議非常雜亂，同時由於自身開發能力較弱，因此用SOA較多，而在花聯網公司，系統大多數是自建系統，其自身開發能力較強，因此採用微服務較多。

 　　3、可擴充套件架構

　　（1）分層架構與微服務

　　　　分層架構是端到端的架構或者單個系統的內部架構，按照某種規則劃分為不同層級，例如按照業務劃分的端到端架構、按照客戶端/服務端劃分的B/S或C/S架構、按照J2EE架構分層劃分的四層架構

　　　　　　　　 

　　（2）微服務與分層架構 　　

　　　　在分層架構中，微服務一般是端到端分層架構中的業務層的架構，一般不會用於其他的層，因為微服務一般就是用來實現業務可擴充套件的架構。

　　　　　　　　

　　5、整潔架構與微服務

　　　　Bob大叔在其《架構整潔之道》中提出的整潔架構，最內層的Entities可以理解為領域模型，然後外面一層是Use Cases，可以理解為業務邏輯，在外面一層是Controller，其負責對接介面，包括對Web的介面、對UI的介面、對DB的介面等等，最外層就是各種DB、裝置等等

　　　　　　　　

　　　　整潔架構和微服務的關係：單個微服務內部可以使用整潔架構，但是不能說整個架構是整潔架構，只能說整個架構是微服務架構，而單個微服務是整潔架構。

　　6、微核心架構與微服務

　　　　微核心架構（Microkernel Architecture），也被稱為外掛化架構（Plug-in Architecture）,是一種面向功能進行拆分的可擴充套件性架構。微核心架構主要包含兩個組成部分：核心系統（core system）和外掛模組（plug-in modules）。

　　　　核心系統負責和具體業務功能無關的通用功能，例如模組載入、模組間通訊等；外掛模組負責實現具體的業務邏輯，具體的業務處理功能需要具體的外掛處理

　　　　　　　　

　　　　微核心架構和微服務的關係：單個微服務可以使用微核心架構，例如在日常落地時，常見的微核心架構有風控、營銷、工作流等場景

 二、微服務架構陷阱與挑戰

（一）微服務架構六大陷阱

　　微服務架構的陷阱主要是由於微服務拆分太細或者基礎設施缺乏導致的，力度太細會影響服務關係、團隊效率和問題定位，而基礎設施缺乏會導致無法快速交付和服務管理混亂的問題。

　　　　　　　　

　　1、拆分粒度太細，服務關係複雜

　　　　需求分析、方案設計、測試、部署……難度都會增加。例如：

　　　　　　（1）分散式服務如何保證資料一致性；

　　　　　　（2）分析設計的時候需要考慮的影響點變多。

　　　　服務拆分太細實際上是降低了服務內部的複雜度，但是增大了外部複雜度。

　　2、拆分粒度太細，團隊效率下降

 　　　　需求分析、方案設計、測試、部署……工作量都會增加。例如：

　　　　　　（1）介面設計數量，1次請求由兩個服務處理，介面數量1個，5個服務處理，介面數量4個，介面設計、介面聯調、介面測試等工作量都會大大增加；

　　　　　　（2）某個業務功能上線，需要升級的系統數量會增加。 粗粒度服務 

　　3、拆分粒度太細，問題定位困難

　　　　單個微服務的故障，會導致多個微服務異常，監控系統一片紅，到處都在告警，但是不知道根因。

　　4、拆分粒度太細，系統性能下降

　　　　呼叫鏈越長，單次請求耗時會更長。

　　5、缺乏基礎設施，無法快速交付

　　　　（1）沒有自動化測試支撐，每次測試時需要測試大量介面；

　　　　（2）沒有自動化部署支撐，人肉運維，手都敲麻了；

　　　　（3）沒有自動化監控，每次故障定位都需要人工查幾十臺機器幾百個微服務的各種狀態和各種日誌檔案。

　　6、缺乏基礎設施，服務管理混亂

　　　　（1）服務路由：假設某個微服務有60個節點，部署在20臺機器上，那麼其他依賴的微服務如何知道這個部署情況

　　　　（2）服務故障隔離：假設上述例子中的60個節點有5個節點發生故障了，依賴的微服務如何處理這種情況

　　　　（3）服務註冊和發現：同樣是上述的例子，現在我們決定從60個節點擴容到80個節點，或者將60個節點縮減為40個節點，如何讓依賴的服務知道新增或者減少的節點

　　上述的六大陷阱主要是因為服務拆分太細和基礎設施缺乏導致，那麼解決方法也就呼之欲出，就是合理的拆分微服務和完善基礎設施，在下面第三、四部分會詳細描述如何完善基礎設施和合理的拆分微服務。

（二）微服務架構四大挑戰

　　微服務拆分會涉及資料庫拆分和服務拆分，拆分後資料存在不同的庫中，介面存在於不同的服務中，就會產生資料分佈和服務分佈的問題：

　　　　資料分佈是由於資料分不到不同的庫表中，原來單體服務資料在同一個庫中，可以使用資料庫的事務保證資料的一致性，但是分佈在多個庫中，就需要使用分散式事務來解決，在使用分散式事務時，有可能會失敗重試，那麼就需要做好冪等處理

　　　　服務分佈是由於介面存在於不同的微服務中，有個能當前介面升級，但是有多個服務在呼叫，有的要用新介面，有的需要使用老介面，如何做介面相容是個問題，另外由於介面在多個服務上，有可能發生迴圈呼叫的問題。

　　　　　　　　

　　 　　資料分佈的解決一般會基於BASE 理論做最終一致性處理：

　　　　　　BASE：Basically Available（基本可用）、Soft State（軟狀態）和 Eventually Consistent（最終一致性）。

　　　　　　核心思想：分散式系統由於 CAP 理論限制，無法做到強一致性，但每個應用都可以根據自身業務特點，採用適當的方式來使系統達到最終一致性。

　　　　　　設計關鍵：1. 適當的方式：有哪些方式？分散式系統只有一種方式：訊息。區別只是傳遞訊息的方式和訊息內容的不同，例如訊息佇列、介面呼叫、ZooKeeper 事件。

　　　　　　　　　　   2. 最終一致性：什麼叫“最終”？其實就是從不一致到一致的持續時間延遲。

　　1、分散式事務

　　　　分散式事務的詳細處理和解決方案可以參考我的另外一篇文章：分散式事務解決方案，裡面詳細的介紹了七種常見的分散式事務解決方案，這裡我簡單的列舉幾個：

　　（1）業務級分散式事務 - 本地事務訊息

　　　　　　　　

　　（2）業務級分散式事務 - 訊息佇列事務訊息

　　　　　　　　

　　（3）業務級分散式事務 - TCC

　　　　　　　　

　　2、全域性冪等

　　　　分散式資料只能通過訊息來實現最終一致性，而訊息可能會丟失，因此需要重試，重試就需要保證冪等。

　　　　在保證冪等時，有可能不同服務發出相同的資料，在業務上可能是兩條資料，這種也是需要做冪等處理的，因此，一般會使用全域性冪等，保證每個冪等操作都是全域性唯一的。

　　　　全域性冪等的處理思路有：全域性唯一 ID 和 狀態機，全域性唯一 ID 一般用於增刪操作，而狀態機一般用於更新操作。

　　3、介面相容

　　　　介面相容是指某個微服務的某些介面升級，依賴這些介面的微服務不一定能夠全部同時升級。解決方案：

　　　　（1）介面多版本，直接拷貝一份舊介面程式碼，在舊介面程式碼上修改，介面 URL 加上 v1/v2 這種標識；

　　　　（2）介面邏輯相容，同一份介面程式碼，相容新舊邏輯，容易互相影響，且舊介面下線時又要修改程式碼（不推薦）。

　　4、介面迴圈呼叫

　　　　某次業務處理過程中，A呼叫B，B又過來呼叫A，A的處理又進入了之前的處理邏輯，導致迴圈呼叫，整個業務進入死迴圈。例如使用者登入服務呼叫風控服務進行安全檢查；風控服務又來呼叫登入服務獲取使用者登入地址資訊；獲取登入地資訊的介面又依賴了風控服務進行安全檢查。這就是因為服務拆分，不同的微服務間呼叫導致的問題。

　　　　這種幾乎沒有好的解決方案，運氣好靠測試發現，運氣不好靠上線發現。

三、微服務基礎設施選型

（一）基礎設施選型方案

　　微服務基礎設施架構包括服務接入層、服務執行層、技術支撐層、基礎設施層，按照優先順序排序，服務執行層、服務接入層、基礎設施層、技術支撐層，因為對微服務系統來說，服務註冊、服務發現、服務路由、服務容錯是其基礎和靈魂，其餘的幾個一般都是等服務量級達到一定規模之後才會需要，因此在做基礎設施搭建時，並非一定要把所有的基礎設定搭建完畢，可以按照優先順序逐步落地。

　　在微服務落地的時候，一般都會將開發語言進行壓縮，一般都是1-4個開發語言，這是因為對於基礎設施建設來說，對於不同的語言可能都要搭建一套基礎設施，例如自動化測試、自動化部署這種與語言強相關的基礎設施。

　　　　　　　　

　　微服務基礎設施中最核心的就是服務執行層的服務註冊、服務發現、服務路由，其是微服務的靈魂所在，在具體落地時，可以使用嵌入SDK、反向代理、網路代理等方式來實現。

　　模式一：嵌入SDK

　　　　　　　　

　　　　優點：1. 架構簡單，天然支援高效能、高可用；2. 維護簡單，無需維護獨立的 Proxy 節點。

 　　　  缺點：1. 應用侵入，需要整合 SDK，並聯動升級；2. 多語言重複開發 SDK。

 　　模式二：反向代理式

　　　　　　　　

　　　　優點：1. 應用無侵入；2. 天然支援多語言。

　　　　缺點：1. Service Proxy 需要通過叢集來做高效能、高可用；2. 維護複雜，需要維護 Service Proxy 叢集。

　　模式三：網路代理式（Service Mesh）

　　　　　　　　

 　　　　優點：1. 應用無侵入；2. 天然支援多語言；3. 天然支援架構高效能、高可用。

　　 　　缺點：1. 維護複雜，需要維護每臺伺服器上的 Service Proxy；2. 單臺伺服器的 Service Proxy 是單點；3. 全鏈路請求效能會下降，目前比較認可的效能下降在20%左右。

　　微服務框架模式對比：

　　　　　　　　

（二）常見微服務框架選擇

　　1、嵌入式 SDK 樣例 - Dubbo

　　　　　　　　

 　　　　Apache Dubbo 是一款高效能、輕量級的開源 Java 服務框架，提供了六大核心能力：1. 面向介面代理的高效能 RPC 呼叫；2. 智慧容錯和負載均衡；3. 服務自動註冊和發現；4. 高度可擴充套件能力；5. 執行期流量排程；6. 視覺化的服務治理與運維。

　　　　【出品方】阿里出品，2017年停更過，現在是Apache專案。

　　2、嵌入式 SDK 樣例 - Spring Cloud

　　　　其提供了更完善的解決方案，除了服務註冊、服務發現、服務路由等，還有熔斷器、全域性鎖等等處理

　　　　　　　　

 　　3、反向代理式案例 - APISIX

　　　　這是一款國產的開源軟體，既可以實現南北流量又支援東西向流量，這裡說明一下，通常我們在畫架構圖時，從客戶端到服務端的流程都是從上到下的，這種叫做南北流量，而服務間的呼叫一般是從左到右的，這種叫做東西流量，由於其支援東西流量，因此其可以作為微服務間服務註冊、服務發現、服務路由的選擇。

　　　　　　　　

 　　4、Service Mesh 案例 - Istio

　　　　目前Istio 在 Service Mesh 的解決方案中是一個統治地位的存在，其功能非常強大，例如可以做服務註冊、服務發現、服務路由、監控、安全等。Istio主要分為控制面板和資料面板，資料面板就是流量的排程、請求、分發、路由等等，而控制面板主要是配置、服務發現、認證等等。

　　　　　　　　

　　5、如何選擇開源微服務框架（遇事不決 Spring，選擇太多 Apache！）

　　　　在做微服務基礎設施選型時，如果語言統一為Java，那麼就看是否需要RPC框架，需要的話就選用Dubbo，不需要就選擇Springcloud，如果為多語言，如果叢集不大，則選用APISIX，超大叢集則選用Istio，因為在特大叢集規模下，Proxy方案下，proxy叢集也會變的無比龐大，從而導致成本增大和維護困難，因此就算Istio有一定的效能損耗，在權衡各種問題後，還是會選擇Istio。

　　　　　　　　

四、微服務拆分技巧

　　1、微服務落地的總體思路

　　　　微服務落地主要從服務拆分方式、基礎設施要求、落地方式三個方面。

　　　　拆分方式可以按照業務拆分和質量拆分，基礎設施的要求可以根據自身情況選擇搭建完善的基礎設施還是隻搭建核心的基礎設施，在落地方面，根據人力、時間等因素，可以選擇一步到位，也可以選擇逐步落地　　

　　　　　　　　

　　　　一般情況下，對於微服務拆分的適用場景如下：

　　　　　　從0開始構建的業務系統：一般按照業務拆分微服務，一步到位，同時需要搭建完善的基礎設定，但是會按照優先順序逐步落地

　　　　　　單體架構拆分為微服務：一般也是按照業務拆分微服務，但是會逐步進行拆分，一般先從非核心業務開始拆分，同時也是需要搭建完善的基礎設施，並按照優先順序逐步落地。這裡特別說明一下，一般是從非核心業務開始拆分，因為剛開始拆分可能回踩很多坑，或者拆分後發現拆分的不合理等問題，使用非核心業務可以很好的去做實驗，有很多團隊在實際落地微服務時，反而是先對核心服務做拆分，導致拆分後存在很大的問題。

　　　　　　粗粒度服務微服務化：一般按照質量進行拆分，但是會逐步進行拆分，對於基礎設施，一般會採用重用的方式處理。

　　　　　　區域性系統優化：一般按照質量拆分微服務逐步落地，並且會重用已有的基礎設施

　　　　　　　　

　　2、按業務拆分微服務的技巧

　　（1）DDD

　　　　按照業務拆分時，DDD是一個繞不過的話題，其主要可以分為戰略設計和戰術設計兩步：

　　　　　　戰略設計：1. 確定領域，對應微服務的“子域”；2. 限界上下文，對應微服務的“服務”。

　　　　　　戰術設計：聚合根、實體、值物件：對應面向物件方法的物件；聚合根：核心的有狀態物件；實體：有狀態的物件；值物件：無狀態的物件。

　　　　但是DDD 卻很難落地，核心問題是 DDD 告訴你限界上下文是什麼，卻沒有告訴你如何劃分，例如在為什麼要把這兩個聚合劃在一個限界上下文中而不是分為兩個限界上下文這種問題，特別是DDD的權威書籍中都沒有明確的答案。例如下面摘抄的DDD權威書籍中的描述，分別表述了要麼請業務專家來劃分，要麼和各團隊間達成一致，要麼在人數少的時候不劃分也行，因此，DDD並沒有明確的標準怎麼劃分界定上下文，從而導致其很難落地。

　　　　　　“業務部門或者工作組織的劃分可以很好地標明模型邊界的位置。你將傾向於為每個業務功能尋找至少一位業務專家。”——《領域驅動設計精粹》P21

　　　　　　“團隊必須決定在哪裡定義 BOUNDED CONTEXT，以及它們之間有什麼樣的關係。…… 事實上，這樣的決策通常需要與外部團隊達成一致。……在實踐中，團隊之間的行政關係往往決定了系統的整合方式。”—— 《領域驅動設計》P268

　　　　　　“設計中的整個系統使用一個 BOUNDED CONTEXT。例如，當一個少於10人的團隊正在開發高度相關的功能時，這可能就是一個很好的選擇。”—— 《領域驅動設計》P270

　　（2）實際專案中業務邊界劃分　　

　　　　實際專案中的業務邊界劃分，一般看有沒有業務專家，有的話，就讓業務專家來劃分邊界，如果沒有，再看是否是全新的業務，如果不是，可以參考業界的現有實現，如果是全新業務，可以先粗粒度的劃分邊界再逐步演進。

　　　　

　　　　　　　　

　　　　但是按照每一種劃分邊界的方案都有自己的問題，例如以業務專家意見為準，那如果這個專家很水怎麼辦，今天抄微博、明天抄QQ、後天抄陌陌，一般這種情況就需要從行業內挖人才了；如果是新業務採用的先粗粒度劃分後續持續演進的方法，有可能開始拆分的太粗導致頻繁演進，這種一般可以使用三個火槍手的原則進行拆分，如果是非新業務，參照行業已有業務劃分，有可能由於技術、公司情況的原因導致水土不服，這種也可以使用三個火槍手的原則進行拆分。 

 　　　　　　　　

 　　（3）實際專案中如何做微服務拆分

　　　　做服務拆分是，首先按照業務邊界對映成領域，再根據領域推匯出微服務，在推導過程中，可以使用一對一、多對一、一對多的方式進行推導，例如：一對一就是一個領域對應一個微服務，比如訂單域就對應訂單服務，會員域就對應會員服務，商品域就對應商品服務；多對一就是多個領域對應一個微服務，例如商品域和庫存域對應一個商品服務，一對多表示一個域對應多個微服務，例如可以把訂單域分為訂單生成、訂單支付、訂單物流多個微服務。

　　　　　　　　

　　　　那麼在推導過程中，應該選擇哪種模式呢，或者哪種模式更好呢，實際上並沒有說哪個更好，而是要根據自身的情況去拆分，一般情況下根據三個火槍手原則去拆分最為合理。

　　　　　　　　

 　　（4）服務拆分技巧 - 三個火槍手原則

　　　　　　定義：平均3個開發人員負責一個微服務。

　　　　　　剖析：1. 為什麼不是1個？因為沒有備份，且一個人思維有侷限。2. 為什麼不是2個？因為異常情況下剩餘1個，壓力會很大；2個人負責維護一個微服務，微服務複雜度偏低。3. 為什麼不是4個或者5個？如果4個或4個以上，每個人不一定能掌握單個服務所有細節。

　　　　　　技巧：1. 微服務數量 = 服務端開發人數 /3 ；2. 3 = 1 +2，1個有經驗的(P7/P6+)，2個普通的(P5/P6)；3. 處於維護期的服務，維護人員為2人。

　　　　三個火槍手案例：

　　　　　　那麼對於領域推導微服務數量，就看實際的開發人數，如果開發人員多，就採用一對多，開發人員少，就採用多對一，如果開發人員人數剛好，就採用一對一。

　　　　　　　　

　　 （5）拆分方法

　　　　　一對一服務對映：可以剛好一個領域對應一個微服務，例如訂單域對應訂單服務，會員域對應會員服務等

　　　　　　　　

　　　　多對一服務對映：可以將多個領域合併為一個微服務，例如將訂單域、庫存域、財務域合併為交易服務，將店鋪域、商品域合併為商品服務等

　　　　　　　　

　　　　一對多服務對映：上面的一對一和多對一都比較好處理，而一對多服務拆分一般會按照業務流程拆分。

　　　　實際落地時，可以列出核心業務功能的處理流程，將流程中的處理步驟作為拆分的維度。例如以下三個案例，先將交易流程拆分為訂單生成、訂單支付、商家發貨、確認收貨、交易成功五個大步驟，然後再根據三個火槍手的原則來看要把哪些流程放到一個服務中。

　　　　　　方案1：拆分為5個

　　　　　　方案2：拆分為2個，下單（包含訂單生成、訂單支付）、物流（包含商家發貨、確認收貨、交易成功）。

　　　　　　方案3：拆分為3個，下單（包含訂單生成、訂單支付）、發貨（包含商家發貨）、收貨（包含確認收貨、交易成功）。

　　　　　　　　

　　3. 掌握按質量屬性拆分微服務的技巧

　　　　按效能拆分：

　　　　　　方法：根據運維繫統統計請求量排名前3的業務，將流量最大的業務以及強關聯的業務拆分出來。

　　　　　　目的：降低業務互相影響程度，拆分後優化流量大的業務，提升效能降低成本

　　　　按業務重要程度拆分：

　　　　　　方法：將重要程度高的業務拆分出來，注意重要程度高不一定是流量大的。

　　　　　　目的：降低業務互相影響程度，拆分後提升重要程度高的業務的可用性。

　　　　　　案例：兒童電話手錶的電話功能。

　　　　按可用性拆分：

　　　　　　方法：將經常出問題的業務拆分出來。

　　　　　　目的：降低業務互相影響程度，拆分後有針對性的提升問題多的業務。

　　　　按穩定性拆分：

　　　　　　方法：將穩定的業務拆分出來。

　　　　　　目的：降低業務互相影響程度，拆分後有利於不斷變化的業務快速迭代。

五、中臺深入剖析和實現技巧

（一）什麼是中臺

　　1、中臺發展史

　　　　中臺發展史，從下圖可以看到，中臺在國內從09年孕育、15年面世，再到18年集中爆發再到19年的泛濫，然後就是到20年的質疑和到21年之後的迷茫，那麼後續中臺究竟會怎麼發展，現在也是處於一個比較迷茫的階段。

　　　　　　　　 

　　2、共享架構

　　　　無共享架構 - 大煙囪架構：在原來的架構中，每個業務都有一整套的基礎建設和應用，這就是典型的大煙囪架構。

　　　　　　　　 

　　　　共享架構模式1 - IaaS 架構：在大煙囪架構上覆用OS、虛擬化、伺服器、儲存和網路，就組成了IaaS架構

　　　　　　　　 

　　　　共享架構模式2 - PaaS 架構：在IaaS的基礎上再複用執行環境、中介軟體、DB等，就組成了PaaS架構，PaaS架構只有應用和資料是獨立的，其餘都是共享的。

　　　　　　　　

 　　　　共享架構模式3 - SaaS 架構：在PaaS架構的基礎上，將應用和資料也進行復用，就組成了SaaS架構

　　　　　　　　

　　 　　 共享架構模式4 - 中臺架構：而中臺架構跟上面的三種共享架構還不一樣，中臺架構可以分為共享業務和共享資料，而根據這兩種劃分，不同的業務只處理自己特性的業務和資料即可。

 　　　　　　　　

　　3、中臺的定義

　　　　　下面是一些對於中臺的定義：

　　　　　　中臺就是“企業級的能力複用平臺”。—— Thoughtworks 首席諮詢師王健

 　　　　　　中臺是將系統的通用化能力進行打包整合，通過介面的形式賦能到外部系統，從而達到快速支援業務發展的目的。—— 百度百科 

　　　　　　中臺架構，是將企業的核心能力隨著業務不斷髮展以數字化形式沉澱到平臺，形成以服務為中心，由業務中臺和資料中臺構建起資料閉環運轉的運營體系，供企業更高效的進行業務探索和創新,實現以數字化資產的形態構建企業核心差異化競爭力。—— 阿里官方定義

 　　　　上面三種定義到底哪一個是正確的呢，這個不好說，因為中颱可以分為業務中臺和資料中臺，想要很好的理解中臺，就需要從兩個維度分別闡述，如果放在一起解釋，無論怎麼解釋都有可能有點片面

　　（1）理解中臺概念 - 業務中臺（針對相似業務）

　　　　業務中臺是企業內部業務相關的能力共享，主要體現在跨業務和相似業務上。其中跨業務是指業務中臺肯定是跨業務的，單個業務不需要中臺這個概念；相似業務是指相似的業務才可以構建在同一中臺上，差異太大的業務，中臺沒有意義。

　　　　業務中臺總的來說是將企業內多個相似業務的通用業務能力沉澱到平臺，以減少重複建設，提升業務開發效率的一種架構模式。

　　　　IaaS、PaaS、SaaS 都不是中臺

　　（2）理解中臺概念 - 資料中臺（針對所有業務）

　　　　資料中臺應該是支援所有業務的，其核心是資料打通和資料複用。資料打通指的是業務間的資料需要打通，例如通過“統一使用者 ID”來關聯同一使用者在多個業務上的資料；資料複用指的是不同業務間的資料可以複用，提升整體的運營效率，例如：美團可能根據你看電影的資料來向你推薦外賣的商品。

　　　　資料中臺總的來說是將企業所有業務的資料沉澱到同一平臺，支援業務間資料打通以及資料複用，提升企業運營效率的一種架構模式。

　　（3）中臺的價值：

　　　　業務中臺：相似業務的能力共享，避免大量重複開發，提升開發效率。

　　　　　　業務相似度越高，業務中臺價值越大，建議相似度達到60%以上的多個業務共建中臺，例如“快車+專車”，“淘寶+天貓+鹹魚”，”火山 + 抖音 + 西瓜“。

　　　　　　評估業務相似度，需要依賴業務專家，而不是一個單純的技術工作。

　　　　　　強行將相似度低的業務塞進一箇中臺，不但不會提升開發效率，還會大大降低效率。

　　　　資料中臺：資料打通和複用，避免資料孤島，提升運營效率。

　　　　　　使用資料中臺的業務越多，資料中臺價值越大。

　　　　　　資料中臺的價值體現在：統一資料平臺、跨業務的資料打通、跨業務的資料複用（挖掘）。

　　　　　　跨業務的資料複用：理想很豐滿，現實比較骨感，受限於業務熟悉度和組織結構的相關約束。

（二）中臺帶來的問題

　　在中臺建設中，常見的三個問題就是小業務抱中臺大腿，中臺抱大業務大腿；中臺與業務邊界那已明確、中臺全流程效率並不高這三點。

　　1、小業務抱中臺大腿，中臺抱大業務大腿。

　　　　　　　　

　　　　如上圖所示，業務A非常強大，屬於爸爸級別的業務，是中臺 KPI 關鍵，那麼中臺肯定會首先抱業務A的大腿，再例如業務C，也是一個強大的業務，屬於保高績效衝擊更高績效的抓手，再例如業務X，有 P11 大佬站臺的業務，是中臺彙報的重點，那麼也會重點做，至於其他的業務，中臺有可能愛理不理，沒事做就支援一下。

　　　　對於這一現象，目前沒有看到很好的應對方法，中臺建設最後就是一個組織結構問題（康威定律）。

　　2、中臺與業務的邊界難以明確

　　　　中臺和業務的邊界沒有任何明確的規則，都是靠人肉討論，在已有業務基礎上比較容易提煉，創新業務幾乎無法判斷，同時因為創新業務對中臺 KPI 沒有幫助，大部分情況下都會被拒掉，由業務自己實現。因此可以看到中臺適合做“組合式創新”，沒法做“顛覆式創新”。

　　　　這種問題業務上和組織上目前沒有很好的解決方法，技術上可以採用後面的技巧來緩解問題。

　　3、中臺的全流程效率並不高

　　　　在中臺支援業務落地時，每個業務功能都要討論邊界，同時每個業務功能都要考慮對所有業務的影響，一個很小的需求變動都可能需要幾十人參與討論，如果是稍微大一點的需求，有可能需要上百人蔘與討論，因此效率並不會很高

　　　　這個問題業務上沒有什麼解決方法，技術上可以通過後面的技巧來緩解問題。

（三）中臺落地技巧

　　中臺落地時，肯定都是採用微服務搭建業務中臺：微服務不一定是中臺，中臺一定是微服務

　　　　　　　　

 　　1、Pipeline落地中臺

　　在實際落地時，可以使用 Pipeline 封裝不同業務流程，如下面錢包的案例，香港錢包只有解碼、校驗、路由的處理，而澳門錢包有解碼、校驗、碼補充、路由四部分組成，在實際落地時，可以採用Pipeline進行封裝。

　　　　　　　　

　　　　Pipeline 程式碼示例

　　　　　　　　

 　　2、用 SPI 封裝不同業務

　　　　SPI 全稱 Service Provider Interface，是 Java 提供的一套用來被第三方實現或者擴充套件的介面，它可以用來啟用框架擴充套件和替換元件。SPI 的作用就是為這些被擴充套件的 API 尋找服務實現。

　　　　還是用上面錢包的案例，設計出解碼、校驗、碼補充、路由四個介面，不同的業務針對介面做不通的實現，然後中臺使用 SPI 進行封裝

　　　　　　　　

 　　3、Pipeline 和 SPI 方案對比

　　　　下圖是Pipeline和SPI的一個對比，Pipeline實現中，中臺團隊負責框架和實際的業務程式碼邏輯，該實現需要中臺需要全部搞定，開發難度低，並且由於程式碼都在中臺，因此直接統一部署，並且在業務和程式碼層面都做了隔離；而SPI實現中，中臺團隊主要負責框架的設計，具體的業務實現由業務團隊負責，因此業務團隊需要非常熟悉中臺團隊的設計和原理，並且邊界要非常明確，開發難度高，在實際落地時，業務程式碼更新只需要釋出jar包即可，這種實現方案是採用為微核心+外掛的方式做了業務隔離和外掛隔離。

　　　　在下面的對比圖中，從開發模式、開發難度、業務隔離三個維度來說，都是SPI方案會更好一些，但是實際上在落地時，由於開發難度的問題，Pipeline採用的反而更多。

　　　　　　　　

 六、手遊電商平臺微服務實戰

　　1、手遊交易業務介紹

　　　　手遊交易平臺是專門為手機遊戲提供相關交易服務的電子商務平臺，包括帳號交易、遊戲幣交易、裝備道具交易、租號、陪玩（美女+大神）、遊戲禮包、遊戲點卡、遊戲陪練代練、IOS代充、手機充值等等綜合性業務。

　　　　手遊業務的交易型別可以分為寄售交易、擔保交易、求購交易、自助交易幾類。

　　　　　　【寄售交易】：是指賣家將現存貨物的遊戲帳號暫時寄存在交易平臺，有買家購買時，由平臺客服人員直接登入遊戲進行發貨，無需賣家整天守候、上線配合的一種交易方式，也是網遊虛擬物品交易中最便捷、省心的交易方式。賬號、遊戲幣，道具（屠龍刀之類的）常用此類。

　　　　　　【擔保交易】：是指賣家只需在交易平臺上釋出擔保出售資訊，無需填寫遊戲帳號資料，交易時由平臺客服人員通知賣家登入遊戲，與買家交易的一種交易模式。遊戲幣，道具（屠龍刀之類的）常用此類。

　　　　　　【求購交易】：是指買家想要求購某些商品時，交易平臺為買家提供一個平臺釋出求購資訊，同時買家將求購資金 存放在交易平臺，賣家根據買家釋出的求購資訊，找到合適的商品後承接交易的一種全新交易模式。

　　　　　　【自助交易】：是指類似於淘寶交易的一種交易方式，由買家和賣家自行交易，交易平臺僅提供一個商品釋出和購買的平臺，不參與交易過程。陪練、代練、陪玩用常用此類。

　　2、手遊交易服務當時情況

　　　　　　單體架構，團隊開發人員25人左右，開發週期和測試周期都比較長。

　　　　　　各種疑難問題很多，收集了一個問題 Excel 表格，大約100條。

　　　　　　每逢假期必出問題，效能扛不住，資料庫撐不住。

　　　　　　爬蟲經常導致系統掛掉。

　　3、問題分析及解決方案

　　　　微服務並不是所有問題的解決方案，需要根據具體的問題做具體的解決方案，例如上面的問題一一進行分析：

　　　　　　單體架構，團隊開發人員25人左右，開發週期和測試周期都比較長。解決方案：這個沒什麼可說的，就是服務拆分，做微服務

　　　　　　各種疑難問題很多，收集了一個問題 Excel 表格，大約100條。解決方案：這個要看具體的問題點，例如有的是單一系統的問題，那麼可以使用微服務拆分來解決，有的是因為不規範使用元件導致的，那麼可以使用元件化，因此該問題的解決方案就是 元件化 + 微服務

　　　　　　每逢假期必出問題，效能扛不住，資料庫撐不住。解決方案：效能扛不住最快最有效的解決方案就是採用救火方案，例如加機器等，在後續要逐步的對效能做優化，因此該問題的解決方案就是 救火 + 效能優化

　　　　　　爬蟲經常導致系統掛掉。解決方案：冷熱資料分離，讀寫分離

　　　　針對問題的分析和對應的解決方案，指定了三個階段：

　　　　　　第一階段：救火階段，例如機器擴容、業務降級、立體化監控等

　　　　　　第二階段：元件化階段，例如快取元件化、訊息佇列元件化、服務中心元件化等

　　　　　　第三階段：解耦，也就是為服務拆分，例如將核心業務和非核心業務分離，組建業務中臺，公共功能元件化等。

　　　　　　　　

　　4、服務拆分方案　　

　　（1）微服務第1式 - 按業務重要程度拆分

　　　　可以按照業務的重要程度進行服務拆分，例如該案例就是使用哪個業務的營業額大就算是重要業務，例如營業額前三的業務是賬號、道具、遊戲幣，那麼就優先將這三個服務進行拆分。

　　　　當時拆分的方法是先拆服務，後拆資料。實際上這並不是最佳實踐，例如在當下，微服務的案例已經非常成熟，先拆分服務再拆分資料可能會導致二次拆分，雖然每一次拆分會比較簡單，但是兩次合起來反而會更復雜。

　　　　　　　　

 　　（2）微服務第2式 - 按業務穩定性拆分

　　　　例如商家服務和客服服務已經非常穩定，可以優先考慮將這兩個服務拆分出去，其他還在快速疊的功能不要影響已經非常穩定的功能。

　　　　　　　　

 　　（3）微服務第3式 - 按業務領域拆分

　　　　最終所有的功能都按照業務領域進行拆分。

　　　　　　　　 

 　　5、手遊交易中臺

 　　　　由於手遊交易有很多入口，例如自由的Web、小程式、App，集團有的淘寶、鹹魚，那麼如果對接這麼多的入口呢，當時想的方案就是採用手遊交易中臺來解決。

　　　　　　　　

　　　　手遊交易平臺具體如何落地，當時設計了三種落地方案：

 　　　　（1）手遊交易中臺設計思路1 - 理想型

　　　　　　將各個微服務名稱改一下，例如服務層將客服微服務改名為客服中心，專案層將手遊交易平臺改為手遊交易平臺，這種方案也是很多公司在做中體時的落地方案。

　　　　　　

　　　　（2）手遊交易中臺設計思路2 - 嵌入式：

　　　　　　由於集團本身有電商中臺，其本身就支援Web、小程式、App、淘寶、鹹魚等多個入口，那麼將手遊交易直接嵌入到集團的電商中臺即可。

　　　　　　這種方案在落地時有很大的問題：

　　　　　　　　業務差異大、資料模型不通，例如：電商中臺的商品分類是一級類目、二級類目、三級類目，而遊戲商品分類：類目-遊戲-平臺-賬號-區服。

　　　　　　　　業務相似度不高：手遊交易是虛擬發貨，實物電商是物流發貨，業務相似度不高，如何相容？

　　　　　　　　中臺限制創新：手遊交易微信生態是大頭，切換到阿里電商中臺，微信賬號和微信支付都不能用

　　　　　　　　

 　　　　（3）手遊交易中臺設計思路3 - 打通型：

　　　　　　手遊交易中臺和電商中臺將資料打通。

　　　　　　這種方案在落地時也有很大的問題：

　　　　　　　　業務差異太大，資料模型不通，怎麼改造？遊戲商品分類：類目-遊戲-平臺-賬號-區服。

　　　　　　　　手遊交易是虛擬發貨，實物電商是物流發貨，如何相容？

　　　　　　　　兩個平臺如何保證資料一致性？例如：一件商品兩邊都賣會超賣，只放一邊賣會導致成交機會下降。

　　　　（4）中臺思路對比

　　　　　　下圖是三種中臺落地方案的對比，首先從影響範圍上說，理想型需要鹹魚、淘寶接入手遊交易中臺，而嵌入式的需要手遊交易融入電商中臺，打通式電商中臺和手遊交易平臺都需要改造；從業務生態來說，理想型能夠適用各種生態，嵌入式就是能適用阿里的生態，打通式也可以適用所有生態；從改造成本來說，理想型方案中，鹹魚和淘寶的改造太大，嵌入式方案中，手遊交易平臺改造成本很大，而打通式方案中兩邊都要改造，總成本也很大。

　　　　　　根據對比方案最終做出決策，從影響範圍來看，理想型讓鹹魚和淘寶接入手遊交易平臺，這個肯定不可能，因為已經有電商中臺，不可能再接入手遊交易中臺；從業務生態來說，直接排除嵌入式，因為手遊交易最大的業務來源於微信交易，而嵌入式自斷一臂的做法不可取；從改造成本來說，三種方案相差不大。

　　　　　　總和上述決策方案，最終選擇的落地方案為打通式。

　　　　　　　　

 　　6、其他中臺設計思路

　　　　以某輕奢品牌設計思路為例，其採用的是隔離型策略，總體方案是電商中臺和自營中臺兩套生態，各自運營。具體的落地方案如下：

　　　　　　同樣的商品，通過人工庫存拆分，分配到不同的生態。每個生態都有對應的運營人員，資料不打通，各自顯示各自的銷量和評價。

　　　　　　　　

　　　　那麼就有一個問題，為什麼輕奢品牌可以這麼做，而手遊交易不能這麼做？這是因為該案例和手遊交易從業務上還是有本質的區別的，例如在本案例中，有一千個名牌包，其中400個在自營平臺售賣，另外600個在電商中臺售賣，或者數量交換一下也行，只要數量相差不大，使用者在哪個平臺看到的評價都差不多，至於銷量沒有彙總則影響不是很大，而對於手遊交易平臺來說，賬號或者裝備都只有一個，在一個平臺交易後就不能在另外的平臺交易，那麼資料同步就是設計的關鍵，因此不能採用這種隔離型策略。