邊車：就是在原來二輪電單車旁邊增加乙個座位成了三輪電單車，增加的一部分稱為邊車
邊車模式：對現有的服務增加額外的功能，這些功能並不影響業務邏輯，例如增加日誌，限流、熔斷、服務的註冊和服務發現有專門服務來實現。 像程式中的控制和業務邏輯分離(controller 和 service 層分離) 這樣大大降低了服務之間的耦合度並提公升了擴充套件性和降低業務的複雜性
這也符合單一職責原則，服務就是負載實現好自己的業務邏輯，一些其他的控制功能就交給其他元件來實現
1、引入jar 將和應用部署在同台機器
優點：節省了網路請求，效率更高
缺點：對服務侵入性大，不能跨語言，當jar更新時需要重新編譯
2、單獨乙個邊車服務，所有請求都經過這個控**務，由這個服務進行分發請求，因為所有請求入口都需要經過這個服務，因此很容易實現 限流、熔斷、服務註冊和路由功能
優點：對應用侵入小，跨語言，擴充套件性好
缺點：網路請求的時延
如何解決網路延時問題：
如果將邊車服務和應用部署在同台機器，然後通過 rpc 指定127.0.0.1 進行本地通訊，這樣會大大節省了通訊時延
閘道器是作為使用者和服務之間的網路**，可以起到控制作用，實現 限流、熔斷、服務路由、註冊和發現、監控等功能，但是閘道器做的事情是有限。
由於閘道器是中心化的，如果閘道器掛掉了就會導致整個服務不可用，同時保證中心服務高可用實現成本也很大，從使用者到請求處理中間多了兩次網路請求，對於服務內部還使用中心化的呼叫方式，就會大大增加了請求響應時間，從而採用去中心化，由服務呼叫者實現負載均衡策略，實現服務發現和路由。
分布式模式之broker模式
建立乙個遊戲系統，其將執行在網際網路的環境中。客戶端通過www 服務或特定的客戶端軟體連線到遊戲伺服器，隨著流量的增加，系統不斷的膨脹，最終後台資料 業務邏輯被分布式的部署。然而相比中心化的系統，複雜度被無可避免的增大了，該如何降低各個元件之間的耦合度。需要保證可伸縮性 可維護性 可更新性，需要將服...
Dubbo 分布式服務
隨著網際網路的發展，應用的規模不斷擴大，常規的垂直應用架構已無法應對，分布式服務架構以及流動計算架構勢在必行，亟需乙個治理系統確保架構有條不紊的演進。垂直應用架構 分布式服務架構 流動計算架構 在大規模服務化之前，應用可能只是通過rmi或hessian等工具，簡單的暴露和引用遠端服務，通過配置服務的...
分布式服務呼叫
分布式服務呼叫策略 1.lvs 中間 負載均衡系統做 優點 代價低，可控性強 缺點 流量壓力大 必由之路，雞蛋不在乙個籃子裡 應用 面向c端 2.名稱服務 各呼叫方機器 自己根據策略進行負載均衡 優點 名稱服務不會直接影響功能 減少了中間的頻寬消耗 缺點 公升級較複雜 當拉起一台伺服器，需要把新的i...