網盤統一視圖服務

1. 單個項目的先後端分離好作，那n多個項目一塊兒嘞？
2. 如何基於常規的先後端分離模式，作更高效的提高
3. 前端分離模式的PAAS能力如何提供？

背景

隨着部門內前端的業務線和平臺愈來愈多，前端的職責也逐漸加劇，隨之而來的就是各類問題和挑戰。目前前端團隊共有31我的，共負責15+業務/項目和平臺，前端項目的總PV最低也在2000萬以上，因爲是工具類型的應用，MAU（月活用戶）也有1億以上。面對這麼大的用戶體量和業務壓力，團隊在開發和維護的過程當中也逐漸遇到了各類問題。

首先是基礎設施的問題，沒有完善且統一的標準規範和設施，致使每一個項目的技術棧和實現思路各不相同，功能複用率不高。在成員提高方面，這麼多的成員如何讓他們在技術和解決問題的能力上都有所提高。另外還有其餘角色更加關注的效能提高的問題，包括前端開發效率的總體提高，以及上下游協做效率的提高。最後是總體穩定性方面的保證，須要在第一時間發現錯誤和體驗相關的問題，這又是一個很重要的問題。

解決思路

面臨以上的問題，咱們從不一樣的角度和維度出發嘗試解決。第一個維度是從外部到內部，主要是從流量的出發，依次是前端、視圖層、後端等，以及總體的穩定性保證等。第二個維度就是從上游到下游，從項目迭代的流程入手，從開始的UE/UI同窗的交互和視覺設計，到FE同窗的開發，再到下游QA同窗的測試。優化協做流程和細節，提高總體的協做效率。

解決方法

通過兩個維度的拆解，咱們大體提出了四個解決方法。其中屬於第一維度的有兩個，分別是統一視圖服務和自動化監控，屬於第二維度的有前端組件庫和物料中臺。

本文章的重點就是講解統一視圖服務，如何基於基礎的先後端分離模式，更好地解決問題和提高效能。

統一視圖服務

背景

前端除了本身的本質工做外，還會負責先後端之間的膠水層，也叫視圖層，主要包括路由控制、視圖渲染、數據處理/聚合、資源管理、CDN優化等。在維護視圖層的過程當中，發現大部分的業務之間的視圖層使用的框架和實現方式都不相同，並且每個大的業務方向都有本身獨立的視圖服務。這樣致使了前端對渲染服務的開發維護，學習和接入成本都很高。而後是職責優化，完全梳理清除先後端之間的模糊地帶，讓先後端的職責更加清晰，專一於提升各方的生產力。最後在職責上完成優化後，在總體架構上能夠完全與後端一塊兒完成微服務化。

解決方法

面臨以上問題，首先是統一部門內不一樣的渲染服務（視圖層），進行歸一化管理，第二是彈性擴展的能力，實現最小成本接入不一樣的項目和能力擴展。第三是同構支持，統一解決不一樣場景下SEO、總體性能提高和用戶體驗的問題。最後是微服務架構，接入後端的微服務架構，讓服務更加的獨立。

難點

首先就是性能要求，對多業務/服務的支持能力，數據源聚合能力，千萬級PV的請求壓力應對問題。固然最主要的是多產品線接入的成本以及接入以後的性能和維護問題。 第二是靈活/穩定的要求，提供平臺化支持，保證服務間正交關係，總體平臺化的監控、運維。

性能要求

對於性能要求的保障，以下圖：

流量經過BGW和BFE以後，會到達網盤微服務的網關，負責分發請求，用戶鑑權，流量分級和其餘功能。gateway主要會將請求轉發到統一視圖服務或後端服務。統一視圖服務集羣中的容器內部都會有inner router和渲染服務。Gateway將請求轉發到視圖服務後，先被inner router接收，它負責下游渲染服務的拓撲和流量處理，再反向代理到渲染服務若是渲染服務的壓力過大，會通知inner router，讓它再去請求其餘的渲染服務實例，保證可用性。渲染服務和後端服務的交互使用BNS和UFC實現，內部對協議作了統一的處理，也包括IDC機房優化。藉助網盤微服務的能力，保證了在性能上的要求。

以上是視圖層所提供的最基礎的能力，可是爲了提現統一管理不一樣產品線的能力，咱們還提供了部分PAAS的能力，如接入層配置，負責在網關和inner router上自行處理流量和拓撲。一鍵工具包，提供快速初始基礎框架和運行時，及守護進程、監控、日誌處理等功能。而後接入的業務方就能夠只需對業務代碼進行增量上線便可。

另外，還對渲染服務進行部署級別分級，提供公共部署和私有化部署，公共部署爲內部平臺服務，私有部署爲線上產品服務。

穩定性和靈活性保障

對於靈活和穩定保證。借鑑微內核架構的思路，抽離出通用的功能和機制，封裝成系統核心。它是一個服務實現的最小功能集。

在core的外面的增長了對應的企業內通用服務，IDC優化及跟蹤機制，鑑權和數據聚合能力，封裝成通用企業級框架。

在企業框架的外面，又增長了網盤內通用的功能，包括渲染機制，APP隔離，AB測試灰度發佈，封裝成部門級通用框架。

最後在部門框架上運行業務和服務，包括商業化，內容商城，開放平臺，和網盤的業務。

經過這四層，讓應用能夠在橫向和縱向兩個維度上任意伸縮。提供很是強的靈活擴展能力。

總體架構

總體架構從上到下依次是應用框架，部門框架，企業框架，基礎服務和底層支持。經過在每一層增長不一樣的能力而後使用相似compose的操做擴展在基礎服務上。

最後，經過這樣一系列的設計和操做，保證了整個視圖服務的性能、對靈活、穩定和擴展性的要求。

收益

1. 部門內的前端項目/平臺統一在統一視圖服務PAAS上管理
2. 更前的場景實驗和落地的能力
3. 產品性能大幅度提高
4. 大幅度節省硬件資源，如今的產品線機器在幾百臺（全量業務）以上，而統一管理以後僅需20個1核CPU容器（視圖渲染服務）便可知足。

關於壓測數據

20個容器支持2000萬PV（926QPS），正常性能要求下可支持1000QPS，意味着每秒發送的1000個事務處理中，95%的請求都會在1s內處理完畢並返回。 並且，是線上總體上下游的測試數據，不是單純的測試nodejs，由於單純的測試nodejs沒有意義，畢竟沒有任何一個線上服務會只用一個nodejs實現。

服務的吞吐量提高在427%，併發下的平響提高74.7%，非併發下的提高是47.7%。

關於不能很好量化的收益

1. 統一視圖服務提供PAAS能力，使視圖層統一管理，節省資源，提高開發和接入效率。
2. 職責分離，專一核心業務
3. 給前端提供更多的可能性，使用各類花活兒提高效率。

最後

講的有點粗糙，有任何疑問和更多瞭解請聯繫做者。