前言
上周四（10月14日）晚，受邀參加了由數列科技主辦的線上技術直播——PGUG系列-大促保障之旅，其中我分享的Topic是《大型業務活動，如何保障系統的穩定性》。
分享過程中，參與直播的同學們提了很多問題，礙於很多問題無法一兩句概括，因此寫了這篇文章，對這些同學提出的問題做一個解答。當然，回答僅限於我個人的角度，僅供參考。
- PGUG系列：大促保障之旅專欄
- PPT下載：大型業務活動，如何保障系統的穩定性？
- 課程回放：大型業務活動，如何保障系統的穩定性？
Question
| 編號 |
提問用戶微信名 |
提問的問題 |
| 1 |
Armo |
流量模型具體指得是什么？ |
| 2 |
怎么根據入口流量和內部流量的成份比例關系進行計算？ |
|
| 3 |
流量的預估上是怎么做的呢？ |
|
| 4 |
容量水位是怎么定義的？當前QPS/按照壓測的QPS？ |
|
| 5 |
王雷 |
K8S是不是自動擴容？ |
| 6 |
空 |
在壓測時，請求參數一般都是重復的嗎？ |
| 7 |
在壓測過程的時候，怎么確定多少連接數比較合適？比如，Redis連接數，數據庫連接數，線程數，Tomcat連接數？ |
|
| 8 |
Macan |
容量水位如何評估是否擴展講細一點？還有自動擴縮容調度決策如何制定？ |
| 9 |
多的 |
應用服務可以通過這些方式達到高性能高可用，但是相對應的，數據庫DB也會有大量的數據讀寫操作，這也可能導致DB掛掉，請問這種情況怎么辦？ |
Answer
PS：很多問題歸類下來都很類似，我歸納匯總下來，主要有如下幾點：
流量模型
關於流量模型，大家先看下面這幅圖：
1、流量模型具體指得是什么？
分布式服務架構下，服務間調用關系是及其復雜的。如上圖所示，一個用戶請求，要經過層層調用，才能到達數據庫。
且調用過程中，對Redis、MQ或其他下游服務的調用可能要多次。這就導致了一種現象：用戶請求一次，對下游的其他服務或者中間件可能請求了多次，這樣就形成了一個漏斗狀的模型。
到這里，流量模型是什么的答案，其實已經出來了。非要做一個定義的話，我認為應該這樣定義：
流量模型：系統處理用戶請求過程中，請求對系統內部服務及中間件的調用形成的關系集合；
如何理解：所謂的流量模型這種關系集合，一般來說都是都是漏斗形狀，即上窄下寬；
2、流量的預估上是怎么做的呢？
流量預估，一般的步驟如下：
- 確定業務目標（技術最終要為業務目標達成負責）；
- 轉化為核心鏈路技術指標（電商行業核心鏈路一般為訂單量）；
- 依賴流量模型，由核心鏈路進行轉化計算（一般都是選取峰值的請求流量）；
3、怎么根據入口流量和內部流量的比例關系進行計算？
以第二個問題的預估步驟為例，參考如下計算方式：
-
業務目標：今年雙十一，業務目標是DAU1000W，支付單量100W；
-
假設創建訂單接口和發起支付接口比例為3:1，那么支付接口QPS=100W；
-
假設往年大促80%的支付請求分布在雙十一0點前一個小時，前一個小時請求中，前十分鍾占比60%；
-
由上可得：支付接口QPS=100W*80%*60%=48W，創建訂單接口QPS=3*100W*80%*60%=144W；
-
平均到秒級別，支付接口QPS=800，創建訂單接口QPS=2400；
-
以核心鏈路的QPS為基准，按照流量模型調用關系進行放大或者縮小計算，即可得出每個應用大促峰值需要承接的QPS；
PS：QPS如何得到？依賴監控系統！
容量評估
4、K8S是不是自動擴容？
k8s是為容器服務而生的一個可移植容器的編排管理工具，從架構設計層面我們關注的可用性、伸縮性都可以結合k8s得到很好的解決。
從服務部署運維、服務監控、應用擴容和故障處理，k8s都提供了很好的解決方案。具體來說，主要包括以下幾點：
- 服務發現與調度；
- 負載均衡；
- 服務自愈；
- 服務彈性擴容；
- 橫向擴容；
- 存儲卷掛載；
PS：綜上所述，服務彈性擴容只是K8S的功能之一，且彈性擴縮容，除了K8S還有其他的實現方式和工具。
5、容量水位是怎么定義的？當前QPS/按照壓測的QPS？
如何理解容量？舉個例子：一台4C8G的虛擬機，在CPU使用率達到最大值時，它的處理能力(TPS)是500。
但線上正常的服務負載，一般不會讓超過40%，這也是所謂的安全水位。在安全水位下，可能這台虛擬機的處理能力只有200。這就是所謂的容量水位，安全水位。
容量水位定義：系統處於X並發情況下，保證安全水位時候的處理能力。
參照上述第三個問題的回答：如果某個核心接口的預估峰值QPS=2400，那這個接口所在的服務集群，最少的機器數量應該為12+（需要留一定的buffer，保證冗余空間）。
PS：需要注意的是：一個服務對應多個接口，需要保證被測接口的請求在該服務占據絕大部分。
6、容量水位如何評估是否擴展講細一點？還有自動擴縮容調度決策如何制定？
容量水位評估，參照上述第五個問題。
自動擴縮容調度決策，實現的邏輯無非就是單機設定一個閾值，超過該閾值自動擴容服務。需要注意的是，負載均衡有時候不是完美的，還需要一個集群的閾值，配合服務健康檢查。
PS：擴容一般都需要有熱備的機器，容器相對擴容速度更快一些，如果是ECS等虛擬機，需要考慮機器熱備。
壓測配置
7、在壓測時，請求參數一般都是重復的嗎？
壓測請求用到的數據，一般有3種：
- 基礎數據：數據庫表中用於鋪底的基礎數據，比如商品信息，庫存數之類的；
- 冪等數據：常見的只讀接口，如果不涉及邏輯校驗，可以用重復的數據；
- 熱點數據：即參數化數據，比如用戶的userid，手機號等，部分業務邏輯涉及到唯一性校驗；
參數配置
8、在壓測過程中，怎么確定多少連接數比較合適？比如，Redis連接數、數據庫連接數、線程數、Tomcat連接數？
一般常用的中間件，應用容器和DB，都會有默認的參數配置和官方推薦的配置。但考慮到不同的業務場景和技術實現方式，都是采用配置測試的方式來調整驗證配置。
比如Tomcat的線程數，之前我做過類似的驗證：1台16C32G的機器，性能和負載最均衡的線程配置數是256。
官方推薦的好像也是16N（這里的N指的是服務器的物理核數）。當然，配置為512，性能更好一些，但機器負載相對會更高一些。
PS：以Tomcat為例，線程配置也分為最小連接數和最大連接數，活躍線程數和最大等待線程數以及timeout。這幾個配置參數之間，也是有關系的，建議看看官方文檔了解下不同參數配置的含義。
DB高可用
9、應用服務可以升配擴容達到高性能，但是對應DB也會有大量讀寫操作，這可能導致DB掛掉，這種情況怎么辦？
目前來說，數據庫的性能瓶頸只能通過升配、分庫分表、拆分實例來提升。當然，優化慢SQL、事務合並、技術改造直連DB為讀寫緩存，也是一種方式，但根本上還是治標不治本。
結語
上述問題的有些回答，我的回復只能作為參考，因為每個人面臨的技術和業務挑戰都不一樣，還是需要靈活評估解決的。
很多問題或者遇到的疑惑，需要大家自己去探索。成長是一個閉環，需要學習-實踐-試錯-復盤-不斷優化。上述的答疑中留了一些問題，相關同學如果感興趣，可以嘗試思考如何解決它們。