狠狠色噜噜狠狠狠狠2021,久久精品国产亚洲av麻豆白洁,777米奇影视盒,国内精品老年人视频网站

十億人都在用的健康碼,運(yùn)維體系是怎么設(shè)計的?(十億人都在用的健康碼,運(yùn)維體系是怎么設(shè)計的)

導(dǎo)讀|隨著疫情防控模式的迭代,健康碼訪問DAU逐漸趨于下跌,意味著健康碼將逐步完成歷史使命,見證著疫情的結(jié)束。本文特邀騰訊研發(fā)工程師李雄政將從技術(shù)架構(gòu)、可觀測體系、運(yùn)營保障體系等運(yùn)維體系多方面,總結(jié)回顧健康碼業(yè)務(wù)運(yùn)營過程中的保障技術(shù)手段。

十億人都在用的健康碼,運(yùn)維體系是怎么設(shè)計的?(十億人都在用的健康碼,運(yùn)維體系是怎么設(shè)計的)

業(yè)務(wù)背景

疫情三年,奧密克戎已是強(qiáng)弩之末,疫情終將過去。歷經(jīng)數(shù)個階段的迭代,騰訊健康碼產(chǎn)品服務(wù)于十余個省份的居民,數(shù)億用戶、數(shù)百億次亮碼。有效助力保障公共衛(wèi)生安全。全國健康碼共累計PV2k多億,亮碼1k多億,最大省份的健康碼用戶量超過1億,DAU過千萬。

隨著疫情防控模式的迭代,健康碼訪問DAU逐漸趨于下跌,意味著健康碼將逐步完成歷史使命,淡出歷史舞臺。本文就曾經(jīng)在健康碼業(yè)務(wù)運(yùn)營過程中的保障技術(shù)手段進(jìn)行了回顧,歡迎有興趣的讀者在評論區(qū)一起探討。

十億人都在用的健康碼,運(yùn)維體系是怎么設(shè)計的?(十億人都在用的健康碼,運(yùn)維體系是怎么設(shè)計的)

技術(shù)架構(gòu)體系

一個穩(wěn)定的架構(gòu)是設(shè)計與運(yùn)維出來的,為了達(dá)到穩(wěn)態(tài)運(yùn)行,設(shè)計上考慮了以下幾個方面:

1)選用合適的云原生產(chǎn)品

健康碼本身是要求高可用、高并發(fā)的應(yīng)用,為了滿足業(yè)務(wù)穩(wěn)定上線、快速上線的需求,我們采用了騰訊云的公有云/私有化產(chǎn)品解決方案。以下是健康碼上線時碰到的幾大類問題:

  • 帶寬容量問題

由于系統(tǒng)需要大容量的承載能力,導(dǎo)致地方政務(wù)云資源供給能力不足。表現(xiàn)如公網(wǎng)出口防護(hù)能力不足(如經(jīng)常性面對境外DDOS攻擊/CC攻擊),IDC出口設(shè)備每秒新建連接數(shù)不夠等。我們采用了DDoS高防包/Waf/ecdn等方案來滿足。DDoS高防包與Waf產(chǎn)品有效抵擋住境內(nèi)外的DDoS攻擊、Web攻擊、入侵、漏洞利用、掛馬、篡改、后門、爬蟲等網(wǎng)站及 Web 業(yè)務(wù)安全防護(hù)問題;ECDN產(chǎn)品通過靜態(tài)資源緩存有效降低混合云場景下政務(wù)云入口新建連接數(shù)、帶寬。也提升了用戶的訪問體驗(yàn)。

  1. 開發(fā)及部署效率問題

疫情的需求迭代較快,如果從頭開始開發(fā)產(chǎn)品,時間上不允許。騰訊云TCB產(chǎn)品做為一站式云原生解決方案,更加貼近小程序/Web 應(yīng)用開發(fā)場景,使開發(fā)人員能快速構(gòu)建完整項(xiàng)目、針對場景快速優(yōu)化定制且集中管理,各產(chǎn)品間無需耗費(fèi)時間精力分別配置與打通,無需切換多款云產(chǎn)品的控制臺進(jìn)行使用。

  • 云資源成本問題

