在網際網路應用專案中分布式設計是必不可少的環節，通過分布式設計從而達到簡單擴容硬體的方式來提高系統和平能的總體吞吐能力。但實際應用中並不是簡單地進行分布式設計就能解決問題，因為在現實應用並不是所有硬體資源都可以很好地進行擴容，比較常見的就是資料庫資源，所以在設計整個架構的時候必須考慮部署資源的局限制性；否則整個構架所產生的效果就不能達到設計前規劃水平。下面講述構建乙個可靠、高吞吐的分布式業務架構基礎改造。
以上結構是最常見的分布式設計結構，而我們現有專案也是遵循著這種結構。這種結構看上去似乎比較理想，通過新增的硬體就能支撐所需要的訪問量；但這種架構在實際應用中不一定達到效果，還容易導致服務不具備良好的可靠性；主要原因如下：
資料庫資源
在整個體系環境中資料庫資源往往都不具備水平新增裝置的可行性，所以即使上層硬體資源再充足也是無補於事的。雖然可以通過業務來水平拆分資料，但過多的資料庫例項在業務處理同步上也會導致整個資料庫環境非常複雜影響效率。
同步操作
以上結構的請求邏輯到響應都是以同步的方式，同步方式的缺陷也是非常明顯的，在整個業務線上只要有乙個點存在效能問題那上游上的所流入都會被阻塞，這個阻塞最終會影響到最上層導致使用者請求無法響應。同樣上游大量請求進來，也容易導致這個點出現崩潰導致整個系統癱瘓；一旦這情出現即使你如何新增硬體資源也是無法支撐。
問題總結
以上兩點就已經說明了在架構設計的時候需要考慮情況的多樣性，一旦有些應用層面的問題在設計上沒有考慮到那這個架構體系就達不到預期的設計目標。所以在作為架構人員了解業務知識，資料流向，支撐產品選擇,系統支撐目標和實施規劃是一件非常重要的事情，反而**細節層面的設計變得相對次要些了。
在高併發應用中資料庫資源往往是很短缺的，而這資源確是高併發洪峰的問題點所在,如果在架構階段沒有考慮這些情況那就會產生很較嚴重的後果,就像平常我們聽到的什麼xx年一遇的洪水一樣.以上的設計架構就沒有考慮洪峰的情況。在現實生活中人們都會在河流上設計堤壩來抵遇這此情況的發生，而這方法在軟體架構設計中也是非常有效的。
當下游的排水能力不足的情況，為了應付上游大量洪水湧入必須建立乙個蓄水池。在架構中可以架設乙個mq服務用於積蓄訊息的資訊池。當使用者提交處理資料系統會直接把訊息投遞到mq後就可以給使用者確認，這樣使用者的響應時間縮短整體吞吐會提公升n個級別；由於有mq的隔離下游的邏輯處理就可以根據資源的使用情況，可達到有序可靠的處理能力。
針對以上情況調整的架構體系如下：
通過以上架構的調整，上層應用就不會受限於資料庫資源的缺少而影響。在不調整資料庫資源的情況可以通過擴容中間部件資源來達到更高的吞吐效能和併發支撐能力。
非同步業務非同步處理可以很好地解決抗併發處理能力，在不需要等待複雜的業務處理的情況下可以大大縮短響應時間，提高吞吐量。
mqmq在軟體系統中可以很好的承擔訊息積蓄池的作用，它可提供高資訊吞吐和可靠性的優點；通過它可以把業務訊息和資料庫進行乙個很好的隔離支撐。
nosql
nosql產品有著其查詢高效性的優點，而這些效能往往是傳統關係資料所不能比的；通過它可以很好地隔離大量資料查詢時的資料庫瓶頸問題。
以上架構的總體出發點都是緩解資料庫壓力而設計的，而它並不能滿足所有系統的需要，只是針對我們現有系統面臨問題的基礎規劃。由於架構設計是為了讓系統可以更好的支撐相應的業務功能；所以架構設計前必須明確業務規則和業務指標，只有在這基礎的構建才能保證架構的可靠性。在傳統技術人員來看，架構往往是如何把系統的**規劃好，制乙個良好的**層次規則。但架構規劃更多的系統生態圈的支撐，所以考慮的面要比**層面要高很多，具備業務的深度和技術的廣度是非常必要。
當然我自身也不具備架構師的資格，以上只是這些年來做架構所積累的一些經驗分享出來，今後有時間會把這些年涉及b2c各個系統架構設計分享出來。
kafka之高可靠 一致性 高吞吐
高可靠 1 ack機制 如果我們要往 kafka 對應的主題傳送訊息，我們需要通過 producer 完成。前面我們講過 kafka 主題對應了多個分割槽，每個分割槽下面又對應了多個副本 為了讓使用者設定資料可靠性，kafka 在 producer 裡面提供了訊息確認機制。也就是說我們可以通過配置來...
Kafka的高吞吐
kafka誕生於linkin公司。當時linkin需要對使用者和 上產生的活動資料進行處理，什麼是活動資料呢？比如頁面訪問量 使用者行為 搜尋情況等，對這些資料的分析將被應用於廣播 排序 個性化 推薦 運營監控等。這類資料有個特點，需要實時處理，最好當下使用者的一些行為資料能馬上被後台感知 計算，並...
DFSH高可靠原理
active namenode 乙個集群只有乙個active，接受客戶端的讀寫請求，記錄edits日誌 元資料 standbynamenode 乙個集群中可能有多個standby。合併edits和fsimage檔案，從而更新fsimage。等待 activenamenode的死亡。journalno...