讀書筆記： 《億級流量網站架構核心技術》(開濤的那本)

這本書知識範圍廣，但都淺嘗輒止，能夠用來開闊視野，因爲以前看過李智慧的《大型網站技術架構》，有部份內容是重合的，因此翻起來比較快。這裏只記錄下以前沒太瞭解的點

第1章：交易型系統設計的一些原則

開場白太棒了，想所有記錄下來，本章還記錄了一些設計的原則。

一、一個好的設計要作到，解決現有需求和問題，把控實現和進度風險，預測和規劃將來，不要過分設計，從迭代中演進和完善。

二、墨菲定律：

• 任何事都沒有表面看起來那麼簡單。
• 全部的事都會比你預計的時間長。
• 可能出錯的事總和出錯。
• 若是你擔憂某種狀況發生，那麼它就更有可能發生。

三、康威定律：

• 系統架構是公司組織架構的反映。
• 應該按照業務閉環進行系統拆分/組織架構劃分，實現閉環/高內聚/低耦合，減小溝通成本。
• 若是溝通出現問題，那麼久應該考慮進行系統好組織架構的調整。
• 在合適時機進行系統拆分，不要一開始就把系統/服務拆分得很是細，雖然閉環，可是每一個人維護的系統多，維護成本高。

第2章：負載均衡與反向代理

第3章：隔離術

目的：將系統或資源分隔開，在系統發生故障時，限定傳播範圍和影響範圍，不會出現雪球效應。

一、隔離方式：

這塊以前瞭解相對較少，能夠偶爾翻翻目錄擴展下隔離方式技術的視野。包含了線程隔離、進程隔離、集羣隔離、機房隔離、讀寫隔離、動靜隔離、爬蟲隔離、熱點隔離。

二、Hystrix隔離

三、基於Servlet3實現請求隔離

• 將請求解析和業務處理線程池分離
• 線程池隔離能夠方便對整個系統的把控，如根據業務重要性對線程池分解、隔離、監控、運維、降級
• 異步化能夠帶來更高的吞吐量，但響應時間也會變長。異步化並不會提高響應時間，但會增長吞吐量和咱們須要的靈活性。

第4章：限流詳解

目的：經過對併發訪問/請求進行限速或者一個時間窗口內的請求進行限速來保護系統，一旦達到限制速率則可用拒絕服務、排隊或等待、降級。

一、限流算法：

令牌桶算法、漏桶算法

二、不一樣層次限流：

應用級限流、分佈式限流、接入層限流

三、節流：

在特定時間窗口內對重複的相同事件最多隻處理一次，或者想限制多個連續相同事件最小執行時間間隔，那麼可以使用節流實現，其能防止多個相同事件連續重複執行。節流主要有幾種用法：throttleFirst、throttleLast、throttleWithTimeout。

第5章：降級特技

目的：降級的最終目的是保證核心服務可用，即便是有損的。

一、降級預案：

頁面降級、頁面片斷降級、頁面異步請求降級、服務功能降級、讀降級、寫降級、爬蟲降級、風控降級

二、關鍵字：

自動開關降級、人工開關降級、讀服務獎、寫服務降級、多級降級、統一配置中心（參考有贊降級熱熔斷系統Tesla）

三、Hystrix原理實現

這部分以前收集的博客系列更加詳細。

第6章：超時與重試機制

一、使用超時與重試機制的緣由

實際開發過程當中，有許可能是由於沒有設置超時或者設置得不對而形成的。若是應用不設置超時，則可能會致使請求響應慢，慢請求累積致使連鎖反應，甚至形成應用雪崩。讀服務自然適合重試，寫服務須要根據實際狀況（如是否作冪等）。重試次數太多會致使多倍請求流量，即模擬了DDos攻擊（參考有讚的Token鑑權超時重試致使流量翻倍，擊垮五倍容災的機器，進而影響線上）。

二、超時與重試機制的分類