云產(chǎn)品擁有較大的共享資源冗余,能夠快速達(dá)成大容量,同時深度采用云原生產(chǎn)品,能夠帶來較大程度的成本節(jié)約。例如采用scf云函數(shù),無需在購買云服務(wù)器的情況下運(yùn)行代碼,使用騰訊云的能力彈性、安全地運(yùn)行代碼。無需冗余資源閑時運(yùn)行成本買單,同時因?yàn)樵圃a(chǎn)品具有天然的跨可用區(qū)容災(zāi)能力,基于云原生的兩地三中心架構(gòu)設(shè)計,基于騰訊云公有云通常可以滿足的高可用能力如:從負(fù)載層采用CLB的跨可用區(qū)高可用能力進(jìn)行可用區(qū)容錯;應(yīng)用層TSF/TKE/CKAFKA的多可用區(qū)高可用能力容錯;存儲層采用TDSQL多可用區(qū)部署及主從同步能力滿足高可用與容災(zāi)。

2)立體化監(jiān)控體系設(shè)計

完整的監(jiān)控體系,對提升系統(tǒng)SLA有非常重要的作用。一方面監(jiān)控系統(tǒng)具有提前業(yè)務(wù)事件預(yù)警能力。最有效的監(jiān)控體系能在業(yè)務(wù)發(fā)生故障前有效預(yù)警,從而知會SRE提前介入處置,防止事件擴(kuò)大成故障,從而降低高故障數(shù)量。另一方面在發(fā)生故障后,能夠評估故障影響程度、有效追蹤異常點(diǎn),引導(dǎo)技術(shù)人員介入處置,提升系統(tǒng)故障恢復(fù)SLA。

3)系統(tǒng)壓力測試、混沌工程、應(yīng)急預(yù)案等多方面檢驗(yàn)

隨著業(yè)務(wù)系統(tǒng)逐漸趨于成熟,要保障常規(guī)運(yùn)行過程中的穩(wěn)定性, 需要周期性保持對系統(tǒng)的應(yīng)急演練工作。一方面通過壓力測試、破懷性測試來檢驗(yàn)系統(tǒng)的承受能力。另一方面通過這些演練來檢驗(yàn)運(yùn)維人員團(tuán)隊(duì)在面對業(yè)務(wù)事件時的響應(yīng)質(zhì)量、處置預(yù)案是否成熟與合規(guī)。

十億人都在用的健康碼,運(yùn)維體系是怎么設(shè)計的?(十億人都在用的健康碼,運(yùn)維體系是怎么設(shè)計的)

可觀測體系

可觀測能力做為基礎(chǔ)技術(shù)能力,在健康碼運(yùn)維中是不可缺少的一部分。優(yōu)秀的可觀測體系能夠幫助業(yè)務(wù)及時、準(zhǔn)確地發(fā)現(xiàn)故障,亦能在故障診斷過程中追根溯源,及時協(xié)助問題定位、從而加速故障恢復(fù)。

健康碼產(chǎn)品基于騰訊云PAAS產(chǎn)品構(gòu)建,系統(tǒng)的可觀測點(diǎn)一般可基于以下能力構(gòu)建:首先,采用了騰訊云waf/ 騰訊智能網(wǎng)關(guān)/騰訊云tke等做為基礎(chǔ)組件。這些組件都能夠輸出標(biāo)準(zhǔn)化日志,我們對日志進(jìn)行清洗、匯聚,從而可獲得各種可觀測的metrics。其次,前端埋點(diǎn)。有助于監(jiān)控前端用戶體驗(yàn),發(fā)現(xiàn)資源加載慢、API接口超時、成功率低等問題。最后,組件自身的監(jiān)控系統(tǒng),采用公有云API、 telegraf input、 prometheus exporter等方式對組件自身的健康情況做好監(jiān)控。

十億人都在用的健康碼,運(yùn)維體系是怎么設(shè)計的?(十億人都在用的健康碼,運(yùn)維體系是怎么設(shè)計的)十億人都在用的健康碼,運(yùn)維體系是怎么設(shè)計的?(十億人都在用的健康碼,運(yùn)維體系是怎么設(shè)計的)

1)基礎(chǔ)組件可觀測

對于基礎(chǔ)組件來說,我們需要知道各組件的運(yùn)行狀態(tài)、容量性能情況等?;A(chǔ)組件可觀測選型較多,相對私有云來說,公有云具有較好的可觀測生態(tài)。以騰訊云為例,公有云除了提供較好的dashboard 與告警能力外, 基于API V3構(gòu)建的開源生態(tài)亦比較豐富,可使用grafana plugin 和prometheus qcloud exporter進(jìn)行觀測,方便與prometheus / grafana 進(jìn)行集成對接。

