生產(chǎn)上線以后發(fā)現(xiàn)內(nèi)頁(yè)圖片無法訪問，全部400錯(cuò)誤：
甚至部分api地址也是不定時(shí)的報(bào)錯(cuò)400
更甚至首頁(yè)有時(shí)候直接就報(bào)錯(cuò)400
國(guó)內(nèi)訪問很高的概率出現(xiàn)400錯(cuò)誤，但是只要一翻墻，訪問就正常，但是在香港、澳大利亞、新加坡也有部分客戶訪問會(huì)出現(xiàn)400錯(cuò)誤。
但是一樣配置的UAT一切正常，生產(chǎn)環(huán)境唯一不一樣的就是域名。
在花了兩天時(shí)間排查了CDN、安全防護(hù)所有一切可能以后，向騰訊云提交了工單。
得到了這么一個(gè)結(jié)果：
背景說明：Domain?Fronting?防護(hù)機(jī)制
在 2023年起，香港政府及其承包供應(yīng)商對(duì)?Domain?Fronting（域名前置）攻擊要求加強(qiáng)防護(hù)。
該攻擊方式的原理是：
攻擊者可以偽造?TLS?握手里的?SNI（Server?Name?Indication）?和?HTTP?請(qǐng)求頭中的Host?不一致，例如：
SNI?顯示為gov.hk?（可信域名）
Host?頭卻指向evil.com?（惡意服務(wù)器）
這會(huì)導(dǎo)致安全設(shè)備、CDN?或?WAF?錯(cuò)誤地認(rèn)為是合法流量，從而實(shí)現(xiàn)繞過檢測(cè)、信息隱匿等攻擊行為。
因此，安全需求明確提出：
“當(dāng)客戶端攜帶的?SNI?與?HTTP?Host?Header?不一致時(shí)，系統(tǒng)需攔截請(qǐng)求并返回400。”
所以當(dāng)我們通過多域名去區(qū)分pc端、手機(jī)端、文件、API的時(shí)候，就出現(xiàn)了不一致的情況。
比如兩域名（www?和m）在相同IP?下、使用同一通配符或?SAN?證書，且服務(wù)端啟用了HTTP/2 (h2)，瀏覽器為了性能優(yōu)化啟用了Connection?Coalescing（連接復(fù)用）機(jī)制。
其行為是：
瀏覽器僅建立 一次?TLS?連接（SNI?=?www.xxx.hk）；
接著在這條TLS?連接上復(fù)用通道發(fā)送Host:?m.xxx.hk?請(qǐng)求。
出于?香港政府Domain?Fronting?策略要求，該行為被判斷為異常訪問（SNI/Host?不一致），EdgeOne?安全引擎觸發(fā)?防護(hù)攔截 → 返回?HTTP?400
所以關(guān)閉EdgeOne默認(rèn)的http2加速就可以了。
接口請(qǐng)求很簡(jiǎn)單，無非就是數(shù)據(jù)庫(kù)查詢數(shù)據(jù)驗(yàn)證賬號(hào)密碼，而數(shù)據(jù)庫(kù)。
數(shù)據(jù)庫(kù)查詢和feign調(diào)用基本都是io請(qǐng)求，唯一存在計(jì)算的就是密碼加密，現(xiàn)在用的是BCryptPasswordEncoder.matches()。
網(wǎng)上一查這個(gè)方法的確會(huì)消耗大量的CPU資源，屬于CPU密集型計(jì)算。
于是換了一個(gè)其他加密方法，500并發(fā)，CPU只消耗了60%左右。
數(shù)據(jù)庫(kù)QPS也起來了。
測(cè)試多次基本穩(wěn)定了。
一開始以為網(wǎng)絡(luò)問題，刷新DNS、更換了WiFi都不行。
以為git出現(xiàn)問題了，又重新卸載安裝了git，故障依舊。
嘗試重新拉一個(gè)其他倉(cāng)庫(kù)的代碼，也是一樣的問題。
最后甚至把ipV6也關(guān)掉的了，也不行。
在我打開IDE工具的時(shí)候，突然右下方提示我git收到windows defender的限制，可能影響性能。
于是去查看windows自帶的防火墻，不知道什么時(shí)候他自己開啟了。
關(guān)閉以后git一切就正常了。
]]>一、架構(gòu)設(shè)計(jì)與核心特性
TDSQL-C MySQL
-
架構(gòu)：采用計(jì)算與存儲(chǔ)分離的云原生架構(gòu)，支持秒級(jí)彈性擴(kuò)縮容（如單集群最多15個(gè)只讀實(shí)例），存儲(chǔ)層基于分布式云存儲(chǔ)，單實(shí)例最高支持PB級(jí)存儲(chǔ)。
-
性能優(yōu)化：
-
寫入性能：通過Redo日志同步機(jī)制，主從延遲低至毫秒級(jí)，寫入性能較傳統(tǒng)MySQL提升約140%69。
-
Serverless支持：按需自動(dòng)啟停，無流量不計(jì)費(fèi)，適合業(yè)務(wù)波動(dòng)場(chǎng)景。
-
網(wǎng)絡(luò)協(xié)議：使用RDMA技術(shù)（雙25Gbps），降低I/O延遲，提升吞吐量。
PolarDB MySQL
-
架構(gòu)：基于分布式存儲(chǔ)與共享存儲(chǔ)池，支持多主多寫（最多8節(jié)點(diǎn)）、HTAP混合負(fù)載，并集成列存索引（IMCI）加速分析查詢。
-
性能優(yōu)化：
-
查詢性能：列存索引（IMCI）可將復(fù)雜查詢耗時(shí)縮短數(shù)倍，彈性并行查詢（ePQ）利用多節(jié)點(diǎn)資源加速處理，適合大數(shù)據(jù)分析場(chǎng)景。
-
高可用性：無感秒切技術(shù)（5-10秒完成主備切換），支持跨地域容災(zāi)（RPO=0）。
-
擴(kuò)展性：在線彈性擴(kuò)縮容，支持Serverless模式下資源動(dòng)態(tài)匹配。
二、關(guān)鍵性能指標(biāo)對(duì)比
| 對(duì)比維度 | TDSQL-C MySQL | PolarDB MySQL |
|---|---|---|
| 寫入吞吐量 | 單節(jié)點(diǎn)百萬級(jí)QPS，Redo日志同步延遲更低 | 一寫多讀架構(gòu)優(yōu)化，多主多寫支持更高并發(fā) |
| 查詢性能 | 適合OLTP場(chǎng)景，緩存命中率高時(shí)讀性能穩(wěn)定 | 列存索引（IMCI）提升復(fù)雜查詢性能400倍，支持HTAP混合負(fù)載 |
| 擴(kuò)展能力 | 秒級(jí)添加只讀節(jié)點(diǎn)，計(jì)算與存儲(chǔ)獨(dú)立擴(kuò)展 | 支持多節(jié)點(diǎn)并行擴(kuò)展，彈性并行查詢（ePQ）突破單機(jī)瓶頸 |
| 高可用性 | 秒級(jí)故障恢復(fù)，快照備份恢復(fù)速度達(dá)GB/秒 | 無感秒切技術(shù)，跨AZ容災(zāi)，事務(wù)不中斷 |
| 成本優(yōu)化 | Serverless按需計(jì)費(fèi)，無流量不計(jì)費(fèi) | Serverless動(dòng)態(tài)資源匹配，冷溫?zé)釘?shù)據(jù)分層存儲(chǔ)降低成本 |
三、適用場(chǎng)景推薦
-
TDSQL-C MySQL更優(yōu)的場(chǎng)景：
-
高并發(fā)寫入：如實(shí)時(shí)交易系統(tǒng)、游戲日志處理，依賴Redo日志低延遲同步。
-
業(yè)務(wù)波動(dòng)大：Serverless自動(dòng)啟停，適合電商促銷、直播峰值等彈性需求。
-
強(qiáng)一致性要求：金融級(jí)事務(wù)場(chǎng)景，主從延遲敏感。
-
PolarDB MySQL更優(yōu)的場(chǎng)景：
-
混合負(fù)載（HTAP）：需同時(shí)處理事務(wù)與分析查詢，如實(shí)時(shí)報(bào)表、大數(shù)據(jù)分析。
-
多地域部署：全球數(shù)據(jù)庫(kù)網(wǎng)絡(luò)（GDN）支持跨地域數(shù)據(jù)同步，降低訪問延遲。
-
復(fù)雜查詢加速：列存索引（IMCI）和彈性并行查詢（ePQ）顯著提升OLAP性能。
四、總結(jié)建議
-
性能綜合對(duì)比：
-
寫入性能：TDSQL-C因Redo日志同步機(jī)制更優(yōu)，適合寫入密集型場(chǎng)景。
-
查詢性能：PolarDB在復(fù)雜查詢和HTAP場(chǎng)景表現(xiàn)更佳，尤其是IMCI和ePQ技術(shù)。
-
擴(kuò)展性與成本：兩者均支持Serverless，但TDSQL-C在秒級(jí)彈性伸縮上更突出，PolarDB在存儲(chǔ)分層和全局一致性上更具優(yōu)勢(shì)。
-
選擇建議：
-
若業(yè)務(wù)以高并發(fā)寫入、強(qiáng)一致性為主，且需頻繁彈性擴(kuò)縮容，TDSQL-C MySQL更合適。
-
若需兼顧事務(wù)與分析、多地域部署或復(fù)雜查詢優(yōu)化，PolarDB MySQL更具競(jìng)爭(zhēng)力。
1. 架構(gòu)設(shè)計(jì)
-
TDSQL-C MySQL版：
基于云原生架構(gòu)，采用計(jì)算與存儲(chǔ)分離的設(shè)計(jì)，支持集群模式，一個(gè)集群最多包含1個(gè)讀寫實(shí)例和15個(gè)只讀實(shí)例。計(jì)算節(jié)點(diǎn)無狀態(tài)，支持秒級(jí)擴(kuò)縮容和故障恢復(fù)，且通過分布式存儲(chǔ)實(shí)現(xiàn)單實(shí)例最高400TB的容量。 -
云數(shù)據(jù)庫(kù)MySQL：
采用傳統(tǒng)主從架構(gòu)，分為單節(jié)點(diǎn)、雙節(jié)點(diǎn)（一主一備）、三節(jié)點(diǎn)（一主兩備）及集群版（最多5個(gè)只讀節(jié)點(diǎn)），存儲(chǔ)與計(jì)算耦合，擴(kuò)展需手動(dòng)操作且耗時(shí)較長(zhǎng)。
2. 核心特性對(duì)比
| 對(duì)比項(xiàng) | TDSQL-C MySQL版 | 云數(shù)據(jù)庫(kù)MySQL |
|---|---|---|
| 引擎 | InnoDB、LibraDB（優(yōu)化寫入性能） | InnoDB、RocksDB（適用于特定存儲(chǔ)場(chǎng)景） |
| 版本兼容性 | 支持MySQL 5.7、8.0 | 支持MySQL 5.6、5.7、8.0 |
| Serverless支持 | 支持，自動(dòng)彈性伸縮規(guī)格，無使用不計(jì)費(fèi) | 不支持 |
| 最大建表數(shù) | 無限制（僅受存儲(chǔ)空間限制） | 單個(gè)實(shí)例表數(shù)量不超過100萬 |
| 主從同步機(jī)制 | 基于Redo日志同步，延遲低至毫秒級(jí) | 基于Binlog同步，存在主從延遲問題 |
| 備份與回檔速度 | 支持快照備份，每秒GB級(jí)恢復(fù)速度 | 物理備份，恢復(fù)速度較慢 |
3. 性能與擴(kuò)展性
-
寫入性能：TDSQL-C通過優(yōu)化日志機(jī)制（僅寫入Redo日志）提升140%的寫入性能。
-
擴(kuò)展能力：TDSQL-C支持秒級(jí)橫向擴(kuò)容（如增加只讀實(shí)例）、縱向彈性調(diào)整規(guī)格，且磁盤擴(kuò)容對(duì)業(yè)務(wù)無感知；而云數(shù)據(jù)庫(kù)MySQL需提前規(guī)劃資源，擴(kuò)展耗時(shí)較長(zhǎng)。
-
存儲(chǔ)容量：TDSQL-C單實(shí)例支持PB級(jí)存儲(chǔ)，云數(shù)據(jù)庫(kù)MySQL受限于單物理機(jī)存儲(chǔ)上限。
4. 適用場(chǎng)景
-
TDSQL-C MySQL版：
-
業(yè)務(wù)波動(dòng)大，需頻繁擴(kuò)縮容（如游戲、電商促銷場(chǎng)景）；
-
高寫入QPS需求（如實(shí)時(shí)交易系統(tǒng)）；
-
對(duì)主從延遲敏感（如金融級(jí)強(qiáng)一致性場(chǎng)景）；
-
需Serverless能力以降低運(yùn)維成本。
-
云數(shù)據(jù)庫(kù)MySQL：
-
傳統(tǒng)互聯(lián)網(wǎng)應(yīng)用（如社交、內(nèi)容平臺(tái)）；
-
中小型金融或電商業(yè)務(wù)；
-
對(duì)成本敏感且無需高頻彈性擴(kuò)展的場(chǎng)景。
5. 成本與運(yùn)維
-
TDSQL-C：按需計(jì)費(fèi)（Serverless模式下無流量不計(jì)費(fèi)），自動(dòng)化運(yùn)維（如自動(dòng)備份、監(jiān)控）。
-
云數(shù)據(jù)庫(kù)MySQL：固定規(guī)格預(yù)付費(fèi)，需手動(dòng)管理備份及擴(kuò)縮容。
總結(jié)建議
若業(yè)務(wù)需要高彈性、低延遲、海量存儲(chǔ)，或計(jì)劃使用Serverless模式，TDSQL-C MySQL版是更優(yōu)選擇；若需求偏向穩(wěn)定性與成本可控，且無需頻繁調(diào)整資源，云數(shù)據(jù)庫(kù)MySQL更適合。
]]>而且非常奇葩的是，溝通過程中，他們承認(rèn)不合理，但就是不改，只有去投訴才會(huì)給你按剩余多少退多少。
他的退款規(guī)則非常復(fù)雜，一個(gè)正常用戶，沒一個(gè)人能看懂的。只要你按照自主操作區(qū)退款，就會(huì)默認(rèn)按照他的規(guī)則給你退款，那么基本上你用了2/3的時(shí)間以后，退款金額就接近0了。
我以為是阿里云一家特例，沒想到騰訊云也一樣，難道出自同一個(gè)產(chǎn)品經(jīng)理？
我買了一個(gè)月的包年包月服務(wù)器，費(fèi)用是1260
用了20天
退款金額是2.9元
我也提交工單，看看客服怎么解釋的。
我就猜到會(huì)給我一個(gè)非常復(fù)雜的公式。
看他那個(gè)公式，我理解的就是比如我原來包年包月比較便宜，中途退款以后就按照按量計(jì)費(fèi)，但是按照按量計(jì)費(fèi)使用20天的費(fèi)用也是1180，也不知道為什么剩余2.9元。
2025-04-14 20:50:37 [ERRO] POST http://jms-core:8080/api/v1/terminal/terminal-registrations/ failed, get code: 400, {"error":"service account registration disabled"}
2025-04-14 20:50:42 [ERRO] POST http://jms-core:8080/api/v1/terminal/terminal-registrations/ failed, get code: 400, {"error":"service account registration disabled"}
2025-04-14 20:50:47 [ERRO] POST http://jms-core:8080/api/v1/terminal/terminal-registrations/ failed, get code: 400, {"error":"service account registration disabled"}
無法正常注冊(cè)
這個(gè)主要是因?yàn)樵诓渴鸷弥螅炎?cè)功能關(guān)閉了。
只要把這個(gè)開關(guān)打開就行了。
可以看到已經(jīng)注冊(cè)成功了。
這個(gè)問題的前提是要保證遷移前后的BOOTSTRAP_TOKEN一致。
]]>
但是通過命令 wsl -d ubuntu直接啟動(dòng)缺正常。
主要原因就是Terminal Ubuntu這個(gè)配置里面的“啟動(dòng)目錄設(shè)置的”~ Windows無法識(shí)別。
直接改成一個(gè)存在的目錄就行。
再去啟動(dòng)就正常了。
于是卸載了wps，官網(wǎng)下載了最新的版本，安裝以后還是一樣的問題。
又換了一個(gè)版本安裝，安裝好還是打開就卡死。
開始懷疑是不是緩存文件導(dǎo)致的，于是又卸載WPS，擅長(zhǎng)所有的緩存文件重新安裝，結(jié)果依然卡死。
在折騰了兩三個(gè)小時(shí)以后，無意間在配置和修復(fù)
的高級(jí)設(shè)置里面
設(shè)置了硬件加速
于是取消勾選以后，再去打開文件發(fā)現(xiàn)一切正常了。
]]>我們開發(fā)在開發(fā)環(huán)境build發(fā)布到集群以后，報(bào)錯(cuò)docker: not found。
一開始以為是容器里面沒有安裝成功docker，檢查dockerfile沒有發(fā)現(xiàn)異常。
docker build以后本地測(cè)試鏡像里面docker命令可以正常運(yùn)行。
由于這個(gè)項(xiàng)目的部署沒有采用自動(dòng)化，而且服務(wù)與服務(wù)之間的部署都是靠多個(gè)腳本去觸發(fā)。
一開始懷疑ECS上面運(yùn)行的鏡像不是我們本地推送的鏡像，經(jīng)過一些列的排查，發(fā)現(xiàn)使用的tag是正確的。
由于這個(gè)項(xiàng)目build需要很久，push鏡像也需要很久，就自己寫了一個(gè)dockerfile build測(cè)試，但是發(fā)布以后可以正常找到docker命令。
就在沒有方向的時(shí)候，開發(fā)說這個(gè)項(xiàng)目之前是部署在amd架構(gòu)的服務(wù)器上面的，最近項(xiàng)目方才改到了arm架構(gòu)上面，會(huì)不會(huì)是因?yàn)檫@個(gè)。
看了使用的build命令
buildx 默認(rèn)使用的 構(gòu)建器（ builder ） 驅(qū)動(dòng)是 docker driver，它不支持同時(shí)構(gòu)建多個(gè) platform 的鏡像。
需要使用 docker buildx create 創(chuàng)建docker-container driver的構(gòu)建器。
docker run --privileged --rm tonistiigi/binfmt --install all
docker buildx create --name mybuilder --driver docker-container --use
docker buildx inspect --bootstrap
]]>