Spark SQL 在極光的建設(shè)實(shí)踐
Locust性能測(cè)試工具的使用
數(shù)據(jù)質(zhì)量建設(shè)實(shí)踐
百億級(jí)數(shù)據(jù)的實(shí)時(shí)存取優(yōu)化與實(shí)踐
極光clickhouse千億級(jí)數(shù)據(jù)分析實(shí)踐之路
關(guān)于企業(yè)上云，業(yè)內(nèi)已經(jīng)有了非常多的討論和論述。這里主要是從極光自身的實(shí)際情況闡述幾個(gè)理由：
1. 傳統(tǒng)自建機(jī)房在擴(kuò)充底層軟硬件資源時(shí)，需要進(jìn)行選型、采購(gòu)、參數(shù)測(cè)試驗(yàn)證、實(shí)施部署等流程，整個(gè)過(guò)程需要消耗很多的人力和時(shí)間，對(duì)于快速發(fā)展的業(yè)務(wù)來(lái)說(shuō)是很大的負(fù)擔(dān)。云服務(wù)可以極大的縮減整個(gè)流程，對(duì)于部分云服務(wù)例如云主機(jī)可以實(shí)現(xiàn)分鐘級(jí)別的資源交付。
2. 自建機(jī)房需要投入高額的硬件資源準(zhǔn)備，包括機(jī)房配套基礎(chǔ)設(shè)施、服務(wù)器、網(wǎng)絡(luò)、安全設(shè)備等，大量的冗余資源閑置，整體資源利用率不高。上云可以實(shí)現(xiàn)按需購(gòu)買(mǎi)使用，實(shí)現(xiàn)更高的資源利用率。
3. 基礎(chǔ)設(shè)施建設(shè)和維護(hù)需要投入大量的人力和精力，往往還吃力不討好。特別是虛擬化方面一直以來(lái)都是極光的痛點(diǎn)，資源隔離做得不好很容易受到其他虛擬機(jī)的影響，往往因?yàn)槟硞€(gè)業(yè)務(wù)的突增影響同一個(gè)物理機(jī)上的所有虛擬機(jī)。云廠商有龐大的專(zhuān)業(yè)團(tuán)隊(duì)進(jìn)行建設(shè)和維護(hù)，各方面相當(dāng)可靠。
4. 云廠商提供成熟穩(wěn)定的PaaS層服務(wù)可以進(jìn)一步釋放我們的精力，讓我們更專(zhuān)注在我們的業(yè)務(wù)，例如天然支持多AZ的RDS可以為我們?cè)诳紤]同城雙機(jī)房架構(gòu)時(shí)提供很大的助益。
早期極光只有一個(gè)單一的機(jī)房，隨著業(yè)務(wù)的發(fā)展，系統(tǒng)規(guī)模越來(lái)越龐大，單一機(jī)房的資源不足以支撐極光的業(yè)務(wù)。因此我們將業(yè)務(wù)系統(tǒng)遷移到了新建的機(jī)房，數(shù)據(jù)業(yè)務(wù)繼續(xù)保留在原有機(jī)房，整個(gè)過(guò)程磕磕碰碰歷時(shí)一年左右。
后來(lái)業(yè)務(wù)系統(tǒng)所在的機(jī)房再進(jìn)一步優(yōu)化，在同城增加一個(gè)機(jī)房，并用專(zhuān)線進(jìn)行互通，遲延在1ms到2ms之間，并將部分子系統(tǒng)遷移到新的AZ。由于我們的業(yè)務(wù)量級(jí)非常大，部分子系統(tǒng)的QPS超過(guò)了百萬(wàn)，在業(yè)務(wù)峰值偶爾出現(xiàn)延遲增加的情況，因此也做了相關(guān)的調(diào)整，訪問(wèn)量大的子業(yè)務(wù)系統(tǒng)盡量不跨AZ進(jìn)行訪問(wèn)。此時(shí)的多AZ，并不是每個(gè)AZ都有完整的業(yè)務(wù)流程，僅僅形成一個(gè)大內(nèi)網(wǎng)，在部署的時(shí)候進(jìn)行優(yōu)化處理。
由于機(jī)房?jī)H有單一的網(wǎng)絡(luò)出入口，帶寬也有限，很容易受到同機(jī)房的其他客戶的影響。曾經(jīng)出現(xiàn)過(guò)出口帶寬用滿甚至整個(gè)出口中斷的情況，業(yè)務(wù)受到嚴(yán)重的影響。我們也考慮了異地雙機(jī)房、單機(jī)房多網(wǎng)絡(luò)出口方案，但是這些方案僅僅是針對(duì)性的解決我們的一些問(wèn)題，沒(méi)有系統(tǒng)性的解決我們當(dāng)時(shí)的困境，因此這兩個(gè)方案并沒(méi)有真正意義的實(shí)行。同時(shí)內(nèi)部也在考慮上云的方案，外加一些外部因素，上云的方案就推到了首位。至于云廠商的選型此處就不做陳述，最終選擇了華為云。
極光推送為開(kāi)發(fā)者提供服務(wù)，一個(gè)開(kāi)發(fā)者可以有多個(gè)Appkey也就是多個(gè)應(yīng)用，每個(gè)Appkey的全部數(shù)據(jù)互不相關(guān)，一個(gè)Appkey有多個(gè)終端設(shè)備用戶。累計(jì)終端用戶超過(guò)500億，同時(shí)還有各個(gè)維度的數(shù)據(jù)，例如tag、alias等等，單副本數(shù)據(jù)總量超過(guò)80TB；月活躍終端用戶超過(guò)5億，各個(gè)API接口請(qǐng)求總量超過(guò)5萬(wàn)QPS。使用超過(guò)2萬(wàn)核CPU，超過(guò)2500臺(tái)虛擬機(jī)來(lái)支撐這些業(yè)務(wù)。
對(duì)外有2類(lèi)網(wǎng)絡(luò)通信：極光推送業(yè)務(wù)和開(kāi)發(fā)者服務(wù)的通信，主要形式是RestfulAPI；極光推送業(yè)務(wù)和應(yīng)用的通信，主要形式是基于TCP長(zhǎng)鏈接的自定義協(xié)議。
推送業(yè)務(wù)部署在虛擬機(jī)和K8S上，這里主要分析對(duì)比虛擬機(jī)的CPU、網(wǎng)絡(luò)、磁盤(pán)的相關(guān)指標(biāo)，以及K8S網(wǎng)絡(luò)的指標(biāo)。
從物理機(jī)看，自建機(jī)房的物理機(jī)相對(duì)華為云目標(biāo)AZ的物理機(jī)性能低一些，例如華為云的物理機(jī)使用更高主頻更高配的CPU。在虛擬化層面，華為云的虛擬化做得更好，資源隔離更加嚴(yán)格，提供各種規(guī)格的云主機(jī)和磁盤(pán)，從整體上來(lái)說(shuō)計(jì)算能力更加強(qiáng)，但是在網(wǎng)絡(luò)和磁盤(pán)IO吞吐和QPS有嚴(yán)格的限制，需要做好規(guī)劃。經(jīng)過(guò)測(cè)試對(duì)比，選擇了相關(guān)規(guī)格的云主機(jī)和磁盤(pán)。
自建機(jī)房-云環(huán)境架設(shè)專(zhuān)線，云主機(jī)和自建機(jī)房機(jī)器之間的RTT在5ms以內(nèi)，常規(guī)情況下為2-3ms，自建機(jī)房?jī)?nèi)網(wǎng)機(jī)器之間RTT為0.2ms左右，同一AZ云主機(jī)之間RTT為0.2-0.3ms。
在K8S網(wǎng)絡(luò)方面，自建機(jī)房做了相關(guān)的優(yōu)化，通過(guò)專(zhuān)用的網(wǎng)絡(luò)設(shè)備能夠使用Underlay的路由模式，可以說(shuō)是目前可用的原生網(wǎng)絡(luò)模式中性能最好的模式。華為云自建K8S集群僅僅支持Overlay模式，性能相對(duì)差了一些；同時(shí)也提供了K8S服務(wù)，通過(guò)硬件加速等優(yōu)化提供了較好的網(wǎng)絡(luò)性能。
上云有幾個(gè)需要考慮的要素：
● 業(yè)務(wù)無(wú)中斷遷移，盡量不影響客戶的使用，盡量不需要客戶做任何變更。
● 遷移前后業(yè)務(wù)功能一致，需要保證數(shù)據(jù)和業(yè)務(wù)的完整性。
● 需要考慮切換過(guò)程中極端情況導(dǎo)致的回滾操作，并且需要保證數(shù)據(jù)和業(yè)務(wù)的完整性。
基于以上幾點(diǎn)，在方案選型方面，我們主要考慮2個(gè)方案：
方案一：自建機(jī)房和云環(huán)境是2套獨(dú)立、隔離的環(huán)境，關(guān)聯(lián)的僅僅是自建到云環(huán)境的數(shù)據(jù)同步，業(yè)務(wù)上相互隔離。以Appkey為單位，遷移Appkey所有的數(shù)據(jù)和業(yè)務(wù)。數(shù)據(jù)通過(guò)專(zhuān)線進(jìn)行遷移同步，同時(shí)盡量保證原有自建機(jī)房數(shù)據(jù)完整，最好能夠數(shù)據(jù)雙向同步/或者數(shù)據(jù)雙寫(xiě)，方便極端異常情況下的業(yè)務(wù)回滾，至少保證能夠回滾后業(yè)務(wù)正常。
方案二：自建機(jī)房和云環(huán)境通過(guò)專(zhuān)線連接起來(lái)后，形成一個(gè)大內(nèi)網(wǎng)。將數(shù)據(jù)耦合度比較低的子業(yè)務(wù)單獨(dú)切換到云環(huán)境；對(duì)數(shù)據(jù)耦合度比較高并且訪問(wèn)量/訪問(wèn)遲延要求高的子業(yè)務(wù)，需要都跟隨數(shù)據(jù)一起遷移。內(nèi)部業(yè)務(wù)系統(tǒng)逐漸遷移切換完成后再對(duì)入口進(jìn)行整體切換。
2個(gè)方案均能實(shí)現(xiàn)業(yè)務(wù)無(wú)中斷，同時(shí)各有優(yōu)缺點(diǎn)，方案一需要額外開(kāi)發(fā)少部分?jǐn)?shù)據(jù)同步/恢復(fù)工具，前期準(zhǔn)備工作充分的情況下，可以比較簡(jiǎn)單快速的切換；方案二不需要開(kāi)發(fā)額外工具，但是需要操作的模塊多，操作時(shí)間長(zhǎng)，切換相對(duì)復(fù)雜，容易出現(xiàn)差錯(cuò)；綜合考慮下選擇了方案一，盡量保證切換過(guò)程簡(jiǎn)單無(wú)差錯(cuò)。
自建機(jī)房和云環(huán)境拉通專(zhuān)線進(jìn)行數(shù)據(jù)同步，從業(yè)務(wù)層面來(lái)說(shuō)，兩個(gè)機(jī)房各自承載全部的業(yè)務(wù)數(shù)據(jù)，為了方便故障回滾，各個(gè)數(shù)據(jù)項(xiàng)盡可能的保持雙向同步，保持?jǐn)?shù)據(jù)最終一致性即可；兩個(gè)環(huán)境的推送業(yè)務(wù)是相互獨(dú)立的，先保證全量數(shù)據(jù)同步到云環(huán)境，以Appkey為單位進(jìn)行流量遷移，將Appkey的流量遷移到云環(huán)境，遷移期間各自承擔(dān)一部Appkey的推送業(yè)務(wù)，最終將全部流量遷移到云環(huán)境。
為了快速遷移，采用1:1對(duì)等資源部署的方式即云環(huán)境部署一套和自建機(jī)房同等資源的系統(tǒng)，涉及業(yè)務(wù)模塊、存儲(chǔ)集群、依賴組件、監(jiān)控體系等。同時(shí)新建另一套內(nèi)部域名跟原有域名作區(qū)分，對(duì)外域名不進(jìn)行變更，在遷移的最后階段再進(jìn)行變更切換。
在系統(tǒng)入口的部署做了特殊的處理：
● API入口 - 部署同等規(guī)模的API服務(wù)器以及前端Nginx，由于對(duì)外域名只有一套，只能在自建機(jī)房和云環(huán)境做二選一，請(qǐng)求流量都進(jìn)入到自建機(jī)房，在Nginx的Lua代碼中判斷請(qǐng)求信息，根據(jù)Appkey歸屬信息決定是否轉(zhuǎn)發(fā)到云環(huán)境；同時(shí)新建備用域名指向云環(huán)境的入口以備異常情況使用。
● SDK接入網(wǎng)關(guān)入口 - 接入網(wǎng)關(guān)分成2個(gè)集群，各自服務(wù)自建機(jī)房和云環(huán)境，同時(shí)接收另一個(gè)機(jī)房的下行數(shù)據(jù)；SDK先連接到調(diào)度服務(wù)，根據(jù)Appkey歸屬信息分配到相應(yīng)的接入網(wǎng)關(guān)集群，同時(shí)調(diào)度服務(wù)跟自建機(jī)房互通，最后再遷移到云環(huán)境。
為了快速部署，并且避免遺漏某些業(yè)務(wù)模塊或者組件缺失，也為了避免配置錯(cuò)誤，我們整理了所有的機(jī)器列表以及相關(guān)信息例如IP，將自建機(jī)房的機(jī)器信息和云環(huán)境的機(jī)器信息一一對(duì)應(yīng)起來(lái)，當(dāng)然還包括域名信息也進(jìn)行一一對(duì)應(yīng)，在部署的時(shí)候?qū)χ@些信息進(jìn)行配置和部署。
推送業(yè)務(wù)的數(shù)據(jù)存儲(chǔ)涉及ES、CouchBase、Redis、PIKA、MySQL，需要把全部存量數(shù)據(jù)同步到云環(huán)境，同時(shí)建立實(shí)時(shí)同步通道進(jìn)行同步增量數(shù)據(jù)，保證云環(huán)境的數(shù)據(jù)最終一致性。
數(shù)據(jù)同步方式為組件工具同步、業(yè)務(wù)雙向同步，確保遷移整個(gè)過(guò)程數(shù)據(jù)在2個(gè)機(jī)房的完整性和最終一致性。專(zhuān)線的拉通，使得2個(gè)機(jī)房之間RTT為2-3ms，為數(shù)據(jù)全量遷移和增量同步提供了非常強(qiáng)的支撐。
根據(jù)各存儲(chǔ)組件，我們先預(yù)研了通用的遷移方案：
● ES同步方式1：云環(huán)境新建集群，拷貝源集群的數(shù)據(jù)文件到新集群，完成存量數(shù)據(jù)的遷移；增量數(shù)據(jù)由程序?qū)懭耄从蓸I(yè)務(wù)實(shí)現(xiàn)數(shù)據(jù)在2個(gè)集群的雙寫(xiě)）；使用腳本工具補(bǔ)充切換窗口的數(shù)據(jù)。
● ES同步方式2：新增云環(huán)境節(jié)點(diǎn)加入到集群，逐步剔除自建機(jī)房節(jié)點(diǎn)，即云環(huán)境和自建機(jī)房當(dāng)成同一個(gè)內(nèi)網(wǎng)，簡(jiǎn)稱(chēng)大內(nèi)網(wǎng)模式。
● CouchBase同步方式1：使用自帶集群同步工具XDCR進(jìn)行同步。
● CouchBase同步方式2：存量數(shù)據(jù)使用業(yè)務(wù)工具導(dǎo)入，增量數(shù)據(jù)由程序?qū)懭耄从蓸I(yè)務(wù)實(shí)現(xiàn)數(shù)據(jù)在2個(gè)集群的雙寫(xiě)）。
● CouchBase同步方式3：大內(nèi)網(wǎng)模式。
● Redis同步方式1：存量數(shù)據(jù)使用redis-shake或者主從同步，增量數(shù)據(jù)由程序?qū)懭耄从蓸I(yè)務(wù)實(shí)現(xiàn)數(shù)據(jù)在2個(gè)集群的雙寫(xiě)）。
● Redis同步方式2：存量數(shù)據(jù)使用業(yè)務(wù)工具導(dǎo)入，增量數(shù)據(jù)由程序?qū)懭耄从蓸I(yè)務(wù)實(shí)現(xiàn)數(shù)據(jù)在2個(gè)集群的雙寫(xiě)）。
● PIKA同步方式1：存量數(shù)據(jù)使用主從同步，增量數(shù)據(jù)由程序?qū)懭耄从蓸I(yè)務(wù)實(shí)現(xiàn)數(shù)據(jù)在2個(gè)集群的雙寫(xiě)）。
● PIKA同步方式2：存量數(shù)據(jù)使用業(yè)務(wù)工具導(dǎo)入，增量數(shù)據(jù)由程序?qū)懭耄从蓸I(yè)務(wù)實(shí)現(xiàn)數(shù)據(jù)在2個(gè)集群的雙寫(xiě)）。
● MySQL同步方式1：存量數(shù)據(jù)使用主從同步，增量數(shù)據(jù)由程序?qū)懭耄从蓸I(yè)務(wù)實(shí)現(xiàn)數(shù)據(jù)在2個(gè)集群的雙寫(xiě)）。
● MySQL同步方式2：雙主復(fù)制
以上為幾種通用的遷移方式，但是每個(gè)數(shù)據(jù)集群實(shí)例的特性不一樣，從業(yè)務(wù)依賴程度、數(shù)據(jù)量、讀請(qǐng)求量、寫(xiě)請(qǐng)求量幾個(gè)維度評(píng)估，最終采取的遷移方案也不一樣，我們梳理了自建機(jī)房的所有數(shù)據(jù)集群實(shí)例列表，對(duì)存量數(shù)據(jù)遷移、增量數(shù)據(jù)同步、切換方式、數(shù)據(jù)一致性需要的時(shí)間、切換操作、數(shù)據(jù)驗(yàn)證等都做了詳細(xì)的評(píng)估和說(shuō)明。
測(cè)試分為功能測(cè)試和性能測(cè)試兩部分，這兩部分都使用我們自己的內(nèi)部賬號(hào)進(jìn)行測(cè)試，先進(jìn)行功能測(cè)試，在功能都完備的情況下再進(jìn)行壓力測(cè)試。
在平時(shí)的開(kāi)發(fā)過(guò)程中我們積累了大量的測(cè)試用例，覆蓋到了全功能和內(nèi)部細(xì)節(jié)，整理這些測(cè)試用例構(gòu)造測(cè)試數(shù)據(jù)并執(zhí)行，從而實(shí)現(xiàn)功能測(cè)試的目的。
對(duì)于壓力測(cè)試，原計(jì)劃的壓力測(cè)試方案是：
1.在壓力測(cè)試的過(guò)程中，切斷云環(huán)境寫(xiě)入數(shù)據(jù)機(jī)房以及自建機(jī)房的數(shù)據(jù)鏈路，避免測(cè)試數(shù)據(jù)污染線上系統(tǒng)。
2.執(zhí)行壓力測(cè)試，確認(rèn)壓力測(cè)試的結(jié)果滿足要求。
3.清理云環(huán)境由于測(cè)試過(guò)程導(dǎo)致的臟數(shù)據(jù)。
4.恢復(fù)第一步被切斷的數(shù)據(jù)鏈路。
5.重新進(jìn)行相關(guān)數(shù)據(jù)的數(shù)據(jù)同步。
6.由于第四步和第五步造成了數(shù)據(jù)和系統(tǒng)的變更，需要再次進(jìn)行功能測(cè)試。
這個(gè)方案比較復(fù)雜，并且執(zhí)行時(shí)間會(huì)比較長(zhǎng)，特別是數(shù)據(jù)同步消耗比較多的時(shí)間，因此我們根據(jù)業(yè)務(wù)特性重新調(diào)整了壓力測(cè)試的方案。測(cè)試以Appkey為單位，并且系統(tǒng)中各個(gè)Appkey是相互獨(dú)立的，基于測(cè)試Appkey進(jìn)行測(cè)試產(chǎn)生的測(cè)試結(jié)果數(shù)據(jù)僅屬于Appkey本身，并且只對(duì)系統(tǒng)的整體運(yùn)營(yíng)數(shù)據(jù)有影響；測(cè)試Appkey也當(dāng)做正常的Appkey存在在系統(tǒng)中，相關(guān)數(shù)據(jù)也不需要進(jìn)行清理，后續(xù)如果有需要可以繼續(xù)使用這些測(cè)試Appkey。因此決定在功能測(cè)試之后，構(gòu)造壓力測(cè)試數(shù)據(jù)，然后直接進(jìn)行測(cè)試，并且對(duì)整體運(yùn)營(yíng)數(shù)據(jù)做清洗過(guò)濾。壓力測(cè)試場(chǎng)景和測(cè)試用例由業(yè)務(wù)團(tuán)隊(duì)和測(cè)試團(tuán)隊(duì)根據(jù)業(yè)務(wù)特征和系統(tǒng)特性來(lái)構(gòu)造，覆蓋所有的核心功能和核心模塊，壓測(cè)結(jié)果數(shù)據(jù)至少不低于當(dāng)前業(yè)務(wù)的峰值。
整個(gè)測(cè)試在存量數(shù)據(jù)同步完成并持續(xù)同步增量數(shù)據(jù)之后進(jìn)行，主要是考慮在做壓力測(cè)試的時(shí)候存儲(chǔ)集群有等量的數(shù)據(jù)量才能使壓測(cè)結(jié)果更加接近原有系統(tǒng)。
在功能完備、數(shù)據(jù)完整的情況下，遷移操作非常簡(jiǎn)單，執(zhí)行腳本，修改Appkey歸屬信息就可以了，具體內(nèi)部邏輯如下：
● 修改Appkey歸屬信息。
● 在API請(qǐng)求入口判斷Appkey的信息，將流量轉(zhuǎn)發(fā)到云環(huán)境的入口，后續(xù)所有流程都在云環(huán)境執(zhí)行。
● 調(diào)度服務(wù)器獲取Appkey歸屬信息，SDK新的請(qǐng)求返回新的接入網(wǎng)關(guān)集群信息，連接到正確的接入網(wǎng)關(guān)服務(wù)器。
● 調(diào)度服務(wù)器通知接入網(wǎng)關(guān)服務(wù)器斷開(kāi)不屬于該集群的Appkey SDK鏈接。
● API入口和接入網(wǎng)關(guān)入口變更有個(gè)時(shí)間差，2個(gè)機(jī)房的業(yè)務(wù)邏輯都能夠完整執(zhí)行，并且有數(shù)據(jù)同步，不管是SDK連接到哪個(gè)接入網(wǎng)關(guān)集群，都能夠接收相關(guān)數(shù)據(jù)。
執(zhí)行遷移操作后，需要進(jìn)行驗(yàn)證，包括但不限于以下部分：
● 基礎(chǔ)監(jiān)控是否正常（網(wǎng)絡(luò)/CPU/內(nèi)存/磁盤(pán)等）
● Prometheus業(yè)務(wù)監(jiān)控是否正常
● 推送業(yè)務(wù)運(yùn)營(yíng)數(shù)據(jù)是否正常
整個(gè)推送業(yè)務(wù)體量非常大，很難一次性全部切換，為了保證遷移過(guò)程有序穩(wěn)定的進(jìn)行，我們按照一定的策略和遷移比例制定遷移計(jì)劃，分批次逐步遷移整個(gè)系統(tǒng)，每批次操作完成后都進(jìn)行驗(yàn)證和觀察一定的時(shí)間。優(yōu)先測(cè)試賬號(hào)并進(jìn)行回滾驗(yàn)證，其次是非VIP，最后是VIP。
整個(gè)遷移過(guò)程，我們建立了實(shí)施過(guò)程跟蹤，每天跟進(jìn)當(dāng)前的進(jìn)度，下一計(jì)劃步驟的工作任務(wù)，有哪些依賴工作，當(dāng)前有哪些風(fēng)險(xiǎn)并且由誰(shuí)來(lái)跟進(jìn)解決等等，盡量確保遷移工作計(jì)劃持續(xù)有序的執(zhí)行。
盡管我們做了詳細(xì)的方案，在實(shí)施過(guò)程中難免會(huì)碰到一些問(wèn)題，我們盡量快速分析定位問(wèn)題，直接解決問(wèn)題或者方案微調(diào)，在風(fēng)險(xiǎn)可控的范圍內(nèi)解決問(wèn)題，這里摘選幾個(gè)問(wèn)題陳述一下：
● 有一個(gè)CouchBase Bucket實(shí)例在實(shí)施過(guò)程中發(fā)現(xiàn)有分鐘級(jí)別的數(shù)據(jù)不一致。經(jīng)過(guò)分析發(fā)現(xiàn)不一致的數(shù)據(jù)都有主動(dòng)刪除的操作，CouchBase在刪除時(shí)并不是真正的刪除，僅僅是標(biāo)記為刪除，然后在后端線程異步執(zhí)行數(shù)據(jù)刪除。CouchBase采用XDCR進(jìn)行跨集群數(shù)據(jù)同步，可能是在數(shù)據(jù)同步過(guò)程中，刪除操作未能及時(shí)同步?？紤]到該實(shí)例的數(shù)據(jù)訪問(wèn)量級(jí)并不大，跨專(zhuān)線的訪問(wèn)時(shí)延并不影響到業(yè)務(wù)，因此進(jìn)行方案的調(diào)整，僅保留云上的實(shí)例，自建機(jī)房和云上的系統(tǒng)共同訪問(wèn)。
● 有一個(gè)Redis實(shí)例偶爾出現(xiàn)CPU負(fù)載增高的情況，自建機(jī)房的實(shí)例觀察正常。在此期間Redis沒(méi)有進(jìn)行數(shù)據(jù)備份，業(yè)務(wù)訪問(wèn)量也相對(duì)平穩(wěn)，虛擬機(jī)并未受到同臺(tái)物理機(jī)的其他虛擬機(jī)的影響；分析日志發(fā)現(xiàn)CPU負(fù)載增高時(shí)，Redis有內(nèi)存碎片清理的動(dòng)作，比對(duì)相關(guān)的配置發(fā)現(xiàn)配置不一樣。懷疑內(nèi)存碎片清理消耗過(guò)多CPU，經(jīng)過(guò)調(diào)整Redis配置，該情況不再出現(xiàn)。
● 業(yè)務(wù)操作MySQL時(shí)偶爾出現(xiàn)遲延增加甚至超時(shí)。通過(guò)監(jiān)控發(fā)現(xiàn)期間有業(yè)務(wù)突增，但是業(yè)務(wù)量屬于正常范圍內(nèi)，并且自建機(jī)房的MySQL訪問(wèn)正常；虛擬機(jī)/物理機(jī)負(fù)載正常，業(yè)務(wù)機(jī)器/MySQL機(jī)器的網(wǎng)絡(luò)IO/磁盤(pán)IO均正常，MySQL各項(xiàng)數(shù)據(jù)也正常；再細(xì)看業(yè)務(wù)機(jī)器的基礎(chǔ)監(jiān)控發(fā)現(xiàn)網(wǎng)絡(luò)丟包重傳相對(duì)增加，懷疑網(wǎng)絡(luò)鏈路有異常，經(jīng)過(guò)華為云團(tuán)隊(duì)排查發(fā)現(xiàn)網(wǎng)絡(luò)設(shè)備的光模塊異常。更換光模塊后業(yè)務(wù)恢復(fù)正常，該情況不再出現(xiàn)。
上云后的規(guī)劃
上云不是終點(diǎn)，而是另一個(gè)起點(diǎn)。雖然已經(jīng)將業(yè)務(wù)遷移上云完成，但是依然有很多工作需要做。云廠商提供了穩(wěn)健的IaaS層，也提供了很多PaaS層服務(wù)，充分利用云資源的優(yōu)勢(shì)，擁抱云原生，持續(xù)演進(jìn)優(yōu)化我們的架構(gòu)，為我們的客戶通過(guò)更加優(yōu)質(zhì)的服務(wù)。以下是上云后的一些工作：
熱門(mén)文章
開(kāi)發(fā)者必看：2025最高效的推送圖標(biāo)配置指南
2025-07-16
低延遲音頻深度解析：GPTBots 技術(shù)方案
2025-07-14
構(gòu)建AI賦能的代碼編輯器：GPTBots與Monaco強(qiáng)強(qiáng)聯(lián)合
2025-07-08
EngageLab深度解析：AI 驅(qū)動(dòng)的全渠道營(yíng)銷(xiāo)自動(dòng)化如何賦能業(yè)務(wù)高速增長(zhǎng)
2025-06-25
GPTBots使用fetch-event-source實(shí)現(xiàn)SSE POST傳參
2025-06-23
相關(guān)文章
極光官方微信公眾號(hào)
關(guān)注我們，即時(shí)獲取最新極光資訊
現(xiàn)在注冊(cè)，領(lǐng)取新人大禮包