十億人都在用的健康碼,運(yùn)維體系是怎么設(shè)計的?(十億人都在用的健康碼,運(yùn)維體系是怎么設(shè)計的)十億人都在用的健康碼,運(yùn)維體系是怎么設(shè)計的?(十億人都在用的健康碼,運(yùn)維體系是怎么設(shè)計的)

需要特別說明的是由于原生監(jiān)控指標(biāo)較少,服務(wù)器數(shù)量較多時,監(jiān)控原生api可能無法滿足高額拉取頻率要求,我們可以采用開源手段進(jìn)行監(jiān)控,比如自行部署 node exporter, 由prometheus 自行抓取與監(jiān)控。

2)業(yè)務(wù)指標(biāo)可觀測

根據(jù)業(yè)務(wù)指標(biāo)的重要程度,我們會針對關(guān)鍵指標(biāo)如亮碼、核酸、疫苗接口相關(guān)業(yè)務(wù)指標(biāo)進(jìn)行觀測。對各種接口監(jiān)控好,我們就可以有效保障系統(tǒng)整體質(zhì)量,監(jiān)控的指標(biāo)包括各接口業(yè)務(wù)量、成功率、平均耗時、95分位耗時等。

  • 業(yè)務(wù)量監(jiān)控

從Log中分解出相應(yīng)的URL,分時間/URL Count 數(shù)量即可獲得業(yè)務(wù)量 metrics, 業(yè)務(wù)量的監(jiān)控有閾值監(jiān)控、同環(huán)比、動態(tài)閾值監(jiān)控等。

  • 成功率監(jiān)控

成功率表示的是成功請求量占總請求量百分比,從Log中很容易區(qū)分出異常返回碼,從而計算出成功率。一般采用閾值監(jiān)控 。

  • 耗時監(jiān)控

耗時監(jiān)控表示的是業(yè)務(wù)整體耗時,每一筆耗時在日志中均有記載,可采用平均值或p95耗時監(jiān)控,一般采用閾值、無閾值監(jiān)控等方法進(jìn)行監(jiān)控。

常用的日志處理手段有ElasticSearch / 騰訊云CLS等。

3)用戶體驗(yàn)可觀測

  • 前端監(jiān)控

我們在健康碼項(xiàng)目中使用的監(jiān)控工具是騰訊云RUM監(jiān)控(Real User Monitoring), RUM監(jiān)控的便捷之處在于對業(yè)務(wù)代碼的侵入性較少,只需新增數(shù)行代碼。能夠監(jiān)控到前端JS錯誤、白屏、首屏打開速度、API成功率、API耗時等。

import Aegis from 'aegis-mp-sdk';const aegis = new Aegis({ id: "pGUVFTCZyewxxxxx", // 項(xiàng)目key uin: 'xxx', // 用戶唯一 ID(可選) reportApiSpeed: true, // 接口測速 spa: true, // 頁面切換的時候上報 pv});

代碼示例:RUM監(jiān)控接入方法及為簡單方便。

十億人都在用的健康碼,運(yùn)維體系是怎么設(shè)計的?(十億人都在用的健康碼,運(yùn)維體系是怎么設(shè)計的)

上圖是前端監(jiān)控數(shù)據(jù)總覽視圖,有助SRE第一時間了解整體用戶體驗(yàn)數(shù)據(jù)。

十億人都在用的健康碼,運(yùn)維體系是怎么設(shè)計的?(十億人都在用的健康碼,運(yùn)維體系是怎么設(shè)計的)

上圖是某健康碼業(yè)務(wù)前端調(diào)用后端API成功率。

API監(jiān)控功能有助于SRE了解后端API性能,在后端成功率、耗時(如95分位,平均耗時)有波動時,可以有效下鉆分析并聯(lián)合后端進(jìn)行排查。由于健康碼內(nèi)部引用了大量的外部接口,在實(shí)際應(yīng)用中,我們通常采用此方法第一時間發(fā)現(xiàn)第三方系統(tǒng)接口耗時波動,并及時聯(lián)系第三方接口后端進(jìn)行處理。

十億人都在用的健康碼,運(yùn)維體系是怎么設(shè)計的?(十億人都在用的健康碼,運(yùn)維體系是怎么設(shè)計的)

上圖是某健康碼業(yè)務(wù)前端錯誤。該視圖有助于SRE第一時間了解整體前端錯誤數(shù)據(jù),并有針對性對業(yè)務(wù)前后端應(yīng)用進(jìn)行優(yōu)化。

  • 用戶反饋監(jiān)控

在業(yè)務(wù)出現(xiàn)問題時,微信投訴入口或微博等媒體一般會有投訴產(chǎn)生,一旦產(chǎn)生某些關(guān)健字匯聚,可以及時介入處理,防止事態(tài)擴(kuò)大化。

4)業(yè)務(wù)撥測

我們可以模擬業(yè)務(wù)請求向業(yè)務(wù)后端接口發(fā)起撥測。撥測失?。o法連接、響應(yīng)超時、錯誤返回碼)可發(fā)出告警,這種探測手段也比較有效。騰訊云的撥測功能能有效從全球發(fā)起撥測請求,并生成撥測結(jié)果報表。

