一文瞭解電商大促系統的高可用保障思路

来源:https://www.cnblogs.com/jingdongkeji/archive/2023/07/21/17571277.html
-Advertisement-
Play Games

本文面向受眾可以是運營、可以是產品、也可以是研發、測試人員,作者希望通過如下思路(知歷史->清家底->明目標->定戰略->做戰術->促成長)幫助大家能夠瞭解電商大促系統的高可用保障,減少哪些高深莫測的黑話和高大尚的論調,而是希望有個體系化的知識讓讀者有所得。 ...


本文面向受眾可以是運營、可以是產品、也可以是研發、測試人員,作者希望通過如下思路(知歷史->清家底->明目標->定戰略->做戰術->促成長)幫助大家能夠瞭解電商大促系統的高可用保障,減少哪些高深莫測的黑話和高大尚的論調,而是希望有個體系化的知識讓讀者有所得。

一、【知歷史】電商大促的簡介

1.1、什麼是電商大促

電商大促是電商平臺組織的一種大型銷售推廣活動,目的是通過提供各種優惠、折扣等方法,提高商品銷售額和網站流量,增加消費者的購物欲望,以實現銷售目標。電商大促活動通常會在一些特定的節點或者節日舉行,比如“11.11”、“618”、“黑色星期五”等,這些時期的電商大促極具吸引力,既有大量的商品打折優惠,又有豐富多樣的活動供消費者參與,是電商平臺提升銷售業績的重要手段。 電商大促活動期間,大家可以購買到平時心儀已久的商品,並且價格通常會遠低於平時,而電商平臺也會通過活動吸引更多的消費者流量和購買力,進一步提升其在電商行業的影響力。電商大促不僅僅是一種營銷方式,也是電商平臺和消費者互動、提高用戶粘性的有效方式。

1.2、典型的電商大促活動簡介

618大促: 每年6月是京東的店慶月,也是京東的電商促銷主戰場,在店慶月京東都會推出一系列的大型促銷活動,從6月1日延續至6月18日(近幾年開始從5.20日左右開啟預售模式,但是整體時間依然是以6月1日開門紅為準)。從2010年開始,以滿減、優惠券等活動的方式,通過單品類、跨店鋪等方式逐步蔓延到23年的百億補貼,歷時已經13年之久為整個京東零售平臺的GMV營收帶來不小的貢獻。

11.11: 11.11是指各網路購物平臺在每年11月11日的大型促銷活動,最早起源於中國阿裡巴巴旗下購物網站在2009年11月11日舉辦的“淘寶商城促銷日”,現已演變成全行業一年一度的購物活動,及影響全球零售業的消費現象。2012年11月11日網路購物全日銷售額超過美國網路星期一,成為全球最大的互聯網的購物節日。(備註:淘寶商城項目剛獨立,後更名為天貓,該營銷活動主打品牌商的商品,是想要模仿美國感恩節大促銷這種活動,通過一個活動或一個事件,讓消費者記住淘寶商城)。(參考維基百科)

黑色星期五: Black Friday最早於2005年美國網路shop.org創造的購物節日,與11.11被電商炒成購物節原因相似。與之相對應的還有興起於法國、葡萄牙與德國的Cyber Monday。關於黑色星期五這一叫法的起源,較普遍的一種認為看法是,由於這一天是感恩節(11月第四個星期四)後開業的第一天。再加上人們通常由此開始聖誕節大採購,很多商店都會顧客盈門從而有大額進帳。傳統上商家會用不同顏色的墨水來記賬:紅色表示虧損即赤字;反之黑色則為有盈利。商家把這個星期五叫做黑色星期五,用以期待這一天過後,年度營收由負轉正,由紅字轉為黑字。而商店的員工則使用黑色星期五這一名字來自嘲,表示這一天會非常忙碌。黑色星期五這一天一般都會是一個大的採購狂潮,銷售額是一年中第二或第三高的一天,而通常一年中銷售額最高潮是聖誕節前夜或之前的一個星期六。(參考維基百科)

除上述比較大型的電商促銷活動外,其他零售電商平臺比如蘇寧818、國美418,以及其他電商平臺也在自己造節日,而近幾年的拼多多、抖音、快手等電商平臺更多的是借勢11.11或者618來提升整個電商平臺的GMV交易額。

二、【清家底】電商平臺的商業模式與系統

