首先必須申明，這不是個路由器，而是借用路由器的特性。一般說來，傳統的路由器，將ip包**到目標機器上，那麼他的路由規則就是ip位址。但對服務請求來說，可能是sql語句或者其他具有規則特性的請求。我們可以建立乙個服務，按照一定的規則，將這些請求分發到其他服務上去，就像路由器**ip包那樣。這個路由服務主要的功能就是按規則分發，但他可以也可以不需要處理請求的結果資料。對於接收到請求的服務來說完全可以直接將資料返回給客戶端。
可能會很奇怪，要這個功能有什麼用呢？其實這個功能非常有用，特別是在高可用高效能的系統中。以dbms為例，如果乙個資料按時間段分布在12個資料庫中，每個資料庫儲存每天中2個小時的資料。那麼如果有乙個請求需要計算1天的資料，就需要將這個請求分發到12個資料庫中，這個例子多見於海量資料的情況。當然，也有的時候，每個資料庫的資料是完全相同，當遇到寫操作的時候，需要同時向多個資料庫寫入資料。而讀請求只由乙個資料庫來響應。這樣一讀多寫的請求同樣需要乙個服務來處理這個分發功能。上面2個例子是典型的高可用高效能系統dbms的方案。但在傳統的c/s架構中，客戶端和伺服器直接互動，缺乏這種中間環節，也失去了這種靈活性。
從單個請求的總體計算時間看，可能會稍大點，因為需要增加路由的計算，但由於計算負荷被多個機器分擔，使用者響應時間反而要減少很多。當某個伺服器失效時，由於路由服務的存在，完全可以將這個請求重新定位到乙個可用的服務。在傳統的c/s架構中，插入路由服務，並不是單純意義上的三層或者四層。對於路由服務來說，同樣可以插入到應用服務和客戶端之間，關鍵問題是他需要基於什麼樣的規則來實現請求的分發功能。
同時，我們還必須關注乙個問題，當請求被分發到多個伺服器之後，其中乙個處理失敗，我們應該採取什麼策略來處理這個結果呢？如果我們採用鴕鳥策略，將它置之不理，那麼這種情況可能會破壞了資料的完整性。但如果我們將它視為乙個事務，全部回滾的話，也可能導致錯誤。比如**交易系統中的成交回報，成交回報是交易所返回的報告，說明某筆委託已經完成交易，不論我們在儲存這個資訊的時候是否發生錯誤，那麼交易所不可能去回滾。所以它必須完成。我們必須不斷的強制傳送這個儲存請求直到全部成功。但是這種方案的後果，可能導致系統的效能嚴重下降。我們應該認識到，如果路由服務管理著越多的節點，那麼發生錯誤的概率越大。這個問題和udp多播的情況很相似。
我們知道，就像tcp和udp那樣，乙個請求是否需要被複製，是否需要保證完整性，是否必須具備實時性，都是因情況而異的。針對不同的情況，我們可以採取不同的策略，而不是一概而論。現在我們討論3種比較通用的情景：
1、需要高可靠性：毫無疑問，我們必須同時保證所有的請求得到同樣的結果，當然乙個分發出來的請求失敗後，我們需要不斷的重啟，當最終無法解決時，我們必須將負責處理這個請求的點標誌為失效。
2、需要高可靠性，但容忍較大的延時：和上面一樣，我們必須保證全部分發的請求處理成功，不過有點比較特殊，如果遇到失敗的處理，我們可以將這個請求快取下來，等待機會繼續重發，而不是花大量的資源來不斷重試。
3、只要傳送一次就可以了：這種情況比較簡單，我們把它當作udp那樣就可以了。
對於使用路由服務的系統來說，時序也是很重要的考慮因素。我們打個比方，乙個客戶的保證金為零，但他先賣出合約，然後再**合約，這個交易過程是可以成功的。但如果這個過程交換了次序卻是失敗，而這種情況在我們的系統中，以及分布式系統中完全可能發生的。當多個請求被多個路由服務所分發，那麼在時序上是很難保證的，除非被嚴格的排序。我們可以使用序號或者時間戳等方式來控制這種時序性，而不是去排序。
高效能，高可用系統架構
本文是學習大型分布式 架構的技術總結。對架構乙個高效能，高可用，可伸縮，可擴充套件的分布式 進行了概要性描述，並給出乙個架構參考。一部分為讀書筆記，一部分是個人經驗總結。對大型分布式 架構有很好的參考價值。1 大型 的特點 2 大型 架構目標 3 大型 架構模式 4 高效能架構 以使用者為中心，提供...
高可用高效能系統（二）系統異常場景
一 網路故障 當客戶正在交易時，突然網路發生異常，導致無法繼續連線到網路上。這個場景是最可能發生的。我們需要在網路發生的時候，讓客戶能夠繼續進行這個交易。二 效能故障 由於機器效能或者軟體效能的緣故，可能會導致我們在某個業務處理過程中耗費大量時間，比如資料庫查詢。但是這也不應該影響我們進行繼續交易。...
高效能，高可用，安全的架構
高效能 rt reponse time 時間 高可用 任何時候專案都必須可用 可公升縮 大促，流量瞬間增大 可擴充套件 開發角度 新需求進行迭代 擴充套件 安全性 網路安全，硬體安全，軟體安全 敏捷性 可持續交付，可持續部署 什麼是高效能？較短的響應時間 較大的併發處理能力 較高的吞吐量與穩定的效能...