•  單個項目的前后端分離好做，那如果n多個項目一起呢?
• 如何基于常規的前后端分離模式，做更高效的提升
• 前端分離模式的PAAS能力如何提供?

[[284532]]

背景

隨著部門內前端的業務線和平臺越來越多，前端的職責也逐漸加重，隨之而來的就是各種問題和挑戰。目前前端團隊共有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. 給前端提供更多的可能性，使用各種花活兒提升效率。