2.1、電商平臺的商業模式

經過上面電商大促簡介,大家心裡已經有一個簡單的電商大促活動認識,對於電商行業從業者,電商大促活動是基本的知識,近幾年隨著“新零售”、“無界零售”、“全渠道”等新詞的頻出,給原本電商大促活動增加了更多的業務複雜性。這也是為什麼會在這裡提下系統分類的原因。在整個零售業鏈路的節點上,劉總曾經提到過“十節甘蔗”理論,而我們致力於做的事是後5節甘蔗的內容,大家知道京東是以自建倉儲物流打通供應鏈為核心驅動力,而淘寶天貓平臺更多是聚集在平臺交易環節通過營銷和兼併購買生態產品帶動流量增長為核心驅動力(近幾年阿裡也開始佈局菜鳥平臺開始衍生至其他節甘蔗);拼多多商業模式更側重於不同的營銷模式,所以系統也聚焦在營銷、交易側,採用第三方商家和物流配送體系;抖音、快手直播電商本身是在構建一個流量場,從開始京東、淘寶天貓入駐流量場到現在獨立發展電商,他們更多是希望搭建的平臺場來實現交易額;

通過上面的講述其實是想要說一件事,如果單純字面上說電商大促備戰是沒有意義的,針對不同環節的"甘蔗",整個電商大促中重要性不同,所以電商大促備戰中,需要明確自己的系統在整個業務鏈路中的位置,同時系統提供的核心功能,是否涉及資損、用戶體驗、阻礙交易行為或者影響公司名譽、品牌、集團戰略、營銷計劃等內容。

2.2、電商平臺下的系統鏈路劃分

基於上述內容,我們可以基於營銷、交易、倉儲、配送、售後來劃分京東零售整個系統的業務鏈路環節初步劃分,從大促活動來看營銷是吸引流量、聚集流量、進行流量轉化的手段,屬於整個大促活動的核心環節;從我們的電商平臺大促目的來說,大促活動更多的是希望帶來交易訂單的達成,促進交易額的提升,所以整個交易鏈路是真正目標核心鏈路,屬於整個大促活動的最重要環節;從倉儲、配送、售後來看更多的是交易後履約服務保障,這裡面更多的是給電商平臺帶來的口碑影響,和用戶的長期體驗,對於電商平臺長期發展來看也是非常重要,但是在電商大促的特定場景下可能相對前置的交易屬於次重要核心環節。因為涉及業務知識比較龐大,以下我簡要說明下鏈路作為大家一個參考(如有不對,可聯繫ERP:liuxiaocheng6反饋)

營銷鏈路:營銷策略方案制定->營銷方案採銷/商家宣講->營銷方案外部市場公關->營銷活動創建->營銷活動審核->營銷活動投放->促銷招商->商家報名->商家選品、發品->營銷活動商品審核->營銷活動、優惠券、商品的投放&推薦

交易鏈路:登陸(網站/APP/小程式/H5)->京東首頁(搜索&推薦)->商詳->購物車->結算頁->收銀台(支付)->訂單(訂單列表/訂單詳情頁)->資金對賬

履約鏈路:訂單拆分、轉移、下傳、出管->POP商家(採銷/供應商)接單->發貨、揀貨、打包、出庫、列印面單->分揀、配送、自提->確認收貨

售後鏈路:拒收/訂單取消/售後退貨、換貨、退款->商家審核/快速退款/糾風判責->暫停修改訂單、攔截物流返倉、原路(部分)退款、上門維修、換新單等->財務對賬->客戶滿意度評價

上面提到的鏈路因為分叉分支很多,比如時效保證、開寄發票、預售先款/先貨、商品評價、直播空間、店鋪評價、客服處理等等內容未涉及,也從側面想說明如果想要保障整個電商平臺的大促穩定,如果不區分重點的話,那麼眉毛鬍子一把抓是肯定完不成好的效果,所以這一個環節主要想要闡述說明在特定場景下,電商大促更多的是保障重點在哪裡。

三、【明目標】大促備戰目標

大促備戰目標的核心一個點:穩。在我們工作中,很多有經驗的同學會發現,如何去設計一個良好的系統,大概會從如下幾個要素考慮:功能性、可用性、性能效率、安全和擴展性,有些場景可能比如秒殺系統更多考率的是高併發因素。那麼在整個大促備戰過程中,基於場景不同,所以我們的大促備戰目標也不可同述。但是整體的總目標來說,依然維持在可用性,如何保障交易核心鏈路更穩、更好的支撐用戶購買下單,促成交易。

