當前位置：首頁 > 科技 > 軟件

繼續聊聊云平臺運維規范

來源：責編：時間：2023-09-28 10:04:55 286觀看

導讀4.5 云平臺監控體系云平臺監控體系主要依托于云平臺自身所提供的一套全面的云計算監控解決方案，可以幫助企業和個人對云端資源進行實時監控和管理。該監控體系由以下三個部分組成：基礎監控：云平臺提供了一套全面的基礎監

4.5 云平臺監控體系

云平臺監控體系主要依托于云平臺自身所提供的一套全面的云計算監控解決方案，可以幫助企業和個人對云端資源進行實時監控和管理。該監控體系由以下三個部分組成：

基礎監控：云平臺提供了一套全面的基礎監控服務，覆蓋了云計算資源的 CPU 使用率、網絡流量、磁盤 I/O、負載均衡等多個指標，可以幫助用戶實時了解云資源的狀態，及時發現和解決問題。

應用監控：云平臺還提供了一套應用監控服務，可以幫助用戶對應用程序進行監控和診斷。該服務可以監控應用程序的性能、錯誤、日志等多個指標，并提供了豐富的分析和報告工具，幫助用戶快速定位和解決問題。

業務監控：云平臺還提供了一套業務監控服務，可以幫助用戶對業務進行監控和管理。該服務可以監控業務的關鍵指標，例如用戶活躍度、訂單量、交易額等，同時還可以支持自定義指標和報警規則，幫助用戶及時發現和解決業務問題。

總體來說，云平臺的監控體系是一個非常全面和強大的監控解決方案，可以幫助用戶全面了解云資源的狀態，及時發現和解決問題，提高系統的穩定性和可靠性。其中基礎監控是所有系統所必備的監控要求，在此之上可以根據業務系統的實際情況來考慮應用監控與業務監控的進一步拓展，故本文檔將主要圍繞基礎監控展開。

4.5.1 監控對象

云平臺監控體系的主要監控對象包括云服務器、云數據庫、云存儲、云網絡、云安全等方面。這些對象的監控可以幫助云平臺管理員及時發現潛在的問題，做出相應的處理措施，保障云平臺的穩定運行。

目前云平臺所涉及的監控對象主要包括但不限于：云服務器、云數據庫、對象存儲、云數據庫MongoDB、云數據庫Redis、云數據庫PostgreSQL、Elasticsearch集群、負載均衡等。

4.5.2 監控工具

云平臺提供了多個監控工具，以幫助用戶對阿里云服務進行監控和管理，常用的監控工具包括：

云監控：可以監控云服務器、云數據庫、云存儲、負載均衡、函數計算、消息服務MQ、容器服務等云服務的運行狀態和性能指標，并支持自定義監控指標和自定義報警規則。

日志服務：可以收集和分析云服務器、容器、Web應用程序等多個應用程序的日志，以便進行故障排查和性能分析。

云審計：可以對云賬號的操作進行審計和監控，并提供實時告警和日志查詢功能，以保障賬號安全和合規性。

除了上述云平臺所自帶的監控工具意外，還可以輔助使用zabbix、prometheus等監控工具來幫助進行平臺所無法實現的指標監控。

4.5.3 監控內容

云平臺監控體系的監控內容包括但不限于：資源狀態監控、系統性能監控、日志監控、安全監控、用戶行為監控等。這些內容可以全面地反映云平臺的運行狀態，幫助管理員及時發現異常情況，提升云平臺的安全性和穩定性。

具體監控項如下：

云服務器：

監控內容	監控工具	監控內容解釋	觸發器
磁盤利用率>95%	云監控	磁盤利用率	統計粒度1分鐘，連續5次滿足條件則2小時告警一次
CPU利用率>95%	云監控	CPU利用率	統計粒度1分鐘，連續5次滿足條件則2小時告警一次
內存利用率>95%	云監控	內存利用率	統計粒度1分鐘，連續5次滿足條件則2小時告警一次
外網出帶寬使用率>95%	云監控	外網出帶寬使用率	統計粒度1分鐘，連續5次滿足條件則2小時告警一次
CPU一分鐘平均負載>5	云監控	CPU一分鐘平均負載	統計粒度1分鐘，連續5次滿足條件則2小時告警一次
zabbix_agent 持續5分鐘未采集到數據	Zabbix	Zabbix agent連通性	統計粒度1分鐘，連續5次滿足條件則2小時告警一次
服務器發生重啟	Zabbix	服務器發生重啟	統計粒度1分鐘，system.uptime.change值<0即告警

