現在常用的開源分布式框架乙個是阿里開源的dubbo，還有乙個就是spring cloud
最初的服務化解決方案是 相同服務提供乙個統一的網域名稱，然後客戶端傳送http請求，由nginx負責請求分發和跳轉，耦合了服務呼叫邏輯，相當於乙個重量級的esb；有以下幾個缺點：
1：作為消費者不知道由哪個服務例項提供服務
2: 無法觀測到服務消費者和服務提供者之間的通訊頻率和調執行狀況
3：消費者的失敗重發，加大了服務開發難度，nginx沒有統一的管理策略
綜合種種原因，分布式框架誕生，dubbo就是一款很優秀的開源框架；他整合了服務註冊中心和服務監控中心
服務提供者通過服務註冊中心註冊自己需要提供的服務，消費者則從註冊中心訂閱自己需要的服務；監控中心則是
統計消費者和提供者之間的通訊頻率、排程時間、執行狀況
從框架的自身結構來看，dubbo也有其缺點
1：服務提供者和服務消費，很依賴第三方元件（zookeeper,redis）,一旦該元件出了問題，框架本身也會啟不起來
2：消費者嚴重依賴服務提供者，雙方**耦合度較高，一旦服務提供者在導jar包的過程中出錯，程式就會出現問題
分布式框架系統定理 ： c —— 資料一致性 a —— 服務可用性 p —— 服務對網路分割槽故障的容錯性，分布式框架很難都滿足，一般符合其中兩者;包括dubbo在內的其它使用zookeeper的分布式框架是滿足cp，因為當客戶端傳送請求時，集群正在進行master選舉或者半數以上的機器宕掉，服務可用性就很難做到；而對於持續整合，快速演化微服務來說，可用性就顯得尤為重要，spring cloud由此誕生
spring cloud和dubbo的區別
兩者的區別也是各自的優劣
1：dubbo的服務註冊與發現是用的zookeeper，spring cloud服務註冊與發現用的是eureka 後者各個節點之間都是平等的不存在主從關係，只要乙個節點還在，就能保證服務正常呼叫，即使全部節點都死掉，服務與服務之間也能通過快取呼叫資訊，這就保證了微服務之間的呼叫足夠的健壯
2：對於呼叫方式dubbo採用rpc的方式，**耦合度高，spring cloud中的提供方和消費方通過http rest方式，不存在**的強依賴顯得更為靈活
對分布式事務的簡單理解
分布式事務就是把乙個包含多個操作步驟的業務操作 這些操作往往是由不同的應用系統來完成的 作為乙個整體來對待，要麼都成功，要麼都失敗。問題是各個操作步驟在不同的業務系統中進行操作，網路速度，系統故障等各種因素都有可能影響操作結果，必須採取有效方法來達到事務的目的。所謂的原子性就是說，在整個事務中的所有...
對分布式一些理解
1，微服務的優缺點 微服務的解決的問題，吞吐量，易擴充套件，小模組的快速開發，解決單點故障多。缺點，單個請求的反應時間變長，需要通過rpc調取多個下游服務。部署整條鏈路複雜，排錯，定位問題複雜。架構邏輯複雜。2，分布式一些難點 1，容易出錯，所以需要把錯誤當成正常邏輯，寫在 裡。能處理的，不能處理的...
談談分布式事務
只要牽涉到分布式系統，無論如何都會碰見分布式事務，當然你可以合理的拆分系統，規劃表和庫的結構，但是這只是減少分布式事務出現的次數，比方說你原來系統中有5處地方會有分布式事務，現在一優化可能只有3處地方有了，但是你要一點也沒有，個人認為不大可能 接下來談談什麼情況下會產生分布式事務?一 同資料庫，不同...