• 代理層超時與重試
• Web容器超時
• 中間件客戶端超時與重試
• 數據庫客戶端超時
• NoSql客戶端超時
• 業務超時（如訂單超時未支付取消任務、活動超時自動關閉等）
• 前端Ajax超時

三、超時策略處理

• 重試（等一會再試、嘗試其餘分組服務、嘗試其餘機房服務，重試算法可考慮使用如指數退避算法）
• 摘掉不存活節點（負載均衡/分佈式緩存場景下）
• 託底數據（返回歷史數據/靜態數據/緩存數據/）
• 等待頁或者錯誤頁

第7章：回滾機制

一、回滾概念

當程序或數據出錯時，將程序或數據恢復到最近的一個正確版本的行爲。最多見的如事務回滾、代碼庫回滾、部署版本回滾、數據版本回滾、靜態資源版本回滾等。經過回滾機制能夠保證系統在某些場景下的高可用。

二、事務回滾

單庫事務回滾這裏就很少說了

分佈式事務：最多見的如兩階段提交、三階段提交協議，這種方式實現事務回滾難度較低，可是對性能影響較大，由於咱們大多數場景中須要的是最終一致性，而不是強一致性。所以，能夠考慮如事務表、消息隊列、補償機制（執行/回滾）、TCC模式（預佔/確認/取消）、Sagas模式（拆分事務+補償機制）等實現最終一致性。

三、部署版本回滾：

部署版本化、小版本增量發佈、大版本灰度發佈、架構升級併發發佈

第8章：壓測與預案

在大促來臨前，通常會對現有系統進行梳理，發現系統瓶頸和問題，而後進行系統調優來提高系統的健壯性和處理能力。通常經過系統壓測來發現系統瓶頸和問題，而後進行系統優化和容災（如系統參數調優、單機房容災、多機房容災等）。即便系統優化和容災作的很是好，也存在一些不穩定因素，如網絡、依賴服務的SLA不穩定等，這就須要咱們制定應急預案，在出現這些因素後進行路由切換或降級處理。在大促前進行預案演戲，肯定預案的有效性。

一、系統壓測流程

壓測前要有壓測方案【如壓測接口、併發量、壓測策略（突發、逐步加壓、併發量）、壓測指標（機器負載、QPS/TPS、響應時間）】，以後要產出壓測報告【壓測方案、機器負載、QPS/TPS、響應時間（平均、最小、最大）、成功率、相關參數（JVM參數、壓縮參數）等】，最後根據壓測報告分析的結果進行系統優化和容災。

二、線下壓測

經過如JMeter、Apache ab壓測系統的某個接口或者某個組件，而後進行調優，實現單個接口或組件的性能最優。

三、線上壓測

按讀寫分爲讀壓測、寫壓測和混合壓測，按數據仿真度分爲仿真壓測和引流壓測，按是否給用戶提供服務分爲隔離集羣壓測和線上集羣壓測。

單機壓測能夠評估出單機極限處理能力，但單機壓測結果不能反映集羣總體處理能力。

在壓測時，須要選擇離散壓測，即選擇的數據應該是分散的或者長尾的。爲了保證壓測的真實性，應該進行全鏈路壓測。

三、系統優化

拿到壓測報告後，接下來會分析報告，而後進行一些有針對性的優化，如硬件升級、系統擴容、參數調優、代碼優化（如代碼同步概異步）、配置調優、慢查詢優化、架構優化（如加緩存、讀寫分離、歷史數據歸檔）等。

四、應用擴容

可根據去年流量、與運營業務方溝通促銷力度、最近一段時間的流量、預計GMV增加等來評估出是否須要進行擴容，須要擴容多少倍。擴容以後還要預留一些機器應對突發狀況，在擴容上儘可能支持快速擴容，從而在出現突發狀況時能夠幾分鐘內完成擴容。

五、系統容災