云數據庫：

監控內容	監控工具	監控內容解釋	觸發器
磁盤利用率>85%	云監控	磁盤利用率	統計粒度1分鐘，連續5次滿足條件則2小時告警一次
CPU利用率>85%	云監控	CPU利用率	統計粒度1分鐘，連續5次滿足條件則2小時告警一次
內存利用率>85%	云監控	內存利用率	統計粒度1分鐘，連續5次滿足條件則2小時告警一次
主從延遲時間>5S	云監控	主從延遲時間	統計粒度1分鐘，連續5次滿足條件則2小時告警一次

對象存儲:

監控內容	監控工具	監控內容解釋	觸發器
4xx狀態碼>50次	云監控	4xx狀態碼	統計粒度1分鐘，連續5次滿足條件則2小時告警一次
5xx狀態碼>50次	云監控	5xx狀態碼	統計粒度1分鐘，連續5次滿足條件則2小時告警一次

容器服務:

監控內容	監控工具	監控內容解釋	觸發器
容器服務Pod數量環比波動20%	云監控	容器服務Pod數量環比波動	統計粒度1分鐘，連續5次滿足條件則2小時告警一次
容器服務集群PVC云盤使用率大于90%	云監控	容器服務集群PVC云盤使用率	統計粒度1分鐘，連續5次滿足條件則2小時告警一次
容器服務集群中容器內存使用率大于90%	云監控	容器服務集群中容器內存使用率	統計粒度1分鐘，連續5次滿足條件則2小時告警一次
容器服務集群中容器CPU使用率大于90%	云監控	容器服務集群中容器CPU使用率	統計粒度1分鐘，連續5次滿足條件則2小時告警一次
容器服務集群發現狀態異常Pod	云監控	容器服務集群發現狀態異常Pod	狀態異常的Pod數 > 1個，連續5次滿足條件則2小時告警一次
容器服務集群節點Pod重啟次數大于3次	云監控	容器服務集群節點Pod重啟次數	Pod重啟次數 > 3次，連續5次滿足條件則2小時告警一次
容器服務集群節點內存使用率大于90%	云監控	容器服務集群節點內存使用率	統計粒度1分鐘，連續5次滿足條件則2小時告警一次
容器服務集群節點CPU使用率大于90%	云監控	容器服務集群節點CPU使用率	統計粒度1分鐘，連續5次滿足條件則2小時告警一次
容器服務集群內存使用率大于90%	云監控	容器服務集群內存使用率	統計粒度1分鐘，連續5次滿足條件則2小時告警一次
容器服務集群CPU使用率大于90%	云監控	容器服務集群CPU使用率	統計粒度1分鐘，連續5次滿足條件則2小時告警一次
容器服務集群Node狀態異常	云監控	容器服務集群Node狀態	統計粒度1分鐘，連續5次滿足條件則2小時告警一次

消息服務Kafka：

監控內容	監控工具	監控內容解釋	觸發器
磁盤使用百分比>90%	云監控	磁盤使用百分比	統計粒度1分鐘，連續5次滿足條件則2小時告警一次
實例連接數百分比>90%	云監控	實例連接數百分比	統計粒度1分鐘，連續5次滿足條件則2小時告警一次
實例生產帶寬百分比>90%	云監控	實例生產帶寬百分比	統計粒度1分鐘，連續5次滿足條件則2小時告警一次
實例消費帶寬百分比>90%	云監控	實例消費帶寬百分比	統計粒度1分鐘，連續5次滿足條件則2小時告警一次

云數據庫MongoDB：