十億人都在用的健康碼,運(yùn)維體系是怎么設(shè)計的?(十億人都在用的健康碼,運(yùn)維體系是怎么設(shè)計的)

上圖是全國健康碼質(zhì)量撥測質(zhì)量視圖。

我們也可能在系統(tǒng)內(nèi)部建立起對第三方接口的撥測,達(dá)到自證清白的效果。低成本的撥測解決方案有 blackbox exporter等。

十億人都在用的健康碼,運(yùn)維體系是怎么設(shè)計的?(十億人都在用的健康碼,運(yùn)維體系是怎么設(shè)計的)

上圖是某健康碼業(yè)務(wù)的第三方接口撥測,有助于自證清白。

十億人都在用的健康碼,運(yùn)維體系是怎么設(shè)計的?(十億人都在用的健康碼,運(yùn)維體系是怎么設(shè)計的)

容量壓測

疫情往往會瞬時帶來比平日峰值數(shù)倍甚至數(shù)十倍的亮碼業(yè)務(wù)量,增長幅度較大,運(yùn)維團(tuán)隊(duì)一般無法即時進(jìn)行擴(kuò)容,所以在疫情增長趨勢較為明顯時,我們會預(yù)估業(yè)務(wù)量,并與業(yè)主溝通進(jìn)行擴(kuò)容,擴(kuò)容后完成性能壓測。

1)讀接口壓測

我們會從系統(tǒng)隨機(jī)抽取一部分用戶,向系統(tǒng)模擬數(shù)十倍峰值請求來進(jìn)行壓力測試。壓測的同時向第三方接口報備壓測流量,以免造成第三方系統(tǒng)損壞。

2)寫接口壓測

寫接口涉及到數(shù)據(jù)寫入到生產(chǎn)環(huán)境,所以一般采用兩種形式進(jìn)行壓測。一種是標(biāo)記數(shù)據(jù)壓測、比如采用一些模擬用戶ID 號段的用戶生成清求,壓測完成后采用刪除壓測數(shù)據(jù)的方式進(jìn)行清臟。另一種是壓測請求http頭內(nèi)攜帶壓測標(biāo)記,業(yè)務(wù)代碼內(nèi)對壓測請求特殊處理,旁路插入測試庫。

騰訊云壓測團(tuán)隊(duì)提供了一系列的壓測工具及服務(wù),有效助力每個健康碼業(yè)務(wù)疫情期容量保障。

3)壓測排障

壓測過程中碰到瓶頸常見于:單核跑滿——存在于某些應(yīng)用使用單核的情況,一般需要做業(yè)務(wù)改造,使系統(tǒng)運(yùn)行在多核;負(fù)載過高——如CPU過高,虛擬機(jī)包量超 10W等;防火墻等數(shù)通鏈路故障——防火墻可能會存在帶寬限制、新建會話數(shù)限制等 (不限于互聯(lián)網(wǎng)出口防火墻、區(qū)域間防火墻);PAAS能力限制——如redis單機(jī)版單核跑滿,連接數(shù)跑滿等;第三方接口延時過高——如第三方接口不能承壓等情況;某些私有云存在大量CPU超分。在壓測過程中發(fā)現(xiàn)并解決能力短板,從而使系統(tǒng)能達(dá)到理想的容量。

十億人都在用的健康碼,運(yùn)維體系是怎么設(shè)計的?(十億人都在用的健康碼,運(yùn)維體系是怎么設(shè)計的)

混沌工程與故障演練

十億人都在用的健康碼,運(yùn)維體系是怎么設(shè)計的?(十億人都在用的健康碼,運(yùn)維體系是怎么設(shè)計的)

