本文作者從事運營商計費係統工作18年，曆經計（jì）費2.8和BSS3.0,參與過計（jì）費2.8、BSS3.0等集團規範編製和（hé）入網測（cè）試，參（cān）與了多個運（yùn）營商省級計費係統建設。
隨著運營商5G商用規（guī）模的不斷擴（kuò）大，5G用戶比例不斷提高，計費（fèi）係（xì）統話單數成幾何倍數（shù）快速增長。如果計費話單處理性（xìng）能不能同步提升，涉及大量（liàng）話單處理的業務場景都會出現嚴重問題。
計費應用無法及時處理高峰期的（de）話單，導致話單大（dà）量積壓，影響流量提醒及時性，引發大麵積用戶投訴。
當計費係統發（fā）生重大故障，係（xì）統恢複時間較長時，將（jiāng）會積壓大量話單。此時就需要強大的（de）計費話單處理能力（lì）來進（jìn）行追單處理，否則如果（guǒ）臨近（jìn）月底話單還沒跑完，將會影響出（chū）帳，後果不堪設想。
計費係統對（duì）帳時，如果想對全省一個月的（de）話單進行新老（lǎo）係統對帳，那麽對帳人員需要耗費大量的時間在等（děng）待跑帳。按月話單數300億估算，如果話單處理能（néng）力隻有6w tps，那麽需要耗費將近6天時間才能跑完，不具備重新跑帳的（de）時間。
導致性能問題的業務原因很明確，所產生問題的業務後果也明確，解決問題的緊迫性很強烈，本文就筆（bǐ）者近（jìn）期在某項目實際優化工作中的探索總結進行分享（xiǎng）。
性能調優，實際上就是不斷地（dì）針對遇到的性（xìng）能問（wèn）題，尋找解決方案並獲得突破（pò），最終達成（chéng）理想的優化效果。計（jì）費話單處理能力的性能問題到底在哪裏呢（ne）？
我（wǒ）們在反複壓測和調優過程中，將遇到的性（xìng）能問題分為三類：部署架構問題、業務流程問題和應（yīng）用邏輯問題。
眾所周知，新一代的計費係統一般都采用（yòng）“平台+應用”的全新IT架構，在部署上應（yīng）用和數據一般是分離的（de），優化前普遍采用的部署架（jià）構如下：
應用環節間采（cǎi）用消息中間件（jiàn）進行話單流轉，采預應用按用（yòng）戶取模把話單分發給（gěi）批價應用，批價應用按用戶關聯分組取模分發（fā）給實時優惠應用，實時優惠應用按用（yòng）戶取模分（fèn）發給（gěi）提醒應用。
采預應用、批價應用、提醒（xǐng）應用跨主機遠程訪問分布式MDB集群（qún）的客戶資料。實時優惠應（yīng）用（yòng）每個應用容器部署一套MDB本地高（gāo）速緩存，用於預加載客戶資料，實時優惠應用訪問應用容器內（nèi）的本地高速緩存中的客戶（hù）資料。
這樣的部署架構粗看沒有問（wèn）題，但是仔細分（fèn）析後，存在三個致命的問題：客戶資（zī）料訪問問題、累積量扣減（jiǎn）鎖衝突問題和MQ流量壓力問題。
1）對於采預應（yīng）用、批價應用和提醒應（yīng）用，由於都是跨主機遠程訪問分布（bù）式MDB集群的客戶資料，網（wǎng）絡交互（hù）耗時占（zhàn）比特別高。以批價應用為例（lì），處理（lǐ）一條話單總耗時大概是10毫秒（miǎo），其中查找客戶資（zī）料耗時占了7毫秒（需（xū）要查找多張表，且一張表需要查找多次），查（chá）找客戶資料的網絡交互耗時占了（le）5毫秒（miǎo）。
2）對於實時優惠應用，雖然預加載客戶資料到（dào）本地高速緩存，但是由於每個應用容器（qì）都需要加載一份客戶（hù）資（zī）料，內存占用巨大，導致隻（zhī）能加載有限的客戶資料。
1）對於套餐共享累積量，一個套餐有多個用戶（hù），不同用戶的話單如果在（zài）批價環節多進程並發處理，會導致不同進程同時扣減同一條累積量，導致批價扣減累積（jī）量的mdb鎖衝突，嚴重影響批價的並發處理性能。
2）由於采預應用給批價應用是按（àn）用（yòng）戶取模分發的，所以對於共享套餐（cān）用戶話單，在批價環節並發（fā）處理的概率還（hái）是（shì）比較高的，特別是話單積（jī）壓場景下，這種並發衝突尤其嚴重。
1）計費流程環節間采用消息中間件MQ進（jìn）行話單流轉，每個環節需要輸出話單到MQ，同時需要輸出（chū）上傳集團的信息點記錄（lù）到MQ，這兩塊對MQ的壓力都是巨大的。
2）根據某省（shěng）準生產環（huán）境實（shí）際（jì）壓（yā）力測試數據，各應用主機（jī）占用網（wǎng）絡帶寬分別如下：采預應（yīng）用主機為12Gb/s，批價應用主機為18Gb/s，實時（shí）優惠應用主機為17Gb/s，提醒（xǐng）應用主機（jī）為3Gb/s，各應用主（zhǔ）機爭搶網（wǎng）絡帶寬資（zī）源，導致所有應用並發時（shí），總體性能上不（bú）去。
新一代的計費業務（wù）流（liú）程基本上繼承了計費專業的傳統業（yè）務流程，主要如下：
1、當前的提醒流（liú）程，提醒應用通（tōng）過合帳應（yīng）用觸發，並在（zài）提醒（xǐng）應用（yòng）內部（bù）再更新一份累積量數據。
2、這種方式可以提高提醒應用的獨（dú）立性，但是（shì）同時帶來了一些比較明顯的缺（quē）陷（xiàn），主要如下（xià）：
由於提醒應用單獨維護的一份累積量數據，這份數（shù）據（jù）和批價應（yīng）用產（chǎn）生的累積量數據由（yóu）於時間差的原因，可能不完全（quán）一致。同時提醒應用單獨維護一份累積量數據，對提（tí）醒應用的存儲（chǔ）資源和應用性能也造成了一定的負麵影響。
由於帳戶（hù）優惠並（bìng）入合帳中進行實時優惠處理，導致對於大帳戶優惠用（yòng）戶，流量提醒端到端總時長大大加長，無法達（dá）到集（jí）團1分鍾提醒的要（yào）求。
由於批價（jià）環（huán）節引入了產品累積量的應（yīng）用邏輯，導致合帳應（yīng）用通知提醒應用的消息量暴增，是正常話單量的3倍，提醒應用的性能處理壓力是批價的3倍。
合帳應用處理限（xiàn）額哈希時，代碼邏輯存在如下問題：申請5000條固定大小的哈（hā）希，按哈希大小循環遍（biàn）曆哈希（xī），反複對無（wú）效數據（jù）進行內存清理，導致合帳CPU消（xiāo）耗特別（bié）高，占用大量CPU資源（yuán），同時跟批價競爭CPU資源（yuán），嚴重（chóng）影響批價性能（néng）。
想要提升（shēng）計費話單處理能力，則必須針對性的解決以上的部署架構問題、業務流程問題和應用邏輯問題。至此（cǐ），性能問題的原因也逐漸清晰。
想要解（jiě）決部署架構問題，重點是解決客戶資料訪問問（wèn）題、累積量扣減（jiǎn）鎖衝突問題、MQ流量壓（yā）力問題。
通過（guò）Daemonset容器高速緩存，解決（jué）客戶資料訪問問題
計費應（yīng）用在業務處理過程中，經常需要訪（fǎng）問客戶資料，如產（chǎn）品實例、銷售品實例等。這（zhè）些客戶資料數據量非常大，放在MDB中供業務應用（yòng）查詢。
MDB作為（wéi）獨立（lì）的服務集群，和業務應用集群（qún）部署在不同的主機上，跨主機的網絡時延對資料的高頻訪問性能影響較大。但是，如果每個應（yīng）用容器都部署一套（tào）MDB本（běn）地高速緩存，內存占用巨大，導致隻能（néng）加載有限（xiàn）的客戶資料。
如果我們在每個業務應用主（zhǔ）機單獨部署一個Daemonset容器，用於部署（shǔ）MDB高速緩存，業務應（yīng）用支持（chí）跨（kuà）容器訪問同主機共享內存中的客戶資料，這樣既可以避免跨主機訪問客戶資料的網絡耗時大的問題，又可以解決每個容器都部署一套高速緩存的內存占用大的問題。
通過Daemonset容器高（gāo）速緩存，我們可以保存訪問比較頻（pín）繁的幾張表的全省客戶資料數據，業務應用（yòng）跨容器通過（guò）IPC訪問MDB本地高速緩存，從（cóng）而提高客戶資料查詢效率，降低網絡時延，如下圖所示：
通過分布式用戶分組技術，解決（jué）累積量扣減鎖衝突問題
前麵我們提到了（le），應用（yòng）多進程並發處理存在數據庫鎖衝突（tū），總體性能上不去。以（yǐ）批價為例，目前按用戶維度進行分發，對於套餐共享累積量，不同的批價進程存（cún）在並發扣（kòu）減同一條累積量，此時會（huì）導致（zhì）數據庫鎖衝突，影響批價的總體處理性能。
運營商業務（wù）中的用戶不是一個完全獨立的（de）個體，而是存在複雜的（de）業務（wù）關聯性，比如通過（guò）套餐關聯、帳戶關聯、客戶關聯，這幾種關係甚至可以多層嵌套關聯。如果業務（wù）應用的並（bìng）發（fā）沒有基於用戶的業務關聯關係，很容易導致數據庫鎖衝（chōng）突。
分布式用戶分（fèn）組技術，可以基於業務規則的（de）動態分析，通（tōng）過關聯分組算法（fǎ）對用戶進（jìn）行關聯關係管理。業務應用可（kě）以基於用戶關聯關係實（shí）現並行處理，且不會引發（fā）並發數據庫鎖衝突問題。同時，由於關聯用戶在一個進程處理，如果關聯用戶的當前環節處（chù）理完成後，可以直接進入下一個環節，不用等待其它非關聯用戶處理完成（chéng），整個計費流程可以實現橫向擴展。
通過分布式用戶分組技術將客戶資料進行拆（chāi）解細分之後，批價、實時優惠、提醒等應（yīng）用按分布式（shì）用戶（hù）分組進行話單分（fèn）發，如下圖所示：
批價、實時優惠（huì）、提醒等業務應用按用戶關聯分組進行話單事件分發，不同的（de）進程實例（lì）處理不同的關聯分組用戶話單，同一個關聯分（fèn）組用（yòng）戶話單隻會分發給一個應用進程實例處理，所以不（bú）同應用進程實例之間處理的話單就不再有關聯關係，也就不會再有數據庫操作的鎖衝突，並（bìng）發處理性能可以得到極（jí）大的提升。
MQ壓縮技術，即對環節間交互的話單事件批量打包後，采用zlib庫（kù）壓（yā）縮數據後寫入MQ，可（kě）壓（yā）縮到原始數據的1/10~1/20，詳細如下圖：
這裏MQ壓縮的效果主要取決於批量話單打包的效果，如果（guǒ）隻有少量的話單事件打包成一個消（xiāo）息包，則MQ的（de）壓縮效果就會比（bǐ）較差；反之，如果較多的話單事件打包成一個消息（xī）包，則MQ的壓縮效果就會比較好。
計費操作MQ的網（wǎng）絡（luò）流量主要（yào）來自兩個（gè）方麵，一方（fāng）麵是計費流（liú）程的環節間交互（hù）話單通過MQ進行流轉，另一方麵是計費流程需要吐出話單級信息點上傳（chuán）集團。
（一）首先，我們來看（kàn）計（jì）費流程的環節間交互話單。實際上計費流程每個環節（jiē）都（dōu）是（shì）批量話單處理的，如果能保證從MQ中的一個消息隊列獲取一（yī）批話單事件，業務處理完成後分發給下遊環節時，還（hái）是分發到同一個消息隊列，則此時這批話單事件將會打包成同一個消息包，那麽這個消息（xī）包包含的話單事件將會最多，MQ壓縮（suō）的效（xiào）果將會達到最（zuì）佳；反之，如果從一個消息隊列獲取的一批話單事件，被打散分發到下遊環節的多個消息（xī）隊列，則這批話單事件將會打包成多個消（xiāo）息包，那麽每個消息包包含的話單事件將會比較少，MQ的（de）壓縮效果也（yě）會比較（jiào）差。
所以我們想（xiǎng）要獲得最佳（jiā）的MQ壓縮效果，需（xū）要盡可能保證上（shàng）下遊環節（jiē）的分發（fā）規則保持一致，則可確保從消息隊列獲取的一批話單事件，給下遊（yóu）環節分發時（shí），不（bú）會被（bèi）打散分發到多個（gè）消息隊列。
（二）其次，我們來看計（jì）費流程需要吐（tǔ）出的話單級信息點給MQ帶來的網絡流（liú）量壓力。這裏的話單級信息點是所有（yǒu）環節都需要輸出的，而每個信息點本身的記錄長（zhǎng）度比較小，但是信息點記錄數和話單數本身是一樣多（duō）的，所以如果壓縮效果不好的（de）話，產生的網絡流（liú）量將是很可怕的。
這裏（lǐ）的話單級信息點是（shì）為（wéi）了生成文件上傳集團的，是由計費流程各業務應用模塊分發給信息點（diǎn）文件生成模塊的，對於分發（fā）規則本（běn）身沒有特別要求，原來是按話單標識分發的。按（àn）話單標識分發均衡性沒有問題，但是會導致從（cóng）計費流（liú）程（chéng）各應用模塊的一個消（xiāo）息隊列獲取（qǔ）的一批話單事件，會被打散分發到信息點文件生成模塊的所有（yǒu）消息隊列，就會導（dǎo）致一個消息包包（bāo）含的話單事件很少，MQ的壓（yā）縮（suō）效果大打折扣。
為（wéi）了提高MQ壓縮效果，我們調（diào）整了計費流程各業（yè）務應用模塊給信息點（diǎn）文件生（shēng）成模塊的分發規（guī）則，改為按業（yè）務應用的應用實例標識分發，這樣子從計費（fèi）流程各應用模塊的一個消息隊（duì）列獲取的一批話單事件，就會分發（fā）到信息點文（wén）件生成（chéng）模塊的（de）一個消（xiāo）息（xī）隊列（liè）中，從而保證這一批話單事件生成的信息點（diǎn）記錄打包成一個消息包，提升MQ的壓縮效果，極大的降低了MQ網絡流量壓力。
首先，我們回顧下前麵提到的業務流程問題：
1）由於提醒應用單獨維（wéi）護的一份累（lèi）積量數據，這份數據（jù）和（hé）批價產生的累積量數據（jù）由於時間差的原因，可能不完全一致。同時提醒應用（yòng）單獨維護一份（fèn）累（lèi）積量數據，對提醒應（yīng）用的存儲資源和（hé）應用性能也造成了一（yī）定的負麵影響。
2） 由於帳戶優（yōu）惠並入合帳中進行實時優惠處理（lǐ），導致對於大帳戶優惠用戶，流量提醒端到端總時長大大加長，無法（fǎ）達（dá）到集團1分鍾提醒的要求（qiú）。
為了解決（jué）以上兩個問題，我們需要打通批價應用到提（tí）醒應用的流程，減少消息中轉流程，避免（miǎn）額外的累積量數據（jù）冗餘，保證計費係統內部各模塊使（shǐ）用的累積量數據的（de）一致（zhì）性，從而提高整個提醒流程的處理效（xiào）率，降低硬件資源（yuán）的消耗。
詳細方（fāng）案如下圖：
原來由合（hé）帳應用通知提醒應用（yòng），調整為（wéi）由（yóu）批價應用直接（jiē）通知提醒應用，減少流量提醒途經環節數，提高提醒及時性。
原來提醒應用需要自己再更新一份累積量數據，現在直接使用批價的累積量數據進行提醒判斷，減少資源消耗，提升提醒應用處理性能。
應用邏輯問題主要如下：
由於批價環節引入了（le）產品累積量的應用邏輯，導致合帳應用通知提醒應（yīng）用的消息量暴增，是正常話單量的3倍，提醒應用的性能處理壓力是批價的3倍。
合（hé）帳處理限額哈希時，代碼邏輯按固定哈希大小刪除無效數據的問題，導致合帳CPU消耗特別高，占用大量CPU資源，同時跟批價競爭CPU資源，嚴重（chóng）影響批價性能（néng）。
首先，針對提醒應用消息暴增問（wèn）題，我們通（tōng）過對通知提醒應用的話（huà）單事件按銷售品實例（lì）、累積量類型和用戶的維度進行（háng）合並，來降（jiàng）低提（tí）醒應用的實際處理話（huà）單量，從而解決（jué）提醒應用消息量暴增帶來的（de）性能（néng）壓力；
其次，針對合帳CPU高問題，我們通過刪除一些不（bú）必要的處（chù）理邏輯來（lái）降低合帳的CPU消耗，即增加（jiā）判斷邏輯，如果（guǒ）是無效數據，則（zé）不需要執行刪除操作。
除了以上兩點業務邏輯優化外，我們還（hái）針對每個業務模塊進行了分析，做了很多零散的改造優化，應用邏（luó）輯優化可以歸納為以下幾個策略：
應用緩存：通過緩存資（zī）料、量本等（děng）數據，減少應用遠程訪問（wèn）MDB和數據庫次數。
邏輯優化：通過廢棄冗（rǒng）餘邏輯，優化（huà）SQL語法、減少零費用話單處理等邏輯優化提升性能。
話單歸（guī）並：通過對批（pī）次內同樣銷售品實例、用（yòng）戶和累積（jī）量類型的話單事件進行合並處理，減少（shǎo）提醒（xǐng）應用觸發（fā）量。
經過前麵幾個性能問（wèn）題的（de）解決（jué），計費（fèi）話單處理能力得到了一個質的飛躍，不僅（jǐn）突破了原來的性（xìng）能天花板（bǎn），而且達到（dào）了20萬條話單/秒（miǎo）的高性能，這個性能遠超集團對於中等省份12萬條（tiáo）話單/秒的要求。
以下是在某省準生產環境實際壓（yā）測的性能數（shù）據：
從以上數據可以看出（chū），除了清單入庫外（wài），其他業（yè）務（wù）應用模塊均已（yǐ）經達到甚至超過了20萬條話單/秒的性能，清單入庫主要由（yóu）於數據庫本身對於自增係列的處理（lǐ）性能達不到20萬條（tiáo）話單（dān）/秒的要求。
隨後，在其（qí）他項目的優化過程中，我們進一步對清單入庫（kù）進行了優化，把自增序列改造為業務應用自（zì）己獲取，不（bú）依賴於數據庫的自增序列，清單入（rù）庫性能從原來單（dān）進程500條話單/秒，提升至2000條話單/秒，性能提升4倍，總體性能遠超（chāo）20萬條話單/秒。
性能問題持續（xù）永恒，性能優化永無止境。