監控內容	監控工具	監控內容解釋	觸發器
磁盤利用率>90%	云監控	磁盤利用率	統計粒度1分鐘，連續5次滿足條件則2小時告警一次
CPU利用率>90%	云監控	CPU利用率	統計粒度1分鐘，連續5次滿足條件則2小時告警一次
連接使用率>90%	云監控	連接使用率	統計粒度1分鐘，連續5次滿足條件則2小時告警一次
內存使用率>90%	云監控	內存使用率	統計粒度1分鐘，連續5次滿足條件則2小時告警一次

云數據庫Redis：

監控內容	監控工具	監控內容解釋	觸發器
CPU利用率>90%	云監控	CPU利用率	統計粒度1分鐘，連續5次滿足條件則2小時告警一次
內存利用率>90%	云監控	內存利用率	統計粒度1分鐘，連續5次滿足條件則2小時告警一次
出流量使用率>90%	云監控	出流量使用率使用率	統計粒度1分鐘，連續5次滿足條件則2小時告警一次
連接使用率>90%	云監控	連接使用率	統計粒度1分鐘，連續5次滿足條件則2小時告警一次
節點CPU利用率>90%	云監控	節點CPU利用率	統計粒度1分鐘，連續5次滿足條件則2小時告警一次
節點內存利用率>90%	云監控	節點內存利用率	統計粒度1分鐘，連續5次滿足條件則2小時告警一次

云數據庫PostgreSQL：

監控內容	監控工具	監控內容解釋	觸發器
存儲空間使用率>90%	云監控	存儲空間使用率	統計粒度1分鐘，連續5次滿足條件則2小時告警一次
CPU利用率>90%	云監控	CPU利用率	統計粒度1分鐘，連續5次滿足條件則2小時告警一次
內存利用率>90%	云監控	內存利用率	統計粒度1分鐘，連續5次滿足條件則2小時告警一次

Elasticsearch集群：

監控內容	監控工具	監控內容解釋	觸發器
最大磁盤使用率>90%	云監控	最大磁盤使用率	統計粒度1分鐘，連續5次滿足條件則2小時告警一次
最大CPU利用率>90%	云監控	最大CPU利用率	統計粒度1分鐘，連續5次滿足條件則2小時告警一次
最大內存利用率>90%	云監控	最大內存利用率	統計粒度1分鐘，連續5次滿足條件則2小時告警一次
平均JVM內存使用率>95%	云監控	平均JVM內存使用率	統計粒度1分鐘，連續5次滿足條件則2小時告警一次

負載均衡：

監控內容	監控工具	監控內容解釋	觸發器
服務器端口狀態異常	云監控	服務器端口狀態異常	統計粒度1分鐘，連續5次滿足條件則2小時告警一次

4.6 備份與恢復

備份是數據安全保護的一個重要措施。備份可以幫助防止數據丟失、誤刪除、系統故障等問題，而備份恢復策略可以確保在出現問題時能夠快速恢復數據和系統運行。

具體來說，備份恢復策略可以幫助防止以下問題：

數據丟失：防止因為意外事件導致數據丟失，比如硬件故障、網絡中斷、自然災害等。

誤刪除：防止因為人為操作失誤而刪除了重要數據。

系統故障：防止因為軟件或系統故障導致數據無法訪問或使用。

云平臺的備份恢復策略通常包括定期備份、多地備份、多版本備份、緊急備份等，可以根據用戶的需求和實際情況進行配置。這樣可以保證數據的安全性和可用性，讓用戶更加放心地使用云服務。

4.6.1 數據文件備份

云平臺提供了快照服務，用戶可以使用快照對云盤、數據庫等資源進行數據備份。阿里云的快照服務支持定期備份、手動備份、增量備份等多種備份方式，可以在用戶數據發生變化時，僅備份變化的部分，從而減少備份所需時間和存儲空間。同時，阿里云快照還提供了多版本備份和快照恢復功能，讓用戶可以方便地對歷史數據進行管理和恢復，提高數據可靠性和恢復能力。此外，快照還可以用于數據遷移和災難恢復，在數據中心或云區域遭受自然災害、硬件故障或其他災難性事件時，可以通過恢復快照來快速恢復數據和系統，確保業務的連續性。綜合而言，阿里云的快照服務為用戶提供了可靠、高效的數據備份和恢復解決方案，可以有效保護用戶數據安全，提高業務連續性和可用性。

