背景
58集團作為國內領先的分類信息網站，服務於眾多的中小企業。而對中小企業來說，信息化能力不足，制約企業發展。58開放平臺是基於58集團海量的用戶，將強大的營銷、數據等能力通過API接口、消息通知、插件化服務等形式開放給開發者，幫助開發者創建更具競爭力的應用。
作為58集團與外部系統通信的重要平臺，技術架構由早期的單體架構、集中部署，到現在的單一職責、獨立部署、去中心化。以及支持多種協議下的API網關、TCP消息推送、降級限流、監控數據可視化等技術。
58開放平臺每天承載著海量的API調用和消息通知，為眾多的第三方系統提供了高可用，高性能的API接口。支撐了58集團多個業務線業務增長。 本文主要呈現58開放平臺架構的關鍵點。
整體架構如下
網關和容錯
開放平臺對接的業務線眾多，不同的業務線所提供的接口協議也大相徑庭（rpc、http、esb等），不同的業務線對接口的權限要求也不盡相同。為了實現將這些內部數據安全可控的開放給外部的第三方開發者來進行調用，以及快速的進行API接入，數據報文轉化，開發了開放平臺的API網關。API網關在架構設計上採用了多層接口，到達網關的請求數據由網關攔截處理。
在接入層進行2個主要環節處理
- 網關的防禦性校驗：鑑權，限流降級，數據正確性校驗等。
- 網關接入分發：網關分發會根據網關注冊中心的數據進行協議解析，之後動態構建調用示例，完成服務泛化調用。
網關鑑權
58集團內部的數據分佈在各個獨立的業務系統中，為了將內部的數據安全可控開放給外部，平臺api網關提供了多種鑑權方案。
OAuth2
oauth授權是指開發者系統是否具備用戶指定範圍的授權。如開發者系統訪問用戶的帖子信息、使用用戶賬號發帖。其流程如下：
設計思路：用戶訪問開發者應用時，開發者應用調用五八授權登錄頁面，用戶確認相關授權後，五八授權服務回調開發者應用，同時攜帶授權碼(code)作為該用戶授權唯一憑證，開發者應用使用該授權碼(code)獲取令牌。
對稱加密
對稱加密鑑權適應場景為通用能力API，通用能力API是將58集團內部的技術能力通過開放平臺提供給第三方開發者（如房價評估、圖片鑑黃、語義識別等）的一類API。與Oauth2不同的是，對稱加密鑑權沒有了中間用戶授權的概念。
第三方開發者在58開發者站點註冊賬號並創建APP後，系統會分配一個APPKEY和APPSECRET。開發者調用時，按照規則對參數進行排序處理，並以APPSECRET作為秘鑰生成SIG，開放平臺接到請求對SIG進行比較鑑權。
token令牌
Token令牌是對稱加密鑑權的一種補充和完善，適用場景為第三方平臺希望將自己的權限授權給外部設備（如手機客戶端），又不方便將秘鑰洩露給第三方。
第三方開發者使用APPSERET的方式，請求授權服務器，將獲取到token分配給外部設備，外部設備將token作為參數直接請求開放平臺的api。開放平臺根據token對接口進行鑑權。
token方式能夠更加細粒度的控制權限，如在獲取token時可以指定token的API權限範圍，過期時間，和使用次數。
網關平滑限流
由於各個業務線API的服務能力不同，為了保證各個API能夠穩定提供服務，防止非預期的請求對系統壓力過大而拖垮業務系統。多維度的網關平滑限流控制成為了網關的重要組成部分。
考慮到開平臺分佈式集群部署的因素，API網關採用的是redis+lua的方式實現了秒級的多維度令牌桶算法的流控。
令牌桶算法示意圖如下：
設計思路為：當請求到來後，根據請求參數獲取到當前請求的所有流控策略。根據流控策略可以生成流控的唯一KEY（比如API和APP的流控策略為prefix_apiid_appid）、流控時間粒度、限制次數等。使用lua腳本獲取對應key值的令牌和進行判斷是否需要填充令牌。
開放平臺提供多維度的流控策略，可以使業務方根據自己的需求更加精細的流量控制。
網關熔斷降級
當我們遇到調用後端接口超時或異常時，後端服務無法立即恢復，此時請求走到後端已經沒有意義。這時就需要引入熔斷降級，當異常達到我們預設的閾值，進行降級處理，再次調用時網關直接返回拒絕失敗。熔斷策略可以進行靈活配置，比如當接口連續N次訪問超時和返回錯自動熔斷，也可以手動設置一些超時時間，當連續N次調用時長都超過M秒，自動進行熔斷。
目前開放平臺熔斷降級採用的是Hystrix，Hystrix支持線程池和信號量兩種隔離方案，因為開放平臺的業務場景存在大量API和API分組，每個API又需要路由到不同的後端服務。為了避免產生大量的線程，我們採用了信號量做隔離，我們為每個API提供一個降級配置。業務方可以根據選擇進行配置，比如達到多少錯誤率、失敗次數等進行熔斷降級。
隔離
開放平臺為數量眾多的API提供支持，這些API對吞吐量、平均響應時長、平均響應數據量、併發數等眾多指標要求不盡相同。比如訂單服務有最低響應時長要求短，請求響應數據小，併發數量大的特點，而圖片上傳服務響應時間高、數據量大、併發度低的特點。如果將兩個服務放在一起處理，勢必會互相影響。另外當某一個業務線集群，或某一個API的服務出現問題時，也有可能會對其他服務造成影響。
為了解決上述問題，開放平臺引入了線程池隔離機制。
線程池隔離主要是針對API組不同，按照權重區分使用不同的線程池，以達到某個API業務出現問題，不會講故障擴展到其他的API組中，從而達到保證業務的高可用。
如下圖所示，當房產服務不可用時。如果多個業務線公用一個線程池時，線程池必然會產生大量的異常房產服務的線程，擠佔了其他正常業務線的處理。最終導致整個服務的不可用。
線程池隔離的技術主要採用的是分組多線程池方式，系統為不同的API根據權重不同，初始化不同線程池。當API請求流量到來，根據不同的API使用對應線程池的線程來處理。當某一個API出現問題，受影響的只有API所在組的服務。
消息實時推送
消息實時推送是58開放平臺的核心組成部分。原有平臺提供API供開發者獲取數據，但實時數據的獲取，如果通過輪詢網關，大量空轉不僅非常低效而且浪費服務器資源。基於此，開放平臺推出了消息推送技術。提供一個實時的、可靠的、異步的雙向數據交換通道，提升API網關性能。
58開放平臺消息實時推送是基於netty框架的keeplive的nio網絡模型實現，實現了為開發者提供近百萬級的併發連接通道，保證了數據及時有效的通知給第三方開發者。
使用統一的ESB異步接入，根據不同的業務通過不同的topic進行隔離，避免了數據量大的業務對其他的業務造成阻塞。RPC方式是對ESB方式的一種補充，方便那些不便使用esb的業務線進行接入。平臺提供一個RPC接口，接入方按照規範調用SCF接口進行消息推送。採用這種架構，消息中心與其他系統進行了解耦，即便消息量激增，對其他系統的影響也會很小，能夠提供可靠穩定的服務。
消息系統使用了broker分發模式。模塊化可拔插的處理方式，使新的消息源接入變得極為簡單，大大的縮短了開發週期。
基於netty作為網絡層架構，構建海量推送模型，通過使用keeplive長連接實現從消息接收、推送、確認、整個過程的全部一異步化處理。
總結和展望
由於篇幅原因，開放平臺還有很多技術細節不能一一介紹，如鏈路調用日誌，基於kakfa-storm-es 數據統計和告警等。
58開放平臺經過一年多的發展，在性能、穩定性、內容豐富度上都有了長足的進步。
下一步的規劃是引入服務市場，組件化建設，豐富接入端，支持小程序，H5等方式的接入。引入serverless來支持公司技術能力和資源的開放與共享。
歡迎大家關注“58架構師”微信公眾號，定期分享雲計算、AI、區塊鏈、大數據、搜索、推薦、存儲、中間件、移動、前端、運維等方面的前沿技術和實踐經驗。
閱讀更多 58架構師 的文章