上圖是健康碼混沌工程實(shí)踐。每個健康碼從新上線到成熟,產(chǎn)品與運(yùn)維團(tuán)隊(duì)都經(jīng)歷了組建至成熟的過程,通過故障演練,團(tuán)隊(duì)能快速找到產(chǎn)品架構(gòu)薄弱點(diǎn)、組織效率瓶頸點(diǎn),演習(xí)完成后可有針對性對演習(xí)中發(fā)現(xiàn)的問題進(jìn)行優(yōu)化,經(jīng)歷過多次演習(xí),架構(gòu)高可用能力與組織效率均能有所提高。

1)檢驗(yàn)服務(wù)的高可用性,如架構(gòu)無單點(diǎn),具備健康檢查、負(fù)載均衡等能力

通過關(guān)機(jī)、網(wǎng)卡禁用、實(shí)例調(diào)整等手段模擬故障,檢驗(yàn)在IaaS/PaaS出現(xiàn)故障時,業(yè)務(wù)是否會受到影響,業(yè)務(wù)能否自動切換,后端業(yè)務(wù)能否自動止損熔斷等。

2)檢驗(yàn)監(jiān)控覆蓋度和有效性,如基礎(chǔ)監(jiān)控、業(yè)務(wù)指標(biāo)監(jiān)控的覆蓋度和告警有效性

通過關(guān)機(jī)、網(wǎng)卡禁用、實(shí)例調(diào)整等手段模擬故障,檢驗(yàn)基礎(chǔ)監(jiān)控手段能否及時發(fā)現(xiàn)問題,業(yè)務(wù)監(jiān)控手段能否及時發(fā)現(xiàn)業(yè)務(wù)抖動,告警能否觸達(dá)到相關(guān)的運(yùn)維人員。

3)檢驗(yàn)應(yīng)急預(yù)案的有效性,如擴(kuò)縮容預(yù)案,限流預(yù)案等

以壓力測試為輔助,檢驗(yàn)壓力條件下,能否快速成功擴(kuò)充容量,能否快速啟動對業(yè)務(wù)限流。

4)提前發(fā)現(xiàn)服務(wù)穩(wěn)定性隱患并推動消除隱患,建立故障快速發(fā)現(xiàn)和快速止損的能力

在某些特定的業(yè)務(wù)耗時增加、錯誤率增加時,能夠快速啟動預(yù)案介入,快速恢復(fù)業(yè)務(wù)成功率及耗時。

十億人都在用的健康碼,運(yùn)維體系是怎么設(shè)計的?(十億人都在用的健康碼,運(yùn)維體系是怎么設(shè)計的)

業(yè)務(wù)架構(gòu)優(yōu)化與業(yè)務(wù)柔性

優(yōu)秀的架構(gòu)需要具有自保護(hù)能力與對后端應(yīng)用的保護(hù)能力。常見的保護(hù)能力如:

某些高并發(fā)寫請求入庫前增加隊(duì)列以增加瞬時吞吐能力。如高峰期掃場所碼,掃場所碼信息入庫實(shí)時性要求并不強(qiáng),采用騰訊云ckafka等組件進(jìn)行業(yè)務(wù)削峰。

在應(yīng)用加入適當(dāng)時長(如:5分鐘)的緩存,用戶短時間調(diào)用該數(shù)據(jù)時走緩存,以減少對后端、第三方接口的請求。該緩存可以加在前端(如Localstorage)或 后端(采用redis或hash到有狀態(tài)服務(wù)的本地內(nèi)存)。

在后端或第三方接口故障時,由于用戶會不斷重試而瞬時增加大量請求,甚至導(dǎo)致后端雪崩,這時就有必要在前端增加限制重試的邏輯。比如有些小程序設(shè)計在用戶請求出錯后,會要求用戶重登陸, 但如果對該登陸請求沒有限制,必然會導(dǎo)致請求量過大而后臺雪崩。我們建議在前端加上限頻措施。以下是常見的前端設(shè)計:

十億人都在用的健康碼,運(yùn)維體系是怎么設(shè)計的?(十億人都在用的健康碼,運(yùn)維體系是怎么設(shè)計的)