生產環境：

適用范圍	所有數據盤上存放有應用數據的云服務器
備份方式	設置自動快照策略，對數據盤進行快照
頻率	每1天1次
開始時間	01:00
保存時長	2周

* 快照對服務器性能有所影響，建議根據業務系統的實際使用情況在業務低峰期進行備份，通常是在每日凌晨1點的業務低峰時段執行；

測試環境：

適用范圍	所有數據盤上存放有應用數據的云服務器
備份方式	設置自動快照策略，對數據盤進行快照
頻率	每1天1次
開始時間	01:00
保存時長	1周

4.6.2 數據庫備份

云平臺的云數據庫備份提供了多種備份方式，包括手動備份、自動備份和增量備份等，以保護數據庫數據的安全性和完整性。用戶可以根據自己的需求和場景選擇合適的備份方式，同時支持多版本備份和數據恢復功能，方便用戶對歷史數據進行管理和恢復，保證數據庫數據的可靠性和恢復能力。此外，云平臺的云數據庫備份采用高可靠、高可用的架構，保證備份的穩定性和可用性，同時提供災備、容災等功能，以確保數據的連續性和可用性。綜合而言，云平臺的云數據庫備份提供了完善的備份策略和功能，可以為用戶提供高效、安全的數據庫備份和恢復解決方案。

生產環境：

備份類型	開始時間	備份頻率	保存時長
快照備份	01:00	每天	14天
日志備份	01:00	每天	14天

測試環境：

備份類型	開始時間	備份頻率	保存時長
快照備份	01:00	每天	7天
日志備份	01:00	每天	7天

4.6.3 HBR備份

阿里云上有統一災備平臺：混合云備份HBR（Hybrid Backup Recovery) 。HBR集成了阿里云ECS整機、ECS數據庫、文件系統、NAS、OSS以及自建機房內的文件、數據庫、虛擬機、大規模NAS等提供備份、容災保護以及策略化歸檔管理功能，是一個簡單易用、敏捷高效、安全可靠的公共云數據管理服務，云平臺備份策略多是在HBR上進行統一管理的。

SQL Server數據庫備份：

備份類型	開始時間	備份頻率	保存時長
全量備份	22:00	每周六	3個月
增量備份	00:00	每天	3個月

ECS文件備份：

備份類型	開始時間	備份頻率	保存時長
指定目錄備份	/	每周一次	1個月

ECS整機備份：

備份類型	開始時間	備份頻率	保存時長
策略1	00:00	每周	30天
策略2	00:00	每天	7天

OSS備份：

備份類型	開始時間	備份頻率	保存時長
整個Bucket	00:00	每天	7天

NAS備份：

備份類型	開始時間	備份頻率	保存時長
策略1	00:00	每周	30天
策略2	00:00	每天	7天

4.6.4 備份管理

4.6.4.1 確認備份策略

在系統上線后，系統及其中的數據是非常寶貴和敏感的。如果在不確定備份策略的情況下，出現系統故障、磁盤損壞、數據損壞等情況，就會嚴重影響業務穩定性和數據安全性。因此，云上系統在上線前，用明確的備份策略確保系統和數據安全是非常必要的。

備份策略以下表為例:

產品	環境	備份策略	備注
CVM	容器集群	不備份
CVM	vpn-ldap-keyclock	每周六、周一，23:00創建，保留15天
Mysql	prd	每天1備，保留30天
Mysql	dev	每天1備，保留7天
PostgreSQL	prd	每天1備，保留30天
PostgreSQL	dev	每天1備，保留7天
Redis	prd	每天1備，保留7天
Redis	dev	每天1備，保留7天
MongoDB	prd	每天1備，保留7天
MongoDB	dev	每天1備，保留7天
ES	prd	每天1備，保留7天
Clickhouse	prd	每天1備，保留7天
COS	prd	暫時只開啟版本控制，不開啟存儲桶復制