在擴容時要考慮系統容災，好比分組部署、跨機房部署。容災是經過部署多組（單機房/多機房）

相同應用系統，當其中一組出現問題時，能夠切換到另外一個分組，保證系統可用。

六、須要應急預案的緣由

在進行系統容災後，仍然會存在一些風險，如網絡抖動、某臺機器負載太高、某個服務變慢、數據庫oad值太高等，爲了防止由於這些問題而出現系統雪崩，須要針對這些狀況制定應急預案，從而出現突發狀況時，有相應的措施來解決掉這些掉這些問題。

七、應急預發步驟

首先進行系統分級，而後進行全鏈路分析、配置監控報警，最後制定應急預案，預案演練等。

八、系統分級

針對交易型系統能夠按照交易核心系統和交易支撐系統進行劃分。實際系統分級要根據公司特點進行，目的是對不一樣級別的系統實施不一樣的質量保障，核心系統要投入更多資源保障系統高可用，外圍系統要投入較少資源容許系統暫時不可用。

九、全鏈路分析，制定應急預案

對核心場景進行全鏈路分析，從用戶入口到後端存儲，梳理出各個關鍵路徑，對相關路徑進行評估並制定預案。即當出現問題時，該路徑能夠執行什麼操做來保證用戶可下單、可購物，而且也要防止問題的級聯效應和雪崩效應。梳理系統關鍵路徑，包括網絡接入層、應用接入層、Web應用層、服務層、數據層等，並制定應急預案。 P149展現了應急預案的格式。

第9章：應用級緩存

一、緩存回收策略

基於空間、基於容量、基於時間（TTL、TTI）、基於Java對象引用（軟引用、弱引用）、基於會是算法（FIFO、LRU（Leas Recently Used）、LFU（Lease Frequently Used））

二、Java緩存類型

• 堆緩存（最快，沒有序列化/反序列化，但GC暫停時間會變長）（Guava Cache、Ehcache 3.x、MapDB）
• 堆外緩存（比堆緩存慢，須要序列化/反序列化，能夠減小GC暫停時間）（Ehcache 3.x、MapDB）
• 磁盤緩存（Ehcache 3.x、MapDB）
• 分佈式緩存（Redis、Memcached）

三、緩存使用模式

• Cache-Aside，即業務代碼圍繞着Cache寫，是由業務代碼直接維護緩存。Cache-Aside適合使用AOP模式去實現。
• Cache-AS-SoR（system of record，或者能夠叫數據源），全部的操做都是對Cache進行，而後再委託給SoR進行真實的讀/寫。即業務代碼中只看到Cache的操做，看不到關於SoR相關的代碼。

四、Cache-AS-SoR共有三種實現方式

• Read-Through，業務代碼首先調用Cache，若是Cache不命中，由Cache回源到SoR，而不是業務代碼（即由Cache讀SoR）。Guava Cache和Ehcache 3.x都支持該模式。
• Write-Through，被稱爲穿透寫模式/直寫模式。業務代碼首先調用Cache寫（新增/修改）數據，而後由Cache負責寫緩存和寫SoR，而不是業務代碼。Ehcache 3.x支持。
• Write-Behind，也叫Write-Back，咱們稱之爲回寫模式。不一樣於Write-Through是同步寫SoR和Cache，Write-Behind是異步寫。異步以後能夠實現批量寫、合併寫、延時和限流。

第10章：HTTP緩存

一、HTTP緩存

• 服務端響應的Last-Modified會在下次請求時，將If-Modified-Since請求頭帶到服務器端進行文檔是否修改的驗證，若是沒有修改則返回304，瀏覽器能夠直接使用緩存內容
• Cache-Control:max-age和Expires用於決定瀏覽器端內容緩存多久，即多久過時，過時後則刪除緩存從新從服務器端獲取最新的。另外，能夠用於from cache場景。
• HTTP/1.1規範定義ETag爲「被請求變量的實體值」，可簡單理解爲文檔內容摘要，ETag可用來判斷頁面內容是否已經被修改了。