后端在網(wǎng)關(guān)等層面限流,只允許承載能力內(nèi)的請求進(jìn)行后端。通過壓測對系統(tǒng)承載能力摸底,從而在接入網(wǎng)關(guān)進(jìn)行限流。我們采用騰訊云智能網(wǎng)關(guān)(騰訊云公有云API網(wǎng)關(guān)有同樣的能力)限流??梢詫笈_起到相應(yīng)的保護(hù)作用。

第三方接口耗時太長,產(chǎn)生大量TCP連接而耗盡系統(tǒng)資源,此時會要求后端具有快速失敗的能力,不再長時間等待第三方接口返回。

十億人都在用的健康碼,運(yùn)維體系是怎么設(shè)計的?(十億人都在用的健康碼,運(yùn)維體系是怎么設(shè)計的)

上圖是健康碼系統(tǒng)分層部署及各層對后端的保護(hù)能力。以上保護(hù)手段在每個項(xiàng)目中的實(shí)現(xiàn)策略均有所差異。因?yàn)樯婕暗接脩趔w驗(yàn),需要與業(yè)主充分討論后執(zhí)行。

十億人都在用的健康碼,運(yùn)維體系是怎么設(shè)計的?(十億人都在用的健康碼,運(yùn)維體系是怎么設(shè)計的)

變更控制

業(yè)務(wù)上線后,需要持續(xù)保持業(yè)務(wù)穩(wěn)定運(yùn)行,變更控制尤其重要,現(xiàn)網(wǎng)變更均需要提出變更請求,每一個變更請求需要進(jìn)行技術(shù)嚴(yán)格評審后,經(jīng)客戶、管理授權(quán)后方能在現(xiàn)網(wǎng)實(shí)施。

我們特別使用騰訊云coding承載變更工作流,變更工作在平臺中實(shí)現(xiàn)閉環(huán)。一個合格的變更請求至少要包含變更目的、實(shí)施過程、驗(yàn)證方案、回退方案等。ITIL 的 change management中均有規(guī)范,此處不再詳述。變更時盡量遵循灰度發(fā)布,防止變更中產(chǎn)生較大影響面的問題。

以上是從技術(shù)架構(gòu)、可觀測體系、運(yùn)營保障體系等運(yùn)維體系各方面總結(jié)出來的、保障健康碼過程中的心得,希望能給大家一些借鑒和參考。整體來說,技術(shù)架構(gòu)上,基礎(chǔ)資源盡量采用云原生產(chǎn)品,滿足大容量、可伸縮、高可用的基礎(chǔ)資源能力。可觀測體系上,要采用云原生產(chǎn)品構(gòu)建業(yè)務(wù)前端、后端一體化觀測體系,保障業(yè)務(wù)可用性。運(yùn)營保障體系上,好的系統(tǒng)運(yùn)維是設(shè)計出來的, 一方面加強(qiáng)業(yè)務(wù)技術(shù)架構(gòu)設(shè)計,可層可對后端提供保護(hù),通過限流、邏輯熔斷等手段使業(yè)務(wù)架構(gòu)具有容錯能力;另一方面平時要不斷通過混沌工程演習(xí)手段,檢驗(yàn)系統(tǒng)容量及高可用能力,保障團(tuán)隊(duì)能夠及時響應(yīng),專業(yè)響應(yīng)。

當(dāng)然我們碰到的業(yè)務(wù)場景有限,為了滿足業(yè)務(wù)快速上線,歷史上所采用的的一些技術(shù)實(shí)踐也不一定是最優(yōu)的。當(dāng)前云產(chǎn)品發(fā)展日新月異,已經(jīng)產(chǎn)生了更好的產(chǎn)品解決方案,期待大家在評論區(qū)一起發(fā)掘討論。

作者:李雄政

來源:微信公眾號:騰訊云開發(fā)者

出處:https://mp.weixin.qq.com/s/AV_WQlHoAfotor6iVT1-Kw

版權(quán)聲明:本文內(nèi)容由互聯(lián)網(wǎng)用戶自發(fā)貢獻(xiàn),該文觀點(diǎn)僅代表作者本人。本站僅提供信息存儲空間服務(wù),不擁有所有權(quán),不承擔(dān)相關(guān)法律責(zé)任。如發(fā)現(xiàn)本站有涉嫌抄襲侵權(quán)/違法違規(guī)的內(nèi)容, 請發(fā)送郵件至 舉報,一經(jīng)查實(shí),本站將立刻刪除。

(0)
上一篇 2023年3月21日 上午10:20
下一篇 2023年3月21日 上午10:36

相關(guān)推薦