4.6.4.2 備份回顧

由于備份會在一定的時間間隔下進行，因此備份的數據可能會被篡改或者遺漏，會導致備份的數據不完整或丟失；備份過程也可能發生各種異常情況，例如目標磁盤空間不足、備份介質損壞或故障等等，而這些異常情況會導致備份失敗。

通過定期檢查備份成功率，可以發現備份數據是否完整和準確，發現潛在的備份異常情況，測試備份恢復過程的可行性和可靠性，并進一步確保備份策略的有效性。最終達到保證數據安全性和業務連續性的目的。

4.6.4.3 備份恢復演練

備份恢復是備份的最終目標，為了檢查備份成功率可以測試備份恢復過程的可行性和可靠性，以確保在恢復過程中沒有遺漏，需要進定期的備份恢復演練，并通過備份恢復演練達到以下目的：

驗證備份方案：備份恢復演習是驗證備份方案是否正確和有效的最佳方式。通過實際演練，可以發現潛在的問題和漏洞，并及時修復。
·備份恢復效率：實際演練可以幫助企業測試備份和恢復流程的效率，并及時發現和解決流程中的瓶頸和短板，提高備份恢復的效率。
避免數據丟失：實際演習有助于驗證數據恢復的完整性，以及數據丟失的可能性，從而幫助企業采取必要的措施防止數據丟失。
降低業務風險：恢復演習可以幫助企業更好地了解備份運作流程以及在實際災難發生時該如何恢復數據。這將有助于企業在發生意外情況時，快速、正確地響應并保持業務連續性，降低業務風險。

提高員工技能：經過實際演習的員工，可以更加熟練的操作備份和恢復流程，提高員工的技能水平和工作效率。

備份恢復演練過程如下圖，需提前準備“演練計劃與資源清單”與“演練計劃與記錄”。

圖片

4.7 漏洞與補丁管理

阿里云漏洞和補丁管理規范遵循以下步驟：

漏洞掃描：定期對阿里云上的系統、應用程序等進行漏洞掃描，確保系統的安全性。

漏洞評估：對掃描出的漏洞進行評估，確定漏洞的危害程度，以及對系統的影響。

漏洞修復：根據漏洞評估結果，及時修復已經發現的漏洞。對于無法立即修復的漏洞，可以采取其他安全措施，例如禁用相關服務或端口等。

補丁管理：及時安裝阿里云提供的安全補丁，以確保系統的安全性。阿里云會定期發布安全補丁，用戶需要及時查看并安裝。

自動化管理：建立自動化的漏洞和補丁管理系統，確保及時發現并修復漏洞，以及自動安裝補丁。

日志監控：建立日志監控機制，及時發現異常，以便及時采取措施。

安全培訓：對相關人員進行安全培訓，提高他們的安全意識和技能，以確保系統的安全性。

總之，阿里云漏洞和補丁管理規范需要建立完善的管理流程和安全措施，定期進行漏洞掃描和評估，并及時修復漏洞和安裝補丁，以確保系統的安全性。同時，建立自動化管理系統和日志監控機制，加強安全培訓，也是非常重要的措施。

4.8 系統巡檢

阿里云系統巡檢規范遵循以下步驟：

確認巡檢范圍：明確巡檢的對象、范圍和時間，包括云服務器、云數據庫、云存儲等。

確認巡檢內容：根據巡檢范圍確定巡檢的內容，如系統狀態、資源使用率、服務可用性、安全漏洞等。

巡檢工具：選擇合適的工具進行巡檢，如云監控、阿里云安全中心等，也可以使用第三方的巡檢工具。

巡檢頻率：根據業務需求和實際情況，確定巡檢頻率，建議進行定期巡檢，以保障系統的穩定性和安全性。

巡檢報告：將巡檢結果記錄在巡檢報告中，包括問題描述、嚴重程度、建議措施等，并及時通知相關人員和部門。

問題解決：對巡檢中發現的問題，根據其嚴重程度及時采取相應措施，如修復漏洞、調整資源配置等，確保系統的穩定性和安全性。