二、HttpClient客戶端緩存、Nginx配置、Nginx代理層緩存

第11章：多級緩存

多級緩存，是指在整個系統架構的不一樣系統層級進行數據緩存，以提高訪問效率，這是應用最廣的方案之一。

一、維度華緩存與增量緩存、大Value緩存處理、熱點緩存處理

二、緩存分佈式及應用負責均衡算法選擇

• 負載較低時，使用一致性哈希。
• 熱點請求降級一致性哈希爲輪詢，或者若是請求數據有規律，則可考慮帶權重的一致性哈希。
• 將熱點數據推送到接入層Nginx，直接響應給用戶。

三、熱點數據

熱點數據會形成服務器壓力過大，致使服務器性能、吞吐量、帶寬達到極限，出現響應慢或者拒絕服務的狀況，這確定是不容許的。

四、單機全量緩存+主從（熱點數據解決方案1）

通常不採用，針對緩存量比較大的應用不適用。

五、分佈式緩存+應用本地熱點（熱點數據解決方案2）

①接入Nginx將請求轉發給應用Nginx。（這種更適合應用層面的，對於服務內部的緩存，還能夠採用Guava cache等本地的堆內緩存、堆外緩存等。）

②應用Nginx首先讀取本地緩存。若是命中，則直接返回，不命中會讀取分佈式緩存、回源到Tomcat進行處理。

③應用Nginx會將請求上報給實時熱點發現系統，上報給實時熱點發現系統後，它將進行熱點統計。

④根據設置的閾值將熱點數據推送到應用Nginx本地緩存。

六、緩存數據一致性

• 訂閱數據變動消息
• 若是沒法訂閱消息或者訂閱消息成本比較高，而且對短暫的數據一致性要求不嚴格（好比，在商品詳情頁看到的庫存，能夠短暫的不一致，只要保證下單時一致便可），那麼能夠設置合理的過時時間，過時後再查詢新的數據。
• 若是是秒殺之類的（熱點數據），能夠訂閱活動開啓消息，將相關數據提早推送到前端應用，並將負載均衡機制降級爲輪詢。
• 創建實時熱點發現系統來對熱點進行統一推送和更新

七、緩存崩潰恢復

• 主從機制，作好冗餘，即其中一部分不可用，將對等的部分補上去。
• 若是由於緩存致使應用可用性已經降低，能夠考慮部分用戶降級，而後慢慢減小降級量，後臺經過Worker預熱緩存數據。

第12章：鏈接池線程池詳解

一、池化技術

在應用系統開發中，咱們常常會用到池化技術，如對象池、鏈接池、線程池等，經過池化來減小一些消耗，以提高性能。對象池經過複用對象從而減小建立對象、垃圾回收的開銷，可是池不能太大，太大會影響GC時的掃描時間。鏈接池如數據庫鏈接池、Redis鏈接池、HTTP鏈接池，經過複用TCP鏈接來減小建立和釋放鏈接的時間來提高性能。線程池也是相似的，經過複用線程提高性能。也就是說池化的目的是經過複用技術提高性能。

二、鏈接池使用的建議

• 注意網絡阻塞/不穩定時的級聯效應，鏈接池內部應該根據當前網絡的狀態（好比超時次數太多），對於必定時間內的（如100ms）所有timeout，根本不進行await（maxWait），即有熔斷和快速失敗機制。
• 當前等待鏈接池的數目超過必定量時，接下來的等待是沒有意義的，還會形成滾雪球效應
• 等待超時應儘量小點（除非很必要）。即便返回錯誤頁，也比等待並阻塞強。

三、線程池

更多的Java TreadExecutors相關的內容。相關配置項如：核心線程池大小、線程池最大大小、線程的最大空閒時間（超過則回收，直到線程數減爲核心線程大小）、線程池的任務緩衝隊列、建立線程的工廠、緩衝隊列滿後的拒絕策略等。另外還有支持延時任務的線程池。

