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實現內外部介面的無縫轉換，可以針對無線場景，做邏輯增強（如服務聚合）。前面師傅領進門，後面修行靠各媽。
移動App服務端架構設計
其實有一點還需要加上，就是對json的壓縮和加密，一來給使用者節約流量，二來防止請求被擷取破解我們的引數。具體先壓縮後加密還是先加密後壓縮這個問題看需求。看到這個架構設計時，你們可能會說如果程式入口掛了，所有的服務都不可以用了。所以這個架構的弱點在程式入口處，因此要有一 多 臺機器做負載，負載的工具...
深入理解kafka服務端控制器
kafka集群中有1個或者多個broker，其中有乙個broker會被選舉為控制器 kafka controller 它負責管理整個集群中所有分割槽和副本的狀態。kafka的控制器選舉工作依賴於zookeeper，成功競選為控制器的broker會在zookeeper中建立 controller 這個...
服務端架構設計及功能說明
這個架構圖是自己以前做過的乙個專案的架構圖。簡單介紹一下各個伺服器的功能 外圍伺服器 1 日誌伺服器 接收各個伺服器的執行日誌，並採用執行緒池的方式寫入到相應的裝置中 資料庫或者檔案 2 監控伺服器 監控各個伺服器的運 況，當發現伺服器執行異常時及時傳送報警資訊 以郵件或者簡訊的方式 3 負載平衡伺...