定期復查：定期復查巡檢報告中的問題，確保問題得到徹底解決，并對巡檢工作進行總結和改進。

總之，阿里云系統巡檢規范需要建立完善的巡檢流程和規范，包括確認巡檢范圍和內容、選擇合適的巡檢工具、確定巡檢頻率、記錄巡檢結果、解決問題和定期復查等。巡檢的目的是確保系統的穩定性和安全性，提高系統的可靠性和可用性，對于運維工作來說非常重要。

4.9 費用管理

具體來說，備份恢復策略可以幫助防止以下問題：

數據丟失：防止因為意外事件導致數據丟失，比如硬件故障、網絡中斷、自然災害等。

誤刪除：防止因為人為操作失誤而刪除了重要數據。

系統故障：防止因為軟件或系統故障導致數據無法訪問或使用。

4.9.1 費用預算管理

在使用云平臺服務之前，需要確定一個費用預算，以避免出現超出預算的情況。并以此為基礎，綜合評估此業務系統的計算、存儲、網絡、數據庫等云資源配置是否合理，確保費用的合理性和可控性。

4.9.2 費用核對和審計

定期對阿里云的費用訂單進行核對和審計，以確保費用的正確性和合規性。如果發現異常的費用，需要及時進行調查和處理。

4.9.3 費用分配和歸集

根據業務需求和費用結構，對云平臺的費用進行分配和歸集，以便更好地管理和控制費用。

4.9.4 費用監控和預警

通過阿里云的監控系統，對費用進行實時監控和預警，及時發現并處理費用異常情況，確保費用的合理性和控制。

4.9.5 費用節約與優化

對云平臺的服務和資源進行優化，以減少不必要的費用支出。例如使用自動化工具和人工定期巡檢，優化實例規格和配置等。可以根據監控數據來制定針對性的優化方案，如修改實例規格、關閉閑置實例、使用按需計費等，以此來優化云計算資源的配置，提升資源利用率并降低不必要的云費用。

云平臺費用管理的目的是確保費用的合理性和控制，避免不必要的費用支出，同時提高業務效率和運營效益。

4.10 運維服務流程

4.10.1 監控事件響應流程

在基礎運維服務過程中，依照如下監控事件響應流程提供服務：

云運維工程師通過現有監控體系，在接收到系統異常告警的時候，首先尋找和排查告警內容的影響和范圍，判斷系統異常、應用異常或云平臺相關異常類型后，進行對應的處理。

1) 系統異常處理

· 系統進程、主機名、密碼更改等狀態異常處理。

· cpu、磁盤、內存、網卡狀態異常處理。

· 中間件、服務進程、相應服務狀態異常處理。

· 通過腳本擴展的自定義的監控項狀態異常處理。

2) 應用異常處理

· 根據監控結果對應用的異常做應急響應與異常處理。

· 如若無法處理，及時通知用戶及應用供應商，并協助處理。

3) 云平臺資源相關異常處理

· 宕機遷移、數據庫異常及其它云服務等相關事故異常處理。

· 云服務相關升級期間導致服務異常中斷異常事故處理。

當用戶出現核心業務異常不能正常訪問、服務器宕機等災難性的事故時，云運維工程師在默認情況下，會以7*24的方式通知用戶和相關方，及時同步事故狀態和事故處理情況。低于此類的事故級別，云運維工程師會以消息推送的方式通知。具體的通知的時間，通知的方式可以由雙方協商確定。

4.10.2 變更流程

資源的變更流程是指在使用云服務基礎設置過程中，由于不同原因需要對資源進行調整或修改時，需要遵循一定的變更流程來保證變更的有效性和安全性。

4.10.2.1 變更紀律

· 所有變更提前一天確認，無變更審批不執行任何操作

· 重要變更提前一周確認無變更審批和用戶確認不執行任何操作

· 影響生產、VIP使用的操作提交緊急變更，確認操作步驟和影響后進行操作

· 其他需求原則上提前一天溝通否則不予支持

· 檢查檢查再檢查，確認確認再確認

4.10.2.2 新增資源