四、線程池使用的建議

• 根據任務類型是IO密集型仍是CPU密集型、CPU核數，來設置合理的線程池大小、隊列大小、拒絕策略，並進行壓測和調優來決定適合場景的參數。
• 使用線程池時務必設置池大小、隊列大小並設置相應的拒絕策略。不如可能致使瞬間線程數太高、GC慢等問題，形成系統響應慢甚至OOM。

第13章：異步併發實戰

一、異步與併發

當一個線程在處理任務時，經過Fork多個線程來處理任務並等待這些線程的處理結果，這種並非真正的異步，這只是併發。異步是針對CPU和IO的，當IO沒有就緒時，要讓出CPU來處理其餘任務，這纔是異步。

二、異步Future

線程池配合Future實現，可是阻塞主請求流程，高併發時依然會形成線程數過多、CPU上下文切換。

三、異步Callback

經過回調機制實現，即首先發出網絡請求，當網絡返回時回調相關方法，採用線程池分發事件通知，從而有效支撐大量併發鏈接。這種機制並不能提高性能，而是爲了支撐大量併發鏈接或者提高吞吐量。

四、異步編排CompletableFuture

JDK 8 CompletableFuture提供了新的異步編程思路，能夠對多個異步處理進行編排，實現更復雜的異步處理，其內部使用了ForkJoinPool實現異步處理。好比三個服務異步併發調用、兩個服務併發調用、服務1執行完後再併發執行服務2服務3等場景。

五、異步Web服務實現

六、請求緩存

七、請求合併

第14章：如何擴容

一、跨庫事務

固然分佈式事務是一種方式，另外一種方式能夠考慮sharding-jdbc提供的柔性事務實現。目前支持最大努力送達，就是當事務失敗後經過最大努力反覆嘗試，是在假定數據庫操做必定能夠成功的前提下進行的，保證數據最終的一致性。其使用場景是冪等性操做，如根據主鍵刪除數據、帶主鍵插入數據。

二、柔性事務

sharding-jdbc的最大努力送達型柔性事務分爲同步送達和異步送達兩種，同步送達不須要Zookeeper和elastic-job，內置在柔性事務模塊中。異步送達比較複雜，是對柔性事務的最終補充，不能和應用程序部署在一塊兒，須要額外地經過elastic-job實現。最大努力送達型事務也可能出現錯誤，即不管如何補充都不能正確提交。爲了不反覆嘗試帶來的系統開銷，同步送達和異步送達都可配置最大重試次數，超過最大重試次數的事務將進入失敗列表。

三、數據異構

查詢維度異構、聚合據異構

四、分佈式任務

Quartz支持任務的集羣調度，若是一個實例失效，則能夠漂移到其餘實例進行處理，可是其不支持任務分片。tbschedule和elastic-job除了支持集羣調度特性，還不支持任務分片，從而能夠進行動態擴容/縮容

五、Elastic-Job

Elastic-Job是噹噹開源的一款分佈式任務調度框架，目前提供了兩個獨立子項目：Elastic-Job-Lite和Elastic-Job-Cloud。Elastic-Job-Lite定位爲輕量級無中心解決方案，能夠動態暫停/恢復任務實例，目前不支持動態擴容任務實例。Elastic-Job-Cloud使用Mesos+Docker解決方案，能夠根據任務負載來動態實現啓動/中止任務實例，以及任務治理。

六、Elastic-Job-Lite功能與架構

Elastic-Job-Lite實現了分佈式任務調度、動態擴容縮容、任務分片、失效轉移、運維平臺等功能。

