拍拍信作為一家專業的數據服務公司，承載著百億級數據量，每天支撐著千萬級的調用量，對數據的安全、用戶需求響應時效、系統的穩定都有著極其嚴格的要求，在此大前提下，拍拍信踏入微服務化之路。
截止發稿，拍拍信在微服務的道路上已經走過一年有餘，90%以上的服務已經投產，整個微服務生態體系也逐漸發揮出不凡的表現，比如快速自動化水平擴展、無值守升級、流量零損耗發佈等。
拍拍信網關概述
拍拍信微服務基於Spring Cloud實施落地，由於其已經集成了Netflix Zuul，也符合拍拍信的技術棧, 能滿足快速應用和二次開發，其官方對Zuul的定義如下：
Zuul is the front door for all requests from devices and web sites to the backend of the Netflix streaming application. As an edge service application, Zuul is built to enable dynamic routing, monitoring, resiliency and security. It also has the ability to route requests to multiple Amazon Auto Scaling Groups as appropriate.
簡單來說，Zuul是所有請求的前端入口，並轉發到後端服務，作為一個邊緣服務應用，Zuul支持動態路由、監控、彈性和安全。它類似於 Servlet 中過濾器（Filter）的概念，提供了四種過濾器的 API，分別為前置（Pre）、後置（Post）、路由（Route）和錯誤（Error）四種處理方式，附上標準流程，如下圖：
但是Zuul的天生不足也比較明顯，需二次開發才可應用於生產環境，首先，它只是一個框架，並不具有運營能力，投產的系統往往都需要一個管控後臺，其次因為它是邊緣服務應用，所以必須做到穩定、持續服務，也就意味著它是長駐服務，不能因為內部業務升級、新開業務等因素重啟網關等。不足之處具體表現為：
● ZUUL自身提供的Monitor&Tracer功能薄弱，無法需足業務需要；
● Spring Cloud雖然集成了ZUUL，但路由表為靜態配置，需要運行時增加、修改；
● 不具有http報文攔截、過濾、轉換功能；
● 網絡屬性配置（如：Socket Timeout）沒有靈活的API，且是靜態配置（這個是Ribbon的鍋）；
● 本身並沒有提供鑑權認證機制、數據安全等功能；
● 運行指標監控、告警功能缺失，雖然可以配套Turbine使用，但也需要二次開發。
最終，經二次開發改進之後的功能模塊包括如下：
整體架構如下：
從業務角度出發
拍拍信網關研發之初，實際業務中的一些痛點問題及需求：
● 服務通訊協議多樣化，需要業務各自實現，導致代碼重複寫；
● 接口缺少完善的監控，發現不及時，問題排查慢等，造成業務受損；
● 接口調用記賬收費無統一入口，會產生多記、漏記、錯記等問題；
● 接口流量突增，影響其他客戶的調用，導致用戶滿意度下降；
● 內部接口的發版等變更時會導致外部接口的調用失敗，接口穩定性下降；
● 接口還會受到一些DDoS及漏洞掃描及爬蟲等非法訪問對網關安全提出新的要求。
Zuul二次開發&業務支撐
● 路由配置管理：
當業務團隊數量增多，業務系統數量增加，不斷的持續開發、升級、發版、新業務線的開通上生產，完全無法控制API數量，假如每改動一個API、新增一個API都需要配置路由並重啟生效，而此時用戶的調用還沒有結束，強制重啟會導致用戶方異常，即使可以採用Nginx、Haproxy負載方案解決問題，那麼也要配置路由、重啟網關，可想系統得多麼糟糕。
我們採用將路由信息持久化到數據庫中的方案，系統啟動時將路由配置加載到內存中，並採用推拉結合的方式，運行時更新內存中數據，達到真正的動態路由。
需注意：系統啟動和加載路由配置的先後順序，要保證系統啟動成功時，配置信息已經加載完成，否則因為路由配置不全，用戶請求已經到達，會導致部分請求失敗。
● 路由配置發佈：
很多公司在服務升級發版時，都非常小心謹慎，如履薄冰，即使在線下經過充分測試，也難免到生產環境出事故，為了降低影響面，拍拍信網關提供了路由配置灰度發佈、一波流發佈、版本回滾功能，可以分批次通過RocketMQ消息通知的方式發佈，指定某幾個服務節點生效，一旦發現監控指標異常，可以利用版本回滾功能回退到之前版本。
● 協議適配&報文檢查、過濾、轉換：
做為一家數據服務公司，接口協議類型也是多樣化的，如：JSON、XML、HTTP，為了簡化業務開發，數據在網關層利用Zuul Filter對報文統一處理，格式化為key/value對後再轉發到下游，使內部業務開發標準化。
提供邊緣服務，要確保數據正確性，拍拍信網關提供了嚴格的數據校驗配置，比如：數據類型、數據長度、值大小、枚舉、時間區間、正則表達式、腳本化支持等，可以濾掉非正常請求，避免內部業務受到衝擊。
此外，即便用戶傳入數據都正確，一些特定業務場景下，仍不能直接將數據轉到下游，比如用戶傳入的參數叫idCard，但是下游需要的參數名是idNumber，這就需要用到參數名稱轉換功能，甚至可以調用Groovy腳本運算產生參數值，或者添加、修改HTTP請求頭信息等。除非下游需要的參數及參數值就是用戶傳入的數據，這種情況下，我們支持一種面向接口維度的“透傳”工作模式。同請求報文處理一樣，響應報文也具有“透傳”和“轉換”功能，以達到接口標準化目的。
● 網絡屬性配置管理：
Spring Cloud集成的Zuul，提供了socket-timeout-millis配置項，Ribbon提供了ReadTimeout配置項，如果要面向API且可以運行時動態調整，原生靜態配置達不到需求。
另一點，微服務場景下，服務之間調用錯綜複雜，要想知道某一次請求來自哪個調用方，實屬困難，可以藉助來源IP定位，不過更便捷的方法是設置Agent來標記。
● 資源隔離
首先說下限流，目的是保護後端服務，在面對大流量時不致於被壓垮，當負載過重時丟棄一部分流量。但是限流是基於服務還是接口，需要根據業務情況慎重考慮。還可以做到按用戶、按接口多維度分配資源，避免單用戶佔用所有線程資源。
當前拍拍信網關結合Ribbon+Hystrix實現按接口維度限流、熔斷&降級，資源隔離採用信號量（推薦使用信號量做資源隔離，原因是Hystrix內部用原子類計數器實現信號量，更輕量，如果採用線程池模式，會導致線程數量陡增，反而增加線程調度的開銷。）
另一點需要注意，Hystrix提供了服務超時配置，如果業務多是網絡化調用，這種場景下，建議關閉Hystrix的超時功能，改用依SocketTimeOut為準，否則超時配置容易錯亂且不易維護。
● 鑑權認證&驗籤
數據在網絡流動過程中，面臨被篡改的風險，為削減數據被篡改的負面影響，我們做到按接口維度可視化選擇採用數據驗籤方式，目前支持：MD5、SHA、JWT、TOKEN 4種方式。
● 服務發現
內部業務系統升級時，發佈平臺自動將對應節點從集群中註銷。隨著業務量的不斷攀升，現有集群不足以支撐業務時，系統會自動水平擴容。
● 運行指標監控&告警及日誌
1. 多維度實時監控&告警；
按用戶和接口維度監控流量、錯誤率攔截量，及網關係統運行狀態等，如:GC、IO異常、負載均衡度等，通過監控平臺配置告警規則、告警渠道等，全天候不間斷自動巡檢，實時感知業務狀態，配合內部值班制度，實時發現用戶調用狀態並及時聯繫解決。
2. 邊緣服務訪問統計&日誌記錄；
a) 詳細記錄接口訪問的入參、出參，以及內部流轉過程、數據，使用Logstash推送到ES，在需要回溯問題時，可得到用戶調用時的詳細信息及接口返回信息，幫助用戶定位問題，做到有據可查。
b) 通過網關管控後臺配置接口是否收費記賬、記賬數據格式，運行時灰度發佈動態生效，統一收口收費記賬邏輯。
● 微服務遷移過移中的融合
微服務實施需要考慮對業務產生的積極、消極影響，首先要保證業務不能停擺。其次要提供良好的遷移、接入體驗，服務好業務團隊才能使網關順利推廣、投產，當然也缺不了公司績效壓力，在整個網關推進過程中，包含以下幾個階段：
1. 純代理模式階段：承載全網所有流量並轉發到下游，但不參與業務過程，經過流量洗禮後更加提升了產品信心；
2. 代理和工作模式並存：業務工程遷移是個漫長的過程，可能要經過數週數月，所以由業務團隊決定接口在哪種模式運行；
3. 純工作模式&複合階段：在經過前兩個階段後，大多數接口已經接入網關，這時候網關不僅承擔了流量入口，還承擔了業務入口的角色，通用、全局的業務規則由網關負責執行處理。
結語：
兵馬未動，糧草先行，是為了解決後顧之憂，軟件產品除了滿足業務需求之外，更需要關注的是產品體驗，運行狀態反饋、業務狀態反饋等，從而促進產品優化，再優化以達到最佳狀態。可用性基本決定了產品的口碑，而可運營則給產品增加了生命的魔力，管控&監控更是驗證產品的運行表現是否符合預期。
期待後續：
● 基於網關配置，生成Swagger Api 文檔
● 微服務治理
● 鏈路跟蹤
歡迎有興趣的小夥伴通過官網聯繫我司相關產品。
閱讀更多 拍拍信 的文章