用戶有新增服務器或者數據庫等需求，需通過郵件發出申請，并在郵件中對新增資源按如下格式進行說明：

申請人			部門		日期
申請項目與原因
申請的資源	XXX資源	詳細信息及配置參數

		網絡安全白名單相關需求

說明
應用負責人簽字				條線部門經理簽字
經理簽字
部門經理簽字

云運維工程師收到新增資源需求后，在經過綜合評估后，將在工單系統發起請求，審批通過后根據請求內容對資源進行安全加固、監控部署等操作。

4.10.2.3 配置變更

相關部門提交變更需求后應有IT部統籌評估并發起變更，IT部內部變更需求應由變更申請人提交相關變更請求。

云運維工程師在變更操作之前，需要評估變更可能造成的風險，并制定變更的詳細計劃和回退方案；對業務的關鍵應用需要進行充分的測試，且不能在生產環境進行測試及調試，如若重要測試需要測試環境。

變更操作前云運維工程師需要對服務器或配置文件進行備份。

所有變更均應經過相應層面的審批，實施部門和配合部門在變更實施完成后應進行變更驗證。

本文鏈接：http://www.www897cc.com/showinfo-26-11794-0.html繼續聊聊云平臺運維規范

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com

上一篇：徹底搞懂Spring的Bean加載

下一篇：還不會部署微服務項目？保姆級教程來啦！

標簽：

熱門焦點

小米降噪藍牙耳機Necklace分享：聽一首歌讀懂一個故事

在今天下午的小米Civi 2新品發布會上，小米還帶來了一款新的降噪藍牙耳機Necklace，我們也在發布結束的第一時間給大家帶來這款耳機的簡單分享。現在大家能見到最多的藍牙耳機
三言兩語說透設計模式的藝術-單例模式

寫在前面單例模式是一種常用的軟件設計模式，它所創建的對象只有一個實例，且該實例易于被外界訪問。單例對象由于只有一個實例，所以它可以方便地被系統中的其他對象共享，從而減少
微信語音大揭秘：為什么禁止轉發？

大家好，我是你們的小米。今天，我要和大家聊一個有趣的話題：為什么微信語音不可以轉發？這是一個我們經常在日常使用中遇到的問題，也是一個讓很多人好奇的問題。讓我們一起來揭開這
破圈是B站頭上的緊箍咒

來源 | 光子星球撰文 | 吳坤諺編輯 | 吳先之每年的暑期檔都少不了瞄準追劇女孩們的古偶劇集，2021年有優酷的《山河令》，2022年有愛奇藝的《蒼蘭訣》，今年卻輪到小破站抓住了追
騰訊蓋樓，字節拆墻

來源 | 光子星球撰文 | 吳坤諺編輯 | 吳先之“想重溫暴刷深淵、30+技能搭配暴搓到爽的游戲體驗嗎？一起上晶核，即刻暴打！”曾憑借直播騰訊旗下代理格斗游戲《DNF》一
小米公益基金會捐贈2500萬元馳援北京、河北暴雨救災

8月2日消息，今日小米科技創始人雷軍在其微博上發布消息稱，小米公益基金會宣布捐贈2500萬元馳援北京、河北暴雨救災。攜手抗災，京冀安康！以下為公告原文
滴滴違法違規被罰80.26億共存在16項違法事實

滴滴違法違規被罰80.26億存在16項違法事實開始于2121年7月，歷經一年時間，網絡安全審查辦公室對“滴滴出行”網絡安全審查終于有了一個暫時的結束。據“網信
利用職權私自解除被封帳號 Meta開除20多名員工

11月18日消息，據外媒援引知情人士表示，過去一年時間內，Facebook母公司Meta解雇或處罰了20多名員工以及合同工，指控這些人通過內部系統以不當方式重置用戶帳號，其
Meta盲目擴張致超萬人被裁，重金押注元宇宙而前景未明

圖片來源：圖蟲創意日前，Meta創始人兼CEO 馬克·扎克伯發布公開信，宣布Meta計劃裁員超11000人，占其員工總數13%。他公開承認了自己的預判失誤：“不僅