Elastic-Job-Lite採用去中心化的調度方案，由Elastic-Job-Lite的客戶端定時自動觸發任務調度，經過任務分片的概念實現服務器負載的動態擴容/縮容，而且使用Zookeeper做爲分佈式任務調度的註冊和協調中心，當某任務實例崩潰後，自動失效轉移，實現高可用，並提供了運維控制檯，實現任務參數的動態修改。

第15章：隊列術

一、使用隊列注意點

咱們要考慮是否須要保證消息處理的有序性及如何保證，是否能重複消費及如何保證重複消費的冪等性。

二、隊列應用場景

異步處理、系統解耦、數據同步、流量削鋒、擴展性、緩衝等。

三、緩衝隊列

好比Log4j日誌緩衝區就是使用的緩衝隊列。使用緩衝隊列應對突發流量時，並不能使處理速度變快，而是使處理速度平滑，從而不因瞬間壓力太大而壓垮應用。經過緩衝區隊列能夠實現批量處理、異步處理和平滑流量。

四、任務隊列

使用任務隊列能夠將一些不須要與主線程同步執行的任務扔到任務隊列進行異步處理。能夠實現異步處理、任務分解/聚合處理。

五、消息隊列

經過消息隊列能夠實現異步處理、系統解耦和數據異構。

六、請求隊列

相似在Web環境下對用戶請求排隊，從而進行一些特殊控制：流量控制、請求分級、請求隔離。例如將請求按照功能劃分不一樣的隊列，從而使得不一樣的隊列出問題後相互不影響。還能夠對請求分級，一些重要的請求能夠優先處理（發展到必定程度應將功能物理分離）。

七、數據總線隊列

八、混合隊列

如MQ與Redis的協同組合使用。Disruptor+Redis隊列（P303）

九、下單系統水平可擴展架構

P311 緩衝表+緩存+同步worker+降級

十、基於Canal實現數據異構

背景：在大型網站架構中，通常會採用分庫分表來解決容量和性能問題。但分庫分表後，不一樣維度的查詢或者聚合查詢就會很是棘手，並且這種方式在大流量系統架構中確定是不行的。一種解決方式就是數據異構，能夠包含具體場景接口的異構、商家維度的異構、ES搜索異構、訂單緩存異構等。

第16章：構建需求響應式億級商品詳情頁

一、單品頁流量特色

單品頁流量的特色是離散數據、熱點少，可使用各類爬蟲、比價軟件抓取。

二、商品詳情頁架構設計原則

• 數據閉環
• 數據維度化
• 拆分系統
• Worker無狀態化+任務化
• 異步化+併發化
• 多級緩存化
• 動態化（數據動態化、模板渲染實時化、重啓應用秒級化、需求上線快速化）
• 彈性化（軟件打包成基礎鏡像，自動擴容）
• 降級開關
• 多機房多活

本章比較雜、淺，更多的是提供一種思路，須要複習仍是經過瀏覽目錄更好。

第17章：京東商品詳情頁服務閉環實踐

一、設計一個高度靈活的系統時，要想着當出現問題時怎麼辦

是否可降級？不可降級怎麼處理？是否會發送滾雪球問題？如何快速響應異常？服務如何更好更有效或者在異常下工做？

二、京東商品詳情頁總體流程

①請求首先進入Nginx，Nginx調用Lua進行一些前置邏輯處理，若是前置邏輯不合法，那麼直接返回，而後查詢本地緩存，若是命中，則直接返回數據。

②若是本地緩存未命中數據，則查詢分佈式Redis集羣：若是命中數據，則直接返回。

③若是分佈式Redis集羣未命中數據，則調用Tomcat進行回源處理。而後把結果異步寫入Redis集羣，並返回。

本章比較雜、淺，更多的是提供一種思路，須要複習仍是經過瀏覽目錄更好。

第18章：使用OpenRestry開發高性能Web應用

一、OpenResty簡介

OpenResty由Nginx、Lua、ngx_lua模塊構成。ngx_lua是章亦春編寫的Nginx的一個模塊，將Lua嵌入到Nginx中，從而可使用Lua來編寫腳本，部署到Nginx中運行，即Nginx變成了一個Web容器。這樣就可使用Lua來開發高性能的Web應用了。

