在架構上， 可以將服務中的伺服器分三個模組：
模組含義
config
配置服務
server
對外介面服務
service
工作服務（worker)
我想讓service接受請求，server進行計算， 流程會是怎麼的呢。
一條簡單的請求過來，可能經過的處理過程：
實際的處理比這個要複雜，比如請求過期處理等。
在框架內通個上，service與server都會向config註冊，通訊以及獲取節點情況等，因此會有很多
相似的邏輯實現，所以很自然地，我把節點的關係重新定義為 config-node
為了簡單處理，抽象了乙個node，service與server共同繼承node, 由node負責與config通訊。
下面我將對系統設計的協議進行設計。
為了簡單方便，我將模組間的通訊採用protobuf。
（實際上在通用對外服務是不能用protobuf的，請大家思考為什麼。）
message configrequest
message configresponse
message serverrequest
message serverresponse
下面的**架構主要爭對config-node而設計。
config請求處理：
class configclass node;為了介面方便，對外介面均設為http介面，並支援網頁。
[get]
引數含義start
起始值end
結束值 例：?start=1&end=10000
[post]
引數含義data
待計算的檔案
tokenize
分隔符 分布式查詢
[post]
引數含義應用名db庫
collection
連線data
查詢條件
為了方便了解每次請求的全鏈路情況，我在原架構中新增了日誌與監控模組
對於map reduce運算，實際處理過程是這樣的
這裡的query在設計上是簡化處理了的，生產上可能需要注意結果快取，主從同步等。
從上面的設計上，我們可以發現，分布式處理的基礎需要有乙個config（配置伺服器），及內部通訊協議。
另外，節點的備份機制也很重要， 比如 config崩潰或者server崩潰的結果要做到不受影響。
對於config的功能，由於其核心功能是當前節點分布，是動態資料，因此資料安全可以採用的方法有很多，比如redis，mysql, mongo等。
其自身的功能崩潰恢復可以採用一種簡單有效的方法。每個config節點都存有所有config的資訊並且同步到各個node(service/server)。
每當新起乙個config或者關掉乙個，資訊更新一次，node與config失聯後再主動選擇乙個連線。
config提供node相互關注的能力， 即node a可以關注node b, 當node b斷開後，config會通知像a一樣所有關注它的node。
談談自己對分布式的理解
現在常用的開源分布式框架乙個是阿里開源的dubbo，還有乙個就是spring cloud 最初的服務化解決方案是 相同服務提供乙個統一的網域名稱，然後客戶端傳送http請求，由nginx負責請求分發和跳轉，耦合了服務呼叫邏輯，相當於乙個重量級的esb 有以下幾個缺點 1 作為消費者不知道由哪個服務例...
對分布式事務的簡單理解
分布式事務就是把乙個包含多個操作步驟的業務操作 這些操作往往是由不同的應用系統來完成的 作為乙個整體來對待，要麼都成功，要麼都失敗。問題是各個操作步驟在不同的業務系統中進行操作，網路速度，系統故障等各種因素都有可能影響操作結果，必須採取有效方法來達到事務的目的。所謂的原子性就是說，在整個事務中的所有...
對分布式一些理解
1，微服務的優缺點 微服務的解決的問題，吞吐量，易擴充套件，小模組的快速開發，解決單點故障多。缺點，單個請求的反應時間變長，需要通過rpc調取多個下游服務。部署整條鏈路複雜，排錯，定位問題複雜。架構邏輯複雜。2，分布式一些難點 1，容易出錯，所以需要把錯誤當成正常邏輯，寫在 裡。能處理的，不能處理的...