但是事與願違,往往我們會發現管理者、項目、產品、研發、測試總是會面臨同樣的一個問題,資源不足,無論是人力、物力或者財力,永遠資源不足的問題是我們要解決的一大核心問題。從古至今,上到將軍打仗、皇帝恩濟百姓,下到企業家創業,資源不足就決定了我們在做決策的時候,需要集中優勢力量兵力結合正確的戰略方針,攻擊目標最薄弱的環節,保障方案正確落地,正所謂蛇打七寸。所以接下來就很明晰我們要做什麼?如何做是我們要考慮的重點。

四、【定戰略】大促整體備戰思路

大促備戰是一個完整的事件,具備著詳細的故事線,這裡面延展開說明下,在領域驅動設計的建模過程中有個事件建模其實就非常好的應證了這一個點,如果我們將人類文明的活動想要梳理清楚,其實很多時候會發現越理越亂,所謂的點-線-面-體,其中線是我們更好的中間表述環節。基於故事線來看的話,那麼整體備戰思路,我們拆解為事前-事中-事後來考慮, 相對而言會比較全面的將大促備戰體系針對特定場景下的備戰儘可能全面。

4.1、事前:基於現狀進行整體提前工作安排

(1)參與部門/集團大促啟動會,及時獲取最新集團備戰導向和最新的戰略內容,比如京東的三道防線戰略。

(2)進行資源盤點梳理,包含人員、應用、上下游依賴、中間件、資料庫,本次大促的SLA約定,值班上下游群,問題反饋群,大促備戰手冊等。

(3)針對可以降低發生概率的事項進行改造,比如梳理核心鏈路,針對鏈路上的薄弱點進行改造,並對於日誌進行改造可以基於不同場景進行日誌輸出,規範整個大促備戰的指南方案。

(4)宣講儀式增強備戰感知,比如基於大促封板需求開始,進行大促意識宣講,同時完善監控大盤,補充關鍵日誌,報警郵件簡訊治理,歷屆大促相關指標同環比數據對照分析數據表等。

(5)宣講會後日檢工作內容,比如成立應急故障虛擬小組,基於歷史故障和常見問題形成故障手冊,同時制定限流和降級預案等指南手冊。

4.2、事中:基於備戰情況保持警惕備戰狀態

(1) 每日郵件指標報表通曬

(2)每日錯誤日誌收集並反饋和解決

(3)每日監控報警根因分析

(4)每日站會同步當天系統應用和人員情況

(5)跟進部門/集團大促備戰日例會

4.3、事後:基於整個備戰結果進行效果復盤

(1)業務目標的達成情況,比如某個營銷活動的達成情況,做的好的,待改善的,可以萃取經驗的內容。

(2)產研測團隊的系統需求保障情況,比如大促前期和中間上線的需求,上線情況和需求收益達成情況。

(3)系統應用的指標、資源成本、人力成本投入情況,比如每年大促備戰基於成熟化的工作流程、工具等內容,在業務變化不大的情況下,成本投入應該逐年下降等。

(4)備戰沉澱的經驗形成文檔資產,每次大促都是系統歷煉的一次非常好的機會,期間形成的文檔資產都可以歸檔方便下次使用。

(5)大促備戰中的待辦工作內容和事項持續跟蹤,很多時候團隊部門缺少跟蹤事項表,只是記錄了時間和人但是持續跟蹤的事情沒有持續性。

五、【做戰術】大促整體備戰工作

5.1、流量沙漏防護原理介紹

因為上述戰略中我們提到的內容比較多,我們這裡以系統應用為切入點,開始進行系統評估是否屬於良好的應用,如果特征因素中有不滿足的我們進行薄弱挖掘,比如大促備戰中,其實整個防護工作是以流量沙漏防護原理為核心的,從流量請求開始,CDN、Nginx、業務網關/前端應用直到後端應用(包含中後臺系統)以及依賴的相關組件和其他應用,其實是在一個整個流量沙漏下,最複雜最核心的也是我們最常講的就是後端應用故障穩定保障。

5.2、流量沙漏防護原理後端應用考慮因素評估表

基於上述的流量沙漏防護原理我們可以進行如下的考慮因素進行後端應用評估,挖掘薄弱點。