二、OpenResty生態

OpenResty提供了一些經常使用的ngx_lua開發模塊，如lua-resty-memcached、lua-resty-mysql、lua-resty-redis、lua-resty-dns、lua-resty-dns、lua-resty-limit-traffic、lua-resty-template。這些模塊涉及如Mysql數據庫、Redis、限流、模塊渲染等經常使用功能組件。另外，也有不少第三方的ngx_lua組件供咱們使用。

三、京東使用OpenResty場景

• Web應用：會進行一些業務邏輯處理，設置進行CPU的模板渲染，通常流程包括mysql/Redis/HTTP獲取數據、業務處理、產生JSON/XML/模板渲染內容，好比，京東的列表頁/商品詳情頁。
• 接入網關：實現如數據校驗前置、緩存前置、數據過濾、API請求聚合、A/B測試、灰度發佈、降級、監控等功能，好比，京東的交易大Nginx節點、無線部門的無線網關、單品頁統一服務、實時價格、動態服務。
• Web防火牆：能夠進行IP/URL/UserAgent/Referer黑名單、限流等功能。
• 緩存服務器：能夠對響應內容進行緩存，減小到底後端的請求，從而提高性能。
• 其餘：如靜態資源服務器、消息推送服務、縮略圖裁剪等。

四、基於OpenResty的經常使用架構模式

• 負載均衡
• 單機閉環
• 分佈式閉環
• 接入網關

五、常見的一些問題

• 在開放Nginx應用時，使用UTF-8編碼能夠減小不少麻煩。
• GBK轉碼解碼時，應使用GB18030，不然一些特殊字符會出現亂碼。
• cjson庫對於像\uab1這種錯誤的Unicode轉碼會失敗，可使用純Lua編寫的dkjson。
• 社區版Nginx不支持upstream的域名動態解析，能夠考慮proxy_pass，而後配合resolver來實現。或者在Lua中進行HTTP調用。若是DNS遇到性能瓶頸，則能夠考慮再本機部署如dnsmasq來緩存，或者考慮使用balancer_by_lua功能實現動態upstream。
• 爲響應添加處理服務器IP的響應頭，方便定位問題
• 根據業務設置合理的超時時間。
• 運行CDN的業務，當發生錯誤時，不要給返回的500/503/302/301等非正常響應設置緩存。

第19章：應用數據靜態化架構高性能單頁Web應用

一、傳統靜態化及頁面構建須要考慮的問題

• 頁面模板部分變動類須要從新所有生成
• 動態化模板渲染支持
• 數據和模板的多版本化：生成版本、灰度版和預發佈版本
• 版本回滾問題，假設當前發佈的生成版本出問題了，如何快速回滾到上一個版本。
• 異常問題，假設渲染模板時，遇到了異常狀況（好比Redis出問題了），該如何處理
• 灰度發佈問題，好比切20%量給灰度版本。
• 預發佈問題，目的是在正式環境測試數據和模板的正確

二、常見異常問題

• 本機從「發佈數據存儲Redis」和主「發佈數據存儲Redis」都不能用了，那麼能夠直接調用CMS系統暴露的HTTP服務，直接從元數據存儲Mysql獲取數據。
• 數據和模板獲取到了，可是渲染模板出錯了，好比遇到500、503。解決方案是使用上一個版本的數據進行渲染。
• 數據和模板都沒問題，可是由於一些疏忽，渲染出來的頁面錯亂了，或者有些區域出現了空白。對於這種問題沒有很好的解決方案。能夠根據本身的場景定義異常掃描庫，掃到當前版本有異常就發警告給相關人員，並自動降級到上一個版本。

第20、21章內容均爲OpenResty的實踐運用，這裏簡單過下就行，真實使用時再細研