叩丁狼開發工程師：SSR服務架構特點分析

　　SSR服務架構是我們在搭建一些開放性平臺的時候需要添加的一項功能應用，而今天成都軟件開發工程師就通過案例分析來了解一下，關于SSR服務架構的特點都有哪些內容?

　　1、抵抗單頁面大流量 要抵抗單頁面的大流量，先我們自然而然會想到會使用緩存，與此同時我們也需要保證頁面的及時響應，因此針對這個問題我們一般會使用CDN服務。由于CDN遵循就近原則，因此客戶端請求對應的頁面及其數據是會被自動分配到延遲低的CDN節點上，如果我們正確的設置對應的HTTP相關緩存，是會得到很好的低延遲加載效果。 那么當臨近CDN節點緩存失效怎么辦呢?

　　這個時候CDN根據對應配置也能很好的幫助我們嘗試回源到目標服務器上，從而完成整個數據的加載。并且由于CDN到目標服務器上的網絡一般采用更優化的網絡鏈路，因此相對于客戶端直接請求目標服務器來說，會有很大的低延遲優勢(客戶端到CDN的節點是鄰近的，CDN到目標服務器是更優化的網絡鏈路)。 但需要注意的是，對于資源的回源HTTP緩存頭設置我們一般需要讓其遵循源站方便業務端控制。同時也需要將其設置為一個比較合理的數值，否則非常容易造成緩存長時間不失效的問題。

　　2、秒級的發布與回滾 在此新架構之前，整個系統的發布和回滾是非常不可靠、緩慢且不靈活的，對于一次發布而言如果牽扯到非常多的子模塊和子系統，那么耗時20多分鐘是非常頻繁的事情。由于新的架構是以平臺化來進行設計，其希望能夠接入更多的團隊和項目產品，因此我們需要非常簡便及可靠的發布邏輯作為支撐。

　　由于sis和sis-ssr所有組件相關信息都是以依賴表為基礎，因此我們很容易在不涉及任何SSR服務下進行，其過程如下： 將對應目標產物同步至Combo服務，若失敗則直接阻斷 將對應目標產物同步至AWSS3中，若失敗則直接阻斷 修改Database的相關表中依賴表的路徑信息，失敗則直接阻斷 刷新Redis的依賴表的路徑信息，設置失效時間

　　3、系統安全與運行隔離 既然作為一個開放的平臺化系統，那么關于整體的系統安全也是需要考慮的一個重要問題。由于組件的開發可以被下發給其他團隊，因此其中的不可控性非常的高，況且整個組件的開發還會涉及到SSR的服務端邏輯，那么如果寫出風險性的代碼是非常存在可能性的。

　　試想，如果A團隊編寫的SSR端代碼內部包含了了process.exit(0)，那么導致整個進程被重啟，實際上會造成非常大的困擾。因此我們在運行過程中需要盡可能的做到運行隔離，限制SSR端代碼可調用的基礎庫，保障整個系統的安全運行。

?

總結

以上是生活随笔為你收集整理的叩丁狼开发工程师：SSR服务架构特点分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。