低調的牛肉
分佈式系統在增大系統容量、提高系統複用性、使系統擴展性更高的同時，同時也有不少難點和缺點。
網絡開銷
傳統架構，所有的業務邏輯都被打成一個代碼包進行部署，所有模塊運行都是在同一個JVM中，不會存在網絡的開銷（應用到數據庫的網絡開銷不討論，這裡和主要指代碼和代碼之間的調用）；而分佈式架構中，模塊和模塊可能會被部署到不同的機器上，它們之間的訪問需要通過遠程調用的方式來實現，網絡IO就成為不可忽視的性能瓶頸了。
特別是在微服務的階段，服務被拆分的比較小，一次完整的業務流程可能需要幾個微服務，這時候網絡問題更會凸顯出來。
通常我們會增加帶寬、使用專線等方式，降低網絡開銷；代碼方面，會採用失敗重試或者異步化的方式，來解決網絡延遲問題，後者也無疑增加了代碼實現難度。
服務依賴性問題
一個完整的應用，被拆分成了多個服務，服務和服務之間肯定是有依賴性的；如果有一個關鍵性的服務掛掉了，那麼整個服務鏈路上的所有服務，都會產生問題。
這時候就需要進行服務治理，梳理出來關鍵業務和非關鍵業務，以及服務的調用路徑；數據庫要做響應的隔離；避免非關鍵性業務把數據庫搞死，從而導致關鍵性業務也變成不可用；所以，理論上每個服務都要有獨立的數據庫，數據不做共享，但是現實中經常無法做到。
數據一致性問題
Consistency：強一致性，事務保障，ACID模型；
Availiablity：高可用性，避免單點；
Partition tolerance：高可擴展性。
我們經常會說的CAP原理，也就是CAP這三個因素不可能兼顧，最多隻能滿足兩個；分佈式系統來說更為強調A和P，所以會選擇適當放棄一致性，或者說分佈式系統通常會選擇保證最終一致性；為解決這個問題，架構中需要引入消息表、MQ（事務消息）或其他的補償手段，這無疑也加大了項目實現的難度。
另外，分佈式系統也會讓測試變得更加的複雜，多層的架構也讓運維變得複雜；分佈式架構在提高系統可用性的同時，也帶來了更多的挑戰。
我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。
會點代碼的大叔
分佈式系統是將系統功能進行模塊化，並且部署到不同的服務器上，每臺服務器實現不同的功能，處理不同的數據。分佈式主要是用於減輕服務器的壓力，提升效率，以及降低系統維護的難度。但由於每臺服務器處理的業務不同，如果一臺服務器出現問題，必然會導致系統故障，所以一般分佈式系統會和集群結合使用。
解耦：解耦是分佈式系統的重點，在系統設計之初就要確定如何進行解耦、模塊劃分，由於不同的模塊可能會由不同的團隊進行開發和維護，如果模塊間出現業務重疊或者交集過多，就會加大開發以及後期維護的難度。
分佈事務：由於分佈式系統將業務進行了拆分，而對於整個系統而言，事務是面向整個業務的，這就要求不同模塊如果存在事務，則必須採用分佈事務的機制來保證業務的完整性。
數據處理：分佈式系統雖然將業務功能進行了模塊化，但是整個系統的數據必然是完整的，那麼在系統設計時要確定好數據的存儲方式，是統一管理還是分開管理，從而保證數據準確性的同時提升系統的運行效率。
數通暢聯 專注於企業IT架構、SOA綜合集成、數據治理分析領域，感謝您的閱讀與關注！