考慮因素 特征 措施
功能/適用性 合適原則 系統需求的可理解
性能效率 全面性 頁面、介面、功能載入時間
時間性 RT響應時間、吞吐量
資源利用率 記憶體、磁碟空間、CPU使用率
可擴展性 代碼、架構設計
可用性 全面性 平均無故障時間、平均修複時間、平均故障間隔時間
穩定性 平均停機時間
容錯性 錯誤崩潰、代碼覆蓋率、多機房容災、冗餘備份等
可維護性 全面性 應用維護人力投入情況
模塊化 結構清晰、邊界清晰
可重覆使用性 代碼、功能復用情況
可測試性 代碼覆蓋率
可分析性 複雜性、代碼圈複雜度、服務之間交互耦合等
可變更性 代碼大小、變更、代碼耦合、服務單一職責等
成本 全面性 開發、測試、部署維護
基礎設施 雲/本地基礎設施成本

5.3、流量沙漏防護原理的備戰重點&應用健康度

CDN動靜分離:主要集中在我們的前後端分離場景下,但是據筆者瞭解因為歷史、組織結構調整交接等各種原因依然有很多應用沒完整徹底的前後端分離,界面還是以後端維護和編寫;但是如果是核心應用的話基本上都完成了前後端分離,所以這塊優化相對簡單。

網關安全保障:通常我們的網關分為技術網關和業務網關,技術網關更多關註的是安全、鑒權、防刷、防攻擊、限流和降級等功能,業務網關更多的是偏BFF層的業務介面適配、裁剪等能力。這塊我們應該更多面對的是熱點流量峰值的不確定性、用戶行為的不確定性以及安全攻擊等風控行為,需要結合風控團隊對於黑產異常流量、異常IP、Cookie自動加入黑名單進行限流操作;同時結合大促壓測進行壓測指標評估,結合大促預期目標對於系統應用有個合理的閾值和水位管控。

後端應用:後端應用類型、功能、服務面向用戶不同決定了高可用的保障手段不同,比如後端應用分類可以基於任務類、工具類、支撐業務類、核心業務類等劃分;根據其應用分級的定義程度我們進行應用健康緯度的評估,評估基礎硬體資源、容器資源、應用資源、監控報警、鏈路維度等明細情況,進行薄弱環節治理,比如公司平臺的應用健康度能夠合理的給應用進行畫像,便於問題的診斷和定位。

