2020年2月13日，Apache Dubbo官方發佈了一條反序列化漏洞（漏洞編號：CVE-2019-17564）的通告，漏洞等級中危。輕舟微服務雖然支持Apache Dubbo，但由於在架構設計上的優化，可保證用戶不會受此次漏洞影響。
漏洞原理及影響範圍
Apache Dubbo支持多種通信協議，官方默認爲Dubbo協議，當用戶選擇HTTP協議進行通信時，攻擊者可以利用該漏洞在目標網站上遠程執行惡意代碼，最終導致網站被控制、數據泄露等。據官方介紹，此次漏洞主要影響Apche Dubbo的以下版本：
-
2.7.0<= Apache Dubbo <= 2.7.4.1
-
2.6.0<= Apache Dubbo <= 2.6.7
-
Apache Dubbo = 2.5.x
官方解決方案：大批量升級風險大
Apache Dubbo官方建議用戶網站升級到安全的2.7.5版本，以解決此漏洞。但這種方式比較激進，貿然大批量升級風險比較大，主要有以下兩方面的原因：
第一，Dubbo歷史比較久遠，版本升級往往不平滑。
很多客戶很早就在使用Dubbo了，Dubbo在2014年停止維護過一次，中間很多客戶切換到噹噹網推出的Dubbox，Dubbo在2017年重新進行維護，這些衆多的歷史版本和分支，涉及到很多的依賴包和中間件。從實踐角度來講，升級絕對不是簡單替換一個jar包這麼簡單，可能會存在大量的不兼容的問題，需要逐步排查，才能成功升級。
第二，Dubbo服務數目較多，批量升級工作量大。
早期使用Dubbo的客戶，經過較長時間的微服務化的歷程，目前服務數目已經比較多，其中包括核心服務，如果只升級部分，可能會出現不兼容情況，批量升級，工作量太大，而且涉及核心業務可能造成停服風險，是客戶很難接受的。
輕舟解決方案：三重機制避免漏洞風險
輕舟微服務是一個基於開源技術棧、支持私有云或公有云等靈活IT架構的一站式雲原生服務平臺，包含微服務框架NSF，應用性能管理APM，容器平臺NCS，分佈式事務GTXS，API網關，PaaS中間件，業務監控，持續集成流水線CI/CD等八大組件構成。
其中和Dubbo關係比較緊密的是微服務框架NSF。
很多客戶在使用開源微服務框架的時候，多采用上圖左面的方式，所有服務管理與治理的功能全部需要自己開發，在業務代碼之外開發量大。而且Dubbo和Spring Cloud有很多的配置，這些配置和代碼邏輯散落在各個工程，每增加一個功能，需要所有的業務重新發布上線。
而輕舟微服務框架NSF，採用全棧字節碼增強技術，0侵入，0性能損耗，納管業務系統。服務管理與功能全部集中在agent中，開發僅需關注業務代碼，二者代碼級分離。並且提供統一的可視化動態治理界面，開發、運維職責獨立分配，更新實時生效。
輕舟微服務框架NSF基於原生Spring Boot技術實現，能夠兼容納管Spring Cloud、Dubbo、Grpc、Istio等主流框架的應用系統，且提供易用性、可視化、安全性、人性化的可視化界面。
那輕舟微服務框架NSF如何解決這次Dubbo的漏洞問題呢？
第一，輕舟微服務框架NSF提供外部服務及服務之間的認證和鑑權機制，可以靈活配置某個服務是否開啓認證鑑權開關，一旦開啓，客戶端請求被Agent攔截，會去NSF進行認證鑑權，只有通過了，才放行，讓請求到達服務端，對於一些核心業務，可以啓用認證鑑權機制，只讓信任的服務調用，可大幅度減少風險。
第二，輕舟微服務框架NSF可以靈活配置服務之間調用的黑白名單，可以用服務名，也可以使用IP地址段。一方面只有信任的服務及IP段可以訪問某些服務，另一方面，一旦發現風險，可以在界面上及時配置，Agent會瞬間下發策略，將風險及時攔截。
第三，從長期來看，Dubbo有Bug還是應該升級的，升級需要有一定的策略，根據服務之間的依賴關係逐層分批升級，從而可以把控風險。使用輕舟微服務框架NSF，可以在界面上看到服務之間的動態依賴關係，可以根據這個依賴關鍵，進行逐步的升級。
最佳實踐建議：面對漏洞，風險可控
輕舟是針對微服務架構的全棧解決方案，除了產品之外，網易在自身業務落地的過程中，也總結出來了全方位的最佳實踐，可以提供諮詢服務。針對Dubbo的漏洞問題，輕舟微服務團隊給出了以下最佳實踐建議，即便Dubbo有漏洞問題，也能及時的控制風險。
第一，容器層：在容器層最佳實踐中，裏面有很重要的兩條，一是容器鏡像儘量小，刪除不必要的工具，這樣即便部署在容器裏面的Dubbo服務被侵入，容器內部也沒有什麼命令可以執行。二是不要使用privileged運行容器，這樣容器即便被侵入，也無法逃逸到宿主機中。
第二，Kubernetes層：對於Kubernetes，不建議所有的Pod都默認互通，而是啓用適當的NetworkPolicy進行隔離。
第三，微服務層：Dubbo服務的升級的確是很頭疼的事情，因爲服務多，依賴關係複雜，但是如果秉承以下的最佳實踐，則升級會輕鬆一些。
規範之一：僅僅單向調用，嚴禁循環調用。
微服務拆分後，服務之間的依賴關係複雜，如果循環調用，升級的時候就很頭疼，不知道應該先升級哪個，後升級哪個，難以維護。
因而層次之間的調用規定如下：
-
基礎服務層主要做數據庫的操作和一些簡單的業務邏輯，不允許調用其他任何服務；
-
組合服務層，可以調用基礎服務層，完成複雜的業務邏輯，可以調用組合服務層，不允許循環調用，不允許調用Controller層服務；
-
Controller層，可以調用組合業務層服務，不允許被其他服務調用。
如果出現循環調用，例如A調用B，B也調用A，則分成Controller層和組合服務層兩層，A調用B的下層，B調用A的下層。也可以使用消息隊列，將同步調用，改爲異步調用。
規範之二：接口數據定義嚴禁內嵌，透傳
微服務接口之間傳遞數據，往往通過數據結構，如果數據結構透傳，從底層一直到上層使用同一個數據結構，或者上層的數據結構內嵌底層的數據結構，當數據結構中添加或者刪除一個字段的時候，波及的面會非常大。
因而接口數據定義，在每兩個接口之間約定，嚴禁內嵌和透傳，即便差不多，也應該重新定義，這樣接口數據定義的改變，影響面僅僅在調用方和被調用方，當接口需要更新的時候，比較可控，也容易升級。