前言
在網際網路應用專案中分散式設計是必不可少的環節，通過分散式設計從而達到簡單擴容硬體的方式來提高系統和平能的總體吞吐能力。但實際應用中並不是簡單地進行分散式設計就能解決問題，因為在現實應用並不是所有硬體資源都可以很好地進行擴容，比較常見的就是資料庫資源，所以在設計整個架構的時候必須考慮部署資源的侷限制性；否則整個構架所產生的效果就不能達到設計前規劃水平。下面講述構建一個可靠、高吞吐的分散式業務架構基礎改造。
現有架構
以上結構是最常見的分散式設計結構，而我們現有專案也是遵循著這種結構。這種結構看上去似乎比較理想，通過新增的硬體就能支撐所需要的訪問量；但這種架構在實際應用中不一定達到效果，還容易導致服務不具備良好的可靠性；主要原因如下：
資料庫資源
在整個體系環境中資料庫資源往往都不具備水平新增裝置的可行性，所以即使上層硬體資源再充足也是無補於事的。雖然可以通過業務來水平拆分資料，但過多的資料庫例項在業務處理同步上也會導致整個資料庫環境非常複雜影響效率。
同步操作
以上結構的請求邏輯到響應都是以同步的方式，同步方式的缺陷也是非常明顯的，在整個業務線上只要有一個點存在效能問題那上游上的所流入都會被阻塞，這個阻塞最終會影響到最上層導致使用者請求無法響應。同樣上游大量請求進來，也容易導致這個點出現崩潰導致整個系統癱瘓；一旦這情出現即使你如何新增硬體資源也是無法支撐。
問題總結
以上兩點就已經說明了在架構設計的時候需要考慮情況的多樣性，一旦有些應用層面的問題在設計上沒有考慮到那這個架構體系就達不到預期的設計目標。所以在作為架構人員瞭解業務知識，資料流向，支撐產品選擇,系統支撐目標和實施規劃是一件非常重要的事情，反而程式碼細節層面的設計變得相對次要些了。
改進架構
在高併發應用中資料庫資源往往是很短缺的，而這資源確是高併發洪峰的問題點所在,如果在架構階段沒有考慮這些情況那就會產生很較嚴重的後果,就像平常我們聽到的什麼XX年一遇的洪水一樣.以上的設計架構就沒有考慮洪峰的情況。在現實生活中人們都會在河流上設計堤壩來抵遇這此情況的發生，而這方法在軟體架構設計中也是非常有效的。
當下遊的排水能力不足的情況，為了應付上游大量洪水湧入必須建立一個蓄水池。在架構中可以架設一個MQ服務用於積蓄訊息的資訊池。當使用者提交處理資料系統會直接把訊息投遞到MQ後就可以給使用者確認，這樣使用者的響應時間縮短整體吞吐會提升N個級別；由於有MQ的隔離下游的邏輯處理就可以根據資源的使用情況，可達到有序可靠的處理能力。
針對以上情況調整的架構體系如下：
通過以上架構的調整，上層應用就不會受限於資料庫資源的缺少而影響。在不調整資料庫資源的情況可以通過擴容中間部件資源來達到更高的吞吐效能和併發支撐能力。
非同步
業務非同步處理可以很好地解決抗併發處理能力，在不需要等待複雜的業務處理的情況下可以大大縮短響應時間，提高吞吐量。
MQ
MQ在軟體系統中可以很好的承擔訊息積蓄池的作用，它可提供高資訊吞吐和可靠性的優點；通過它可以把業務訊息和資料庫進行一個很好的隔離支撐。
NOSQL
NOSQL產品有著其查詢高效性的優點，而這些效能往往是傳統關係資料所不能比的；通過它可以很好地隔離大量資料查詢時的資料庫瓶頸問題。
總結
以上架構的總體出發點都是緩解資料庫壓力而設計的，而它並不能滿足所有系統的需要，只是針對我們現有系統面臨問題的基礎規劃。由於架構設計是為了讓系統可以更好的支撐相應的業務功能；所以架構設計前必須明確業務規則和業務指標，只有在這基礎的構建才能保證架構的可靠性。在傳統技術人員來看，架構往往是如何把系統的程式碼規劃好，制一個良好的程式碼層次規則。但架構規劃更多的系統生態圈的支撐，所以考慮的面要比程式碼層面要高很多，具備業務的深度和技術的廣度是非常必要。
當然我自身也不具備架構師的資格，以上只是這些年來做架構所積累的一些經驗分享出來，今後有時間會把這些年涉及B2C各個系統架構設計分享出來。