1、微服務實踐痛點與解決方案目錄CONTENTS微服務的拆分分布式事務微服務的監控微服務拆分微服務粒度服務劃分方法-DDDMarketingcontextSalescontextSupportcontextdomainsSales opportunitiesSalesconstractcustomerslicensecustomersdetectsBound context微服務拆分線索單個系統作為一個微服務粒度會太大嗎？數據庫的table大概有多少，有50以上？（數據庫大概50張表左右）管理成本，容易理解？這個微服務團隊需要多少人，5-7個人subsystemservice packagedep

2、endencylibTable-prefix多個service之間有類似的功能服務需要注意的一些點pattern描述Bussiness-driver拆分的時候首先考慮業務需求Service first data last先拆分業務，再拆分數據Share1.頻繁變動的服務，作commonservice2.比較固定的服務，log，dateutil,stringutil，可以封裝成jar包Anti-rest服務之前的交互可以有rest，再有些情況也可以通過eventAnti-retrytimeout必須結合Circuitbreaker模式，避免一直重試浪費資源DAG不要涉及環路的設計Distribu

3、tion Transaction設計的時候一定要考慮事務，能避免盡量避免dependency運行時候依賴，部署避免依賴微服務分布式事務微服務分布式-springJTA1.Atomikos2.Bitronix3.LCN Tm事務管理器S1（txclient）S2(txclient)1.starttransaction注冊事務2注冊事務3.提交和回滾DB連接池DB連接池4.Commit&rollbacktstartAtstartBtstartctendAtendB.C鎖時間微服務分布式-事務MQ全局事務由一個個小的本地事務組成ServiceAMQDBServiceB2執行本地事務1發送消息3執行本

4、地事務1發送half消息2發送成功4Confirm/rollback4Confirm/rollback5超時回查6超時回查消息可消費B 在消費的時候cashMq保證消息至少消費一次1執行本地事務發送消息2網絡或者Acrash分布式事務Mq考慮回滾的復雜度ABASTBFTCBSTCFT缺點：正向補償：服務一多，反向補償復雜度會很高，一般mq采用用正向補償的方式，利用重試機制和人工處理避免回滾時間窗口拉長：異步消費時間無法控制；正向補償失敗后，需要人工處理優點：實現相對簡單，rocketmq已經支持事務.ST.FT.事務MQ的適用場景實時性要求不高的業務-后一個服務之要能夠完成，時間長一點沒關系被

5、動型業務-后一個服務對前一個服務沒有決策權退款付款記賬微服務分布式-基于saga算法ServiceAServiceBAlphaDBTransaction Astart/EndTransaction Bstart/EndTransactionId異常/超時補償OMEGAOMEGA優點（相比TCC）：只需要寫一個冪等的補償接口實時性相對比較好缺點：數據隔離性不好SAGA執行流程ServiceAServiceBsagastartTxid1 A start(補償接口描述符)Txid=1ServiceCsagastartTxid1 A start(補償接口描述符)Txid1 B start(補償接口描述

6、符)Txid1 B endTxid1 C start(補償接口描述符)Txid=1觸發補償alpha服務掛掉，end沒有發送Aplfa crash，消息發送不出來Txid1 B start(補償接口描述符)Txid1 B endTxid1 C start(補償接口描述符)Txid1 C end(補償接口描述符)Txid1 A endsagaendTxid1 C abortTxid1 B 補償Txid1 A endsagaenddoA()doB()doC()SAGA模式的適用場景可補償的事務，實時性要求比MQ高的事務補償的事務：可接受結果超出預期，損失可承受，比如積分模式不可補償事務：金融轉賬。

7、第三方只支持操作和取消的服務微服務分布式方案-優化版本ServiceAServiceBAlphaDBTransaction Astart/endTransaction BstartTransactionId異常/超時補償內存數據庫性能問題，2000TPS，400個業務發生補償，補償恢復需要占用半個小時的恢復時間（4.5s執行一個補償操作）微服務分布式-TCC部分confirm失敗，部分confirm成功？優點：能夠保持嚴格一直想，不會導致讀未提交缺點：需要開發者實現try接口，confirm/cancle的接口，對于開發者能力有較大的要求TCC模式正常執行流程ServiceAServiceBS

8、erviceC分支事務管理器serviceA(tryA)Confirm/cancle 方法描述符tryB()Confirm/cancle 方法描述符Confirm/cancle 方法描述符tryC()tryendconfirmconfirmokokokokconfirmTCC模式異常執行流程ServiceAServiceBServiceC分支事務管理器serviceA(tryA)Confirm/cancle 方法描述符tryB()Confirm/cancle 方法描述符Try canclecancleokokTCC適用場景微服務監控用戶單次會話請求復雜鏈路-微服務應用以拓撲圖的形式全景展示了單

9、次請求的服務調用鏈路，秒級鎖定異常、瓶頸。復雜調用異?？焖俣ㄎ豢焖俳桓杜c快速排查客戶下單報錯啦！下單報錯啦！前臺客戶下單報錯啦！前臺我沒問題，問問服務報錯了嗎？運維進程都在，也沒看見ZB報錯呀！中臺是你沒調過來吧，我連日志都沒打！后臺胡說什么？我這有反應，你傳錯了！DBA叫什么叫，連數據都沒連上！DBA叫什么叫，連數據都沒連上！基礎傻X,磁盤滿了，都不知道在叫啥。老板張三說李四，李四說王五，說了半天都兩個小時了，就不能解決地快點嗎？員工誰不想快??？但也要快的起來呀！老板，我們都沒偷懶啊。我們為什么需要全鏈路監控？能直觀查看整個鏈路的延時分布怎樣？用戶的瀏覽器或者移動端的體驗是什么？應用在整個鏈路上是否有異常？數據庫響應怎樣？資源占用情況怎樣？會話級全鏈路一體化智能監控系統根據用戶的id或者相關的業務id找出程序響應的全鏈路關聯信息需要什么樣的監控系統？關聯整合才能解決問題微服務全鏈路故障回溯從前臺到后臺的全鏈路軟硬件關聯感 謝 聆 聽Thanks！