首先我們來看看這個架構圖中的監控部分：
監控各個伺服器的運**況，當發現伺服器執行異常時及時傳送報警資訊（以郵件或者簡訊的方式）。
從架構圖中可以看出監控伺服器會對整個系統中的伺服器進行監控。
那麼監控伺服器又如何能夠檢查乙個伺服器是否執行正常呢？
我們知道對於乙個伺服器來說監控它是否執行正常最有權威、最簡單的方式，並不是要它向監控告知自己是否執行正常，而是由和它有相關業務處理邏輯的伺服器來進行監控。換句話說，對於業務處理伺服器是否執行正常最有發言權的應該是分發伺服器。
那麼我們就可以將整個的架構重新調整為:
業務處理伺服器和賬號伺服器均採用了主伺服器和備用伺服器的方式。這樣用來可以保證當其中一台賬號伺服器或者業務處理伺服器出現問題以後，分發伺服器可以根據相關演算法切換到另外的一台備用伺服器上，保證業務的正常執行。同時分發伺服器將出現異常的賬號伺服器或者業務處理伺服器的問題訊息傳送給監控伺服器，監控伺服器進行相關報警操作。
上面的話比較繞口，我們來舉個例子：
這個例子的前提條件是分發伺服器連線著主賬號伺服器、主業務處理伺服器，同時分發伺服器正常連線日誌伺服器、監控伺服器以及負載平衡伺服器。
（1）：當終端使用者傳送一條業務到分發伺服器以後，分發伺服器對這條業務進行相關分發（例如它分發到了主業務處理伺服器）。
（2）：主業務處理伺服器在處理這條業務的時候，由於種種原因處理失敗，這條業務指令被拋棄掉。或者主業務處理伺服器直接退出程式。
（3）：分發伺服器傳送業務以後馬上對於這條業務指令進行計時處理。
（4）：由於主業務處理伺服器已經拋棄了這條業務，則在分發伺服器無法在指定時間之內得到主業務處理伺服器返回的訊息。
（5）：分發伺服器斷開與主業務處理伺服器的連線，並和備用業務處理伺服器連線。
（6）：分發伺服器將主業務處理伺服器出現異常的訊息傳送給監控伺服器。
（7）：監控伺服器進行彙總報警。
同理我們對賬號伺服器也進行了相應的處理。
那麼其它伺服器應該如何處理呢？這個可否請大家自己來考慮呢？
fxh7622
服務端架構設計及功能說明
這個架構圖是自己以前做過的乙個專案的架構圖。簡單介紹一下各個伺服器的功能 外圍伺服器 1 日誌伺服器 接收各個伺服器的執行日誌，並採用執行緒池的方式寫入到相應的裝置中 資料庫或者檔案 2 監控伺服器 監控各個伺服器的運 況，當發現伺服器執行異常時及時傳送報警資訊 以郵件或者簡訊的方式 3 負載平衡伺...
移動App服務端架構設計
其實有一點還需要加上，就是對json的壓縮和加密，一來給使用者節約流量，二來防止請求被擷取破解我們的引數。具體先壓縮後加密還是先加密後壓縮這個問題看需求。看到這個架構設計時，你們可能會說如果程式入口掛了，所有的服務都不可以用了。所以這個架構的弱點在程式入口處，因此要有一 多 臺機器做負載，負載的工具...
App架構設計經驗談 服務端介面的設計
使用者用密碼登入成功後，伺服器返回token給客戶端 客戶端將token儲存在本地，發起後續的相關請求時，將token發回給伺服器 伺服器檢查token的有效性，有效則返回資料，若無效，分兩種情況 然而，此種驗證方式存在乙個安全性問題 當登入介面被劫持時，黑客就獲取到了使用者密碼和token，後續則...