前面我們已經提到單個伺服器再優化,它的處理能力都是有上限的,因此我們選擇多擴容以及使用緩存和消息隊列等對程式進行優化。 下麵介紹另一種方法,隨著項目需求完成越來越多,應用自然也會越來越大,架構師將一個應用整體拆分成多個應用。 拆分的原則: 1.業務優先,確定業務邊界 2.循序漸進,邊拆分邊測試 3. ...
前面我們已經提到單個伺服器再優化,它的處理能力都是有上限的,因此我們選擇多擴容以及使用緩存和消息隊列等對程式進行優化。 下麵介紹另一種方法,隨著項目需求完成越來越多,應用自然也會越來越大,架構師將一個應用整體拆分成多個應用。 拆分的原則: 1.業務優先,確定業務邊界 2.循序漸進,邊拆分邊測試 3.兼顧技術:重構、分層 4.可靠測試 拆分的思考: 1.應用之間的通信:RPC(dubbo等)、消息隊列 消息傳輸適用於傳輸數據包小但是數據量大,對實時性要求不高的場景。比如下單成功後通過簡訊通知用戶。而選用RPC框架實時性更高一些。 而不會適用http、webservice等方法,因為RPC配置好之後和本地調用很像。 2.應用之間的資料庫設計:每個應用都有獨立的資料庫 3.避免事務操作跨應用,分散式事務是一個非常消耗資源的問題。這樣應用和應用的耦合度降低。
Dubbo是一種分散式的服務框架 要實踐微服務要解決4個問題: 1.客戶端如何訪問這些服務 API Gateway提供統一的服務入口,對前臺透明,同時可以聚合後臺的服務,提供安全過濾流控等api的管理功能 2.服務之間是如何通信的 非同步的話使用消息隊列,同步調用使用REST或者是RPC,Rest可以使用springboot,RPC通常使用Dubbo 同步調用一致性強但是出現調用問題,REST一般基於http實現,能夠跨客戶端,同時對客戶端沒有更多的要求。 RPC的傳輸協議更高效,安全也更加可控。特別是在一個公司內部如果有統一的開發規範和統一的框架,它的開發效率會更加明顯。 而非同步消息在分散式系統中有特別廣泛的應用,它既能減少調用服務之間的耦合,又能成為調用之間的緩衝,確保消息積壓不會衝垮被調用方。 同時保證調用方的用戶的體驗,繼續乾自己的活。付出的代價是一致性的減慢,需要接受數據的最終一致性 3. 如何實現如此多服務 在微服務架構中一般每一服務都會拷貝進行負載均衡,服務如何相互感知,如何相互管理,這就是服務發現的問題了,一般都是進行服務註冊信息的分散式管理。 4.服務掛了該如何解決,有什麼備份方案和應急處理機制 分散式最大的特性就是網路是不可靠的,當系統是由一系列的調用鏈組成的時候,其中任何一個出問題都不至於影響到整個鏈路。 相應的手段有:重試機制、應用的限流、熔斷機制、負載均衡、系統降級