類型 檢測指標
基礎資源 應用跨集群
應用跨機房
應用跨POD
應用POD分佈
JIMDB POD分佈
網路TCP重傳
應用容器CPU
JIMDB CPU
JMQ CPU
資料庫 CPU
JIMDB分片拓撲
JIMDB分片POD
資料庫主從
資料庫機房
資料庫規格
JMQ POD
VIP機房數量
後端機房數量
錯誤後端(ip)
集群環境一致
容器 容器存活
應用模塊化
GIT分支
灰度更新超時
CPU利用率
記憶體使用率
磁碟繁忙
網路流入
TCP連接數
CPU利用率
記憶體使用率
Swap使用率
磁碟繁忙
磁碟使用率(根目錄)
磁碟使用率(export)
網路連通性
網路流入
網路流出
系統時間偏差
應用 JSF版本
JMDB版本
JMQ2版本
JMQ4版本
UMP版本
DUCC版本
LOG4J版本
JVM版本
Full GC/Young GC
JVM_XMX最大堆記憶體
JVM_XMS最小堆記憶體
JVM_堆外記憶體
JVM_ParallelGCThreads
JVM_GCConcGCThreads
JVM_CICompilerCount
JVM_Metaspace
JVM_CMS回收閾值
JVM_新生代大小
JVM_HeapDump
JVM_Server模式
JDOS_日誌清理
JSF_Timeout超時時間
JSF_跨單元調用
JSF_跨環境調用
JSF_跨機房調用
JSF_重試次數
負載均衡
JSF_限流
JSF_動態別名
JSF_設置黑名單
JSF_同機房部署
JSF_別名命名規範
JSF_混合環境部署
color網關timeout
最大連接數
初始連接數
connectTimeout
SocketTimeout
maxWait
時區
JIMDB FAILOVER狀態
JIMDB 熱KEY
JIMDB 大KEY
JIMDB 慢日誌
JIMDB 掃描過期頻率
JIMDB 服務端版本一致
JIMDB 服務端風險版本
淘汰策略
JIMDB_Swap交換區
JIMDB_綁核
JIMDB_CPU模式
JIMDB_網卡軟中斷
慢SQL
優先治理慢SQL
含外鍵表
索引過多表
自增溢出表
大表
接入方式
最大線程數
JIMDB讀超時
JIMDB跨單元調用
JIMDB連接超時
JIMDB等待超時
JIMKV連接超時
JIMKV讀超時
JMQ_sendTimeout
空應用
純預發應用
單實例應用
預發流量過大
預發資源過多
不活躍預發分組
應用_實例存活
應用_Port存活
應用_URL存活
JSF_Provider介面存活
JSF_Consumer介面存活
依賴JIMDB集群異常Server_OPS次數
Server_CPU利用率
Server_記憶體使用率
Server_記憶體RSS
Server_網路流入
Server_網路流出
Server_連接數
tp99異常次數
積壓
broker 主機-負載
broker 主機-磁碟繁忙
JED Qps
JED連接數
JED主從延遲
監控報警 CPU利用率
負載
記憶體使用率
Swap使用率
磁碟繁忙
磁碟使用率
網路連通性
TCP連接數
TCP重傳
網路流入
網路流出
系統時間偏差
JsfProvider組件報警
JimDB組件報警
JmqProducer組件報警
Mysql組件報警
SpringMVC組件報警
UMP JVM監控
UMP 方法監控
JVM_CPU利用率
JVM_記憶體使用率
JVM_線程數
FULLGC次數
YONGGC次數
方法TP99
方法TP999
方法可用率
方法TP99配置合理性
方法TP999配置合理性
方法可用率配置合理性
方法調用次數
Port存活
URL存活
OPS次數
連接數
記憶體使用率
主從斷開
主從複製延遲
積壓
重試
主從延遲
Logbook關鍵字報警配置
鏈路超時 鏈路超時
鏈路超時JIMDB組件

其他應用/中間件/資料庫:我們會發現很多時間我們的問題引入集中在三方因素較多,也是在備戰中需要關註的重點:

•- 介面定義不合理,業務周知不到位,新上的業務需求直接在某個時刻脈衝流量到達薄弱依賴將服務打掛;

•- 還有部分是因為上下游依賴不穩定,比如遇到性能瓶頸,業務系統強依賴無法作出降級操作,只能靜靜等待恢復故障;

•- 在機房方面沒有容災,可能因為通信機房網路問題,電纜被挖斷或者信號中斷等問題導致網路癱瘓故障不可用;

•- 中間件使用策略異常,比如沒有做業務冪等性操作、重試策略未控制次數和時間導致依賴的業務系統無法承接脈衝流量從而服務不可用;

•- 還有依賴的中間件和資料庫容量水位已到閾值,沒有及時擴容,從而引發業務系統的不可用。

•- 應用操作資料庫線程阻塞、死鎖、慢SQL等造成資料庫拖垮服務應用

•- 應用操作緩存/ES出現熱點的商品造成的數據流量不均引發的服務不可用。

•- 應用記憶體泄漏、JVM配置不合理等等

通過上述的流量沙漏防護原理是希望幫助大家能夠對於大促備戰有個整體框架,從而更好的結合三道防線戰略,以及考慮因素評估表和應用畫像來決策如何治理整改應用不合理的內容,最終形成相對合理的應用架構。

六、【促成長】其他

電商大促相對每個人來說都是很好的成長機會,通過大促備戰能夠讓你更好的補齊自身知識的不足,也能更深入的瞭解所在團隊的核心業務,所以建議無論是業務運營、產品、研發、測試人員都可以簡單瞭解下。

那麼如何成為一個合格的團隊大促備戰師呢?筆者以自身當時經歷來說,就是大促備戰師要做到胸有成竹,在大促備戰前應該充分瞭解核心鏈路業務,做好事前工作梳理,能夠有著大促指南手冊宣導給團隊每一個人,做到精兵強將,人人互為備份,將監控報警可視化面板進行大屏展示,及時捕捉和觀察業務變動情況。

那麼如何成為一個事業部架構師或者集團架構師呢?筆者認為需要有嚴格清晰的備戰路線和里程碑,關註的重點事項以及日例會進行事項跟進和同步,因為當人數超過幾十人以後,大促備戰更多的是管人、管流程,而不是管應用,所以需要責任到部門、到個人,緊抓流程,同時日例會及時信息溝通減少信息變更差。

