基於OpenResty和Node.js的微服務架構實踐

什麼是微服務？

傳統的單體服務架構是單獨服務包，共享代碼與數據，開發成本較高，可維護性、伸縮性較差，技術轉型、跨語言配合相對困難。而微服務架構強調一個服務負責一項業務，服務能夠單獨部署，獨立進行技術選型和開發，服務間鬆耦合，服務依賴的數據也獨立維護管理。雖然微服務存在部署複雜、運維難度較大、分佈式事務控制難、容錯要求高等缺點，但整體而言，微服務的優勢遠大於其複雜性。

微服務架構須要注意哪些問題？

微服務架構，首先考慮客戶端與服務端之間的通訊問題。有兩種解決辦法，一是客戶端與多個服務端直接進行通訊，但存在對外暴露接口細節、衆多接口協議沒法統1、客戶端的代碼復

雜、服務端升級相對困難等問題。二是客戶端訪問統一的API網關，由API網關調用衆多服務接口，易實現統一通訊協議，下降客戶端和服務端代碼耦合，也能夠達到統一的鑑權和流控，然而此方式存在延時增長的風險，可能使API網關成爲系統發展的瓶頸。

微服務架構是分佈式服務架構，如何進行服務的註冊和發現也是須要解決的問題。一種是經過客戶端發現，調用方須要知道全部依賴服務的地址，開發成本較高，協議升級比較困難。另外一種是經過統一網關發現具體服務的地址，對客戶端來講實現比較簡單，可以在網關進行統一鑑權和流控，要求網關高度可用性。

調用微服務儘量作到有序，避免相互調用，杜絕循環調用。服務間要有清晰的層次關係，上層服務能夠依賴下層服務，若是遇到下層服務須要同步消息給上層調用方的狀況，能夠考慮經過消息隊列異步解耦，好比訂單/審覈系統在建立訂單或者改變訂單狀態時，能夠考慮使用雙寫（即寫入數據庫後，同時在消息隊列也寫一份），異構系統（好比訂單執行系統）能夠經過訂閱消息保存異構數據。

個推在微服務上有哪些實踐？

個推的服務場景主要有三種。其一是個推推送場景，經過Java語言開發，SOA的架構方式來實現，保證信息推送的實時性與高併發性，這塊微服務改造比較困難；其二是廣告交易平臺，好比投放平臺、DMP數據管理，以Java爲主進行開發，對併發數要求較高，咱們在逐步進行基於Java的微服務框架的微服務化嘗試；其三是web業務系統，它爲前端提供無狀態的業務API接口，是典型的request/response方式，同時，這是咱們目前微服務實踐最多的場景。

隨着業務快速發展，公司web相關的業務系統開發需求不斷增長，這些系統都涉及到用戶管理，後臺管理，權限管理等。爲進一步提升團隊開發效率，咱們對服務進行平臺化、模塊化改造，選擇瞭如上的技術選型。

個推的總體架構如上圖所示。請求先通過LVS/HaProxy，到達基於OpenResty實現的API網關，API網關會根據請求將流量upstream到服務單元。服務單元做爲一個總體，支持經過Lua、Node.js、Java等語言實現業務邏輯，啓動時向Zookeeper註冊，API網關會從Zookeeper獲取服務單元部署信息。

服務單元如上圖所示。它由Openresty統一對外暴露服務端，Openresty內置了lua語言，能夠在weblua框架中經過編寫lua程序來進行業務邏輯處理。Openresty經過proxy_pass,upstream將請求轉給webnode處理，也能夠在Openresty中經過配置處理Java業務邏輯。服務單元就像一個抽屜櫃，具體的業務（app）就像一個抽屜，只要尺寸符合抽屜櫃的要求，就能將抽屜推入到抽屜櫃中，抽屜所用的語言不做要求。

Openresty集成了lua腳本做爲編程語言，使用Zookeeper服務註冊。爲了解決lua與Zookeeper不適配問題，在Openresty啓動時啓動websocket服務，Node.js進程啓動時同步啓動websocket的client，這樣每一個Node.js進程會和Openresty保持長鏈接和心跳，Openresty會選擇一個Node.js進程，啓動Zookeeperclient完成服務註冊。API網關也是基於服務單元經過相似的方式實現完成服務註冊的。

服務單元在Openresty層完成了統一鑑權，不會產生額外的性能開銷。

咱們能夠用「通道化」來闡述服務間的調用問題。咱們將微服務之間的調用比喻成水管，從水管的一端流進去的是請求信息，那麼從另外一端流出來的也應該是請求信息，咱們只要求流入流出的信息保持一致，而不關心這些信息在傳輸過程當中通過了轉換或其餘過程。如上圖，A、B之間的調用經過進程內require就能實現，而A、C間的調用是經過服務單元內的http完成的。

Q&A

Q：微服務架構在運維部署是否會很麻煩？

A：隨着微服務的不斷推動，服務數量勢必會愈來愈多，這就須要考慮DEVOPS。好比代碼提交以後經過Jenkins自動觸發打包編譯，自動生成版本號，進而觸發自動測試部署和自動化測試，測試經過後進行一鍵部署升級、支持升級失敗自動回滾等。咱們目前已經實現了自動打包和測試部署，後續環節正在推動。

Q：Openresty裏對Session管理進行了處理，開發人員會不會以爲不方便？

A：在引入微服務框架以前，公司有不少獨立業務服務，每一個服務都有本身的帳號系統實現登陸驗證邏輯。雖然有現成的代碼模塊能夠用，但每次都須要從新測試驗證。現在，具體的業務服務均可以經過Openresty完成鑑權並統一對外，對開發和測試人員來講，反而減小了必定的工做量。