注：圖片來源  https://blog.csdn.net/define_us/article/details/84812729

在談微服務架構設計的時候我們已經談到過，傳統的一個單體應用被拆分爲了多個微服務模塊，而這些微服務模塊之間本身也通過API服務接口進行交互。如果這些模塊需要對外暴露接口和提供能力，往往就需要通過API網關進行服務註冊接入，並提供統一的對外能力提供，這種情況下API網關本身可以實現服務治理和管控。

但是如果不對外提供能力，我們前面談到過微服務模塊之間的API接口交互往往是通過服務註冊中心進行，但是服務註冊中心本身服務治理和管控能力相當弱，很多類似日誌審計，安全，流控等能力都無法達到。而這個時候就涉及任何需要API網關來進行服務治理管控。

API網關本身是中心化的，那有沒有一種完全去中心化的架構？

這也就是前面我們談到過的ServiceMesh服務網格和SideCar，簡單來說就是服務網關的關鍵技術能力全部下沉到微服務模塊中，和微服務模塊一起部署。Service Mesh 直譯過來是 服務網格，目的是解決系統架構微服務化後的服務間通信和治理問題。服務網格由 sidecar 節點組成。

Sidecar 在軟件系統架構中特指邊車模式。這個模式的靈感來源於我們生活中的邊三輪：即在兩輪摩托車的旁邊添加一個邊車的方式擴展現有的服務和功能。這個模式的精髓在於實現了數據面（業務邏輯）和控制面的解耦：原來兩輪摩托車的駕駛者集中注意力跑賽道，邊車上的領航員專注周圍信息和地圖，專注導航。具體到微服務架構中，即給每一個微服務實例（也可以是每個宿主機host）同步部署一個 sidecar proxy。

在採用這種架構下，我們來看如何實現統一的日誌監控和管理。

如果我們將服務運行實例日誌全部存儲在微服務模塊App Server本身的應用服務器上面，那麼顯然是很難對這些日誌進行統一管理，存儲和結構化處理的。因此最佳的方式仍然是我很早就提到過的，sidecar代理在獲取到日誌信息後仍然需要將該信息異步推送到消息中間件，再由消息中間件寫入到統一的日誌存儲中心進行統一的管理和監控。

即實際的服務運行管理過程本身是完全去中心化的，但是對於後續的監控管理仍然是有一個完整的元數據配置中心和實例日誌的存儲管理中心，以實現統一的管理和監控。

聯想到我們常說的扁平化管理也是同樣的道理。以一個項目團隊來舉例說明，很多管理和協同往往都需要團隊成員將問題和需求上升到項目經理，再有項目經理跟進實際情況將任務分配到不同的崗位角色人員處理，最終再進行反饋。這種模式雖然是增加了溝通環節和次數，但是一個關鍵的好處就是資源信息本身是可以複用的，同時可以減少大量不必要的重複溝通和協同。

如果是完全去中心化，可能存在A向B要一個文檔，但是C同樣在向D要一個文檔，在這種情況下單點溝通隨時快捷了，但是出現了大量的重複無效溝通，資源本身也沒有得到有效的複用。

如何解決這個問題？

我覺得完全可以借鑑去中心化的技術架構裏面的思路，即溝通過程本身是點對點的，但是溝通過程和交互輸出本身卻需要進行集中化歸檔，同時給歸檔庫提供一個全文檢索功能。再好一點就是人工對歸檔庫進行結構化歸檔處理。這樣在新的需求出現的時候，我們應該是首先對歸檔庫進行搜索，在沒有發現可複用的資源後，再進一步尋求協助，而協助本身也會是一個廣播的方式進行發送，並尋求響應。

基於這個思路，你會發現當前的類似QQ溝通羣本身就是一個好的基礎載體，唯一要改進的就是溝通信息本身如何更好的集中化歸檔和結構化處理，形成強大的資源搜索庫。這將很好的解決在傳統去中心化溝通模式下，需要羣體中每個獨立個體之間都能夠做到完全相互瞭解和默契配合的要求。