作者:京東零售 劉曉成

來源:京東雲開發者社區


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 一、哪些因素會成為系統的瓶頸 CPU:如果存在大量的計算,他們會長時間不間斷的占用CPU資源,導致其他資源無法爭奪到CPU而響應緩慢,從而帶來系統性能問題,例如頻繁的FullGC,以及多線程造成的上下文頻繁的切換,都會導致CPU繁忙,一般情況下CPU使用率<75%比較合適。 記憶體:Java記憶體一般是 ...
  • 我們智能客服知識庫機器人已經開發完成,後端資料庫是使用的qdrant向量資料庫,但是該資料庫並沒有導出備份功能,所以我按簡單的純前端實現知識庫導出excel數據 使用第三方庫(如SheetJS) SheetJS是一個流行的JavaScript庫,可幫助處理Excel文件。您可以使用SheetJS來將 ...
  • 這裡給大家分享我在網上總結出來的一些知識,希望對大家有所幫助 背景 愉快的雙休周末剛過完,早上來忽然被運營通知線上業務掛了,用戶無法下單。卧槽,趕緊進入debug模式,一查原來是服務端返回的數據有問題,趕緊問了服務端,大佬回覆說是業務部門配置套餐錯誤。好在主責不在我們,不過趕緊寫了復盤文檔,主動找自 ...
  • 博客推行版本更新,成果積累制度,已經寫過的博客還會再次更新,不斷地琢磨,高質量高數量都是要追求的,工匠精神是學習必不可少的精神。因此,大家有何建議歡迎在評論區踴躍發言,你們的支持是我最大的動力,你們敢投,我就敢肝 ...
  • 1.添加函數修改img的屬性; /** * * @param {*} idName 傳入的id,獲取改img的dom,添加相應的數學 */ export const proxyImg = (idName) => { const img = document.getElementById(idName ...
  • 打開前端項目中的 package.json,會發現眾多工具已經占據了我們開發日常的各個角落,它們的存在於我們的開發而言是不可或缺的。有沒有想過這些工具的功能是如何實現的呢?沒錯,抽象語法樹 (Abstract Syntax Tree) 就是上述工具的基石。 ...
  • TCP/IP是一種分層模型,它將通信協議分解為五個層次,每個層次都有特定的功能和任務。以下是TCP/IP五層的處理流程: ...
  • 採用依賴倒置原則後的分層架構和六邊形架構,實際上都符合整潔架構設計理念。但是六邊形架構中使用埠與適配器,讓應用程式能夠以一致的方式被用戶、程式、自動化測試、批處理腳本所驅動,同時能夠讓應用程式邊界更加清晰,從而能更好地防止領域層和應用層邏輯泄露到外層。 ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發(一):使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說,近來想嘗試開發一款安卓APP,考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP,畢竟是使用Visual Studio開發工具,使用起來也比較的順手,結合微軟官方的教程進行了安卓 ...
  • 前言 QuestPDF 是一個開源 .NET 庫,用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫,它徹底改變了我們生成 PDF 文檔的方 ...
  • 項目地址 項目後端地址: https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址: ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址: http://tree ...
  • 話不多說,直接開乾 一.下載 1.官方鏈接下載: https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe,運行開始下載SQL server; 二. ...
  • 前言 隨著物聯網(IoT)技術的迅猛發展,MQTT(消息隊列遙測傳輸)協議憑藉其輕量級和高效性,已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫,為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog支持多種接收器用於日誌存儲,增強器用於添加屬性,LogContext管理動態屬性,支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項,適用於不同需求。 ...
  • 目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據,爬取信息時需要模擬瀏覽器行為,否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下: 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • 1.前言 什麼是熱更新 游戲或者軟體更新時,無需重新下載客戶端進行安裝,而是在應用程式啟動的情況下,在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR,Xlua,ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles,Addressable, ...
  • 本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺,其實像阿裡雲,騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後,它會送 ...
  • 通過以下方式可以高效,並保證數據同步的可靠性 1.API設計 使用RESTful設計,確保API端點明確,並使用適當的HTTP方法(如POST用於創建,PUT用於更新)。 設計清晰的請求和響應模型,以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證,確保接收到的數據符合預期格 ...