2． 保證數(shù)據(jù)一致性的模式

（一）可靠事件模式（二）業(yè)務補償模式（三）TCC模式（Try－Confirm－Cancel）

上述幾種模式，經(jīng)常有人提到下面的問題：

1）都要求服務提供者在正常的交易之外，提供額外的功能，貌似帶來了代碼的復雜度，加大了工作量。實際上都是業(yè)務需求中必備的，例如：TCC 模式在交易系統(tǒng)中都有預扣款這樣的接口，并不會增加實現(xiàn)的工作量。而對于服務的調(diào)用者來說，相關(guān)服務的調(diào)用由微服務框架實現(xiàn)，例如自動的事件投放、自動補償調(diào)用、TCC中 CC 服務的調(diào)用，也不需要額外的工作量；2）如何從當前上下文向補償接口、confirm接口、cancel 接口傳遞參數(shù)？實際上只要將正向交易的數(shù)據(jù)傳遞過去即可，不需要額外的數(shù)據(jù)；3）如果補償還是失敗，該怎么辦？還是需要對賬的。 分布式感覺能力的相關(guān)技術(shù)

建立感覺能力可以概括為以下四種方式：

1）心跳監(jiān)測：提供模擬交易，由系統(tǒng)主動提供運行狀態(tài)信息。2）日志記錄：系統(tǒng)將運行情況記錄下來，用于感覺后端服務的運行情況。3）字節(jié)碼注入：注入到服務端代碼中，用于感覺后端服務的運行情況。4）客戶端埋點：注入到客戶端代碼中，用于感覺前端的運行情況。

聚合式知覺能力的相關(guān)技術(shù)

“感覺”探查到的信息匯總形成完整的“知覺”，例如：

1）健康檢查：知曉微服務健康狀態(tài)，了解服務的可用性，避免調(diào)用到失效服務上。2）性能分析：知曉微服務運行的性能，了解整個系統(tǒng)的瓶頸，在實時分析的基礎(chǔ)上進行預警，在問題萌芽的階段發(fā)覺并告警，降低問題影響的范圍和時間。3）業(yè)務監(jiān)控：知曉業(yè)務交易情況，監(jiān)測業(yè)務訪問量、慢交易數(shù)量、業(yè)務時延及發(fā)生錯誤的次數(shù)等各項業(yè)務指標。4）故障定位：知曉微服務的拓撲結(jié)構(gòu)、調(diào)用關(guān)系和調(diào)用順序，實時搜集信息并進行聚合分析，了解系統(tǒng)和應用中發(fā)生的事件，盡量避免故障，并且在發(fā)生故障后快速定位故障，減少處理時間。

重復的“輪子”。

建立微服務架構(gòu)下系統(tǒng)的知覺能力，需要多個層面配合完成，是一個系統(tǒng)性的工程，而不是孤立的考慮。我們把系統(tǒng)的“知覺”能力縱向分為四個層次，客戶端（Web、H5、APP、小程序等）、服務端（微服務進程）、技術(shù)組件（虛機、容器、中間件、數(shù)據(jù)庫等）、基礎(chǔ)設施（網(wǎng)絡、服務器、存儲等）。“知覺”體現(xiàn)的最終行動，分為鏈路拓撲、監(jiān)控、預警、故障定位、趨勢分析等幾個主題；配置中心（CMDB）實現(xiàn)所有涉及到的應用軟件、系統(tǒng)軟件、服務器和網(wǎng)絡設備的配置管理、監(jiān)控參數(shù)設置、業(yè)務規(guī)則配置，監(jiān)控中心負責監(jiān)控展示與告警；分析中心根據(jù)“感覺”采集的數(shù)據(jù)進行深度挖掘，積累知識。 關(guān)于作者：黃榮，數(shù)字化金融研究院研究員，擅長系統(tǒng)分析和架構(gòu)設計、金融三級密鑰安全體系及信息安全保障、虛擬化和云計算技術(shù)、JavaEE技術(shù)；參與研發(fā)的神州商橋電子商務平臺獲得“全國電子商務示范單位”稱號；帶領(lǐng)團隊研發(fā)的國電通云終端系統(tǒng)在國網(wǎng)多個省公司推廣應用。