本文主要內容包括：
1. 緊密耦合
無線介面和web應用緊耦合，web端的修改會影響無線介面，web端的發布導致無線介面被動連帶發布，web端的bug影響無線介面的可用性，反過來也一樣，無線介面的任何變化會影響web應用。
2. 重複開發
3. 穩定性
圖二 系統拆分示意
1. 對等隔離
2. 統一服務
adapter物理上是jar包，由各個業務線研發團隊提供，作為相應soa服務的前置，最終所有adapter集中部署在閘道器，閘道器本身支援水平擴充套件。
閘道器支援集中管控的同時，也帶來單點問題。假設後台某個服務介面，由於某種原因，效能有嚴重問題，對應adapter處理很慢，那麼閘道器所在伺服器的執行緒很快被耗盡，導致單個介面拖垮整個系統。這種問題，單純通過加機器，水平擴充套件閘道器數量是解決不了的，實踐中，我們引入智慧型公升降級機制快速隔離單個介面的影響，如圖四所示：
圖四 智慧型公升降級
針對特定乙個介面，如果在一定時間間隔內（比如5秒鐘），它的超時失敗率到了一定比例（比如2%），閘道器會對該介面做降級處理，隨機拋棄部分流量，比如只允許50%流量通過。下乙個5秒再評估，如果失敗率還沒有改善，允許通過的流量降到25%，以此類推。
如果成功率好轉，閘道器對該介面做公升級處理，提公升通過的流量比例，為了快速恢復，一般提公升到原流量4倍，然後在下乙個時間段再評估是否觸發公升降級。
整個過程全自動智慧型處理（為防止誤判，可支援人工干預），這樣單個介面出問題，不會影響整個閘道器的處理能力。
2. 底層核心的soa服務基於統一業務規則提供邏輯和資料，介面不區分pc、無線或其他渠道（如open api），避免重複開發，避免業務邏輯被汙染。所有前端一母同胞，本是同根生。
3. 根據無線本身的特點，支援系統層面的集中處理和業務層面的分散處理。通用邏輯支援外掛程式化擴充套件，可以根據需要逐步補充；adapter實現內外部介面的無縫轉換，可以針對無線場景，做邏輯增強（如服務聚合）。前面師傅領進門，後面修行靠各媽。
HTTP服務端JSON服務端
最後更新日期 2014 5 18 author kagula 內容簡介 cppcms是個開源web開發框架，通過它可以很容易實現http服務和json服務，這裡介紹cppcms開發環境的搭建。寫乙個cppcms測試程式，它建立http服務，向瀏覽器返回hello,world頁面。cppcms依賴的一...
移動App服務端架構設計
其實有一點還需要加上，就是對json的壓縮和加密，一來給使用者節約流量，二來防止請求被擷取破解我們的引數。具體先壓縮後加密還是先加密後壓縮這個問題看需求。看到這個架構設計時，你們可能會說如果程式入口掛了，所有的服務都不可以用了。所以這個架構的弱點在程式入口處，因此要有一 多 臺機器做負載，負載的工具...
專案ITP 三 玩玩 服務端 到 app端
系列文章 傳送門 泡泡腳，寫寫部落格，規律生活，睡個好覺，待會看會書。每天想著問題，問題只會慢慢的清晰。想著想著，慢慢模式就出來了。推送互動模式 所指的是學生群體 所指的是教師 教師可以基於http 給伺服器指示，提示伺服器進行操作 push.等 或是直接在web端進行操作 學生群體接受 push，...