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