有哪些設計或實現上的難點？

分布式系統在增大系統容量、提高系統復用性、使系統擴展性更高的同時，同時也有不少難點和缺點。

網絡開銷

傳統架構，所有的業務邏輯都被打成一個代碼包進行部署，所有模塊運行都是在同一個JVM中，不會存在網絡的開銷（應用到數據庫的網絡開銷不討論，這里和主要指代碼和代碼之間的調用）；而分布式架構中，模塊和模塊可能會被部署到不同的機器上，它們之間的訪問需要通過遠程調用的方式來實現，網絡IO就成為不可忽視的性能瓶頸了。

特別是在微服務的階段，服務被拆分的比較小，一次完整的業務流程可能需要幾個微服務，這時候網絡問題更會凸顯出來。

通常我們會增加帶寬、使用專線等方式，降低網絡開銷；代碼方面，會采用失敗重試或者異步化的方式，來解決網絡延遲問題，后者也無疑增加了代碼實現難度。

服務依賴性問題

一個完整的應用，被拆分成了多個服務，服務和服務之間肯定是有依賴性的；如果有一個關鍵性的服務掛掉了，那么整個服務鏈路上的所有服務，都會產生問題。

這時候就需要進行服務治理，梳理出來關鍵業務和非關鍵業務，以及服務的調用路徑；數據庫要做響應的隔離；避免非關鍵性業務把數據庫搞死，從而導致關鍵性業務也變成不可用；所以，理論上每個服務都要有獨立的數據庫，數據不做共享，但是現實中經常無法做到。

數據一致性問題

Consistency：強一致性，事務保障，ACID模型；

Availiablity：高可用性，避免單點；

Partition tolerance：高可擴展性。

我們經常會說的CAP原理，也就是CAP這三個因素不可能兼顧，最多只能滿足兩個；分布式系統來說更為強調A和P，所以會選擇適當放棄一致性，或者說分布式系統通常會選擇保證最終一致性；為解決這個問題，架構中需要引入消息表、MQ（事務消息）或其他的補償手段，這無疑也加大了項目實現的難度。

另外，分布式系統也會讓測試變得更加的復雜，多層的架構也讓運維變得復雜；分布式架構在提高系統可用性的同時，也帶來了更多的挑戰。

我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。