目前正在做業務中臺，但是面對較多接入方（有前面的也有後面的），感覺做的非常的累，看不到自己在做什麼（只有無窮多的需求）？業務中臺到底解決了什麼問題？
所以在建設中臺前，第一個要問自己的就是：我們建設中臺，願景是什麼？而且更重要的是這個願景是需要所有的角色，上到企業管理層，下到每一位中臺的相關人員都要明確並達成一致的。
明確中臺的用戶和客戶是誰？（避免被動）
中臺建設雖然需要兼顧各方的利益，但更多主要還是解決企業管理層對於公司長期生存與可持續發展的恐懼與焦慮問題（避免成爲各方的外包，要聽得進別人的化，但是還要明確自己的目標，走自己的路）
中臺的目標怎麼驗證？
阿里中臺考覈（不能完全借鑑）： 40%穩定 + 25%業務創新 +20%服務接入量 + 15%客戶滿意度
業務中臺（引用他人）：
我們常提到的業務中臺，是狹義層面的業務概念，業務中臺需要具體承載支撐業務開展的必要業務元素，封裝着爲了保障業務可以順利開展需要解決的必要問題空間的解決方案。
目的
1.在當年這樣一個互聯網時代，用戶纔是商業戰場的中心，爲了快速響應用戶的需求，藉助平臺化的力量可以事半功倍。
2.提高用戶響應力，不斷抽象沉澱自己核心的底層能力，通過平臺化包裝，得以更好地賦能前臺業務，用底層的確定性來幫助企業對前臺業務以及最終用戶需求的不確定性。
3.平臺化，並且讓不斷對自身進行治理演進、打破技術邊界、逐漸擁抱業務、容納業務、具備更強的業務屬性的過程。中臺關注爲前臺賦能，真正爲前臺而生。
前臺：由各類前臺系統組成的前端業務平臺。每個前臺系統都是一個用戶觸點，大多是企業最終用戶直接使用的系統，是企業與最終用戶的交點。例如用戶直接使用的網站、手機 App、微信公衆號、小程序等都屬於前臺範疇。
後臺：由後臺系統組成的後端支撐平臺。每個後臺系統一般管理了企業的一類核心資源（數據 + 計算），例如財務系統、產品系統、客戶管理系統、倉庫物流管理系統等，這類系統構成了企業的後臺。
並不是主要服務於前臺系統的業務創新，而是爲了後端資源的電子化管理，解決企業管理的效率問題。大多數企業已有的後臺，要麼前臺根本就用不了，要麼不好用，要麼更新速度就根本跟不上前臺的業務發展的節奏。總結“慢”和“貴”。
背景歷史：
Middle Office （阿里）2018，天貓+淘寶，重複減少涉的問題，煙囪式系統架構->重複建設和資源浪費->重複組織和系統進行整合。阿里共享事業部誕生，爲各個前臺系統公告部分進行平臺化改造->痛苦，夾縫->聚划算爆發的契機->阿里共享事業部重要地位。
思考：
1.互聯網龍頭企業（阿里、京東、騰訊）的樣板效應。
2.互聯網企業進入傳統行業的一個非常好的切入點，將互聯網技術和實踐帶到傳統行業，中臺是一個非常好的抓手和利器。消費側戰場激烈，求助於供給側。
3.煙囪林立、數據孤島等痛點。
4.底層原因，最近兩年經濟形勢不好，但是把能力進行沉澱和複用，應對未來。
疑問
1.中臺化與平臺化的區別是什麼？
2.中臺化和服務化的區別是什麼？
3.中臺該怎麼建設？
1.企業級（只支持一條業務線和產品線，那就不是中臺），並不是技術問題，而是企業架構問題。需要跨業務線的能力沉澱。
2.能力 中臺的主要承載對象，能夠有怎樣的能力決定了該中臺
3.複用 易用性+用戶體驗（響應 平穩）
4.平臺 中臺的主要形式，區別於傳統的應用系統拼湊，更細粒度能力的識別與平臺化沉澱
利用平臺化的思維和手段梳理、識別、沉澱與複用企業級核心能力的過程
不同中臺：
1.業務中臺
2.數據中臺
業務中臺生產數據，數據中臺對數據二次加工，並將結果再服務於業務，爲業務進行數據和智能的賦能。
業務中臺下業務根據領域模型分爲各大中心:
交易中心
支付中心
訂單中心
商品中心
會員中心
評價中心
柔性事務
1.引入日誌和補償機制
2.可靠消息傳遞 - 要求消息至少被投遞一次，需要消費冪等
3.實現無鎖
4.樂觀鎖
目前能夠清楚的：
1.當前的業務流程設計中，我依賴了哪些應用，哪些服務？
2.整個鏈路的依賴路徑是怎麼樣的？哪些服務對當前業務處理來說是最爲核心的？這些依賴如果出錯，會有什麼影響？
3.一次業務請求處理的時間到底花在了什麼地方？是因爲某一個服務耗時很長，還是因爲某一個數據庫的訪問操作？
4.我所負責的業務鏈路中，過去一段時間哪些服務是出錯率比較高的，哪些服務是業務鏈路的處理瓶頸。
數據庫異構難題，阿里解決方案-精衛：
精衛平臺通過抽取器（Extractor）獲取到訂單數據創建在MySQL數據庫中產生的binlog日誌，轉換爲event對象，用戶可以通過精衛自帶的過濾器（Filter）對event對象中的數據進行處理，最終通過分發器（Applier）將結果轉換爲發送給DRDS的SQL語句，實現異構索引數據。
分佈式事務一致性淘寶XTS框架：
支付寶XTS分佈式事務框架是基於BASE的思想實現的一套類似兩階段提交的分佈式事務方案。
用來保障在分佈式環境下高可用性、高可靠性的同時兼顧詩句一致性的要求。相比消息實現的分佈式事務僅支持正向補償，XTS可同時支持正向和反向補償。XTS是TCC(try/confirm/cancel)型事務，屬於典型的補償性事務。