總結(jié)了下這段時間遇到的問題。
快速生成字典表數(shù)據(jù)
在前期開發(fā)的時候，BA總是給我好幾張excel,讓我生成字典表,寫代碼又耗時，而且不同的excel字段也不一樣，不可能每次都要去改代碼吧，總之我不干，好在我能借助excel函數(shù)完成這樣的需求。
=CONCATENATE("insert into test_claims(`id`,`code`,`name`) values('", A1, "','",B1, "','",C1,"');")
這個函數(shù)的語法是 CONCATENATE(text1, [text2], ...)
1. text1（必需）：要聯(lián)接的第一個項目。項目可以是文本值、數(shù)字或單元格引用；
2. Text2, ... （可選）：要聯(lián)接的其他文本項目。最多可以有 255 個項目，總共最多支持 8,192 個字符
Kubernetes Pod頻繁重啟
后臺看到部署到kubernetes的pod一直在重啟，但是看日志沒有報錯，但是一會兒它就自動重啟了，最后通過describe命令看到是因為liveness接口的原因
kubelet Liveness probe failed: Get "http://10.24.8.84:9202/actuator/health"
因為使用了springboot actuator接口,它會檢測服務中使用到的其他服務是否能正常使用,從而判定當前服務是否存活，所以必然是因為這個接口返回的信息導致pod重啟。
重啟的這個服務主要用到了郵件以及Redis,但是不知道到底是哪個服務健康檢查失敗了。此時我們也無法進入到pod中訪問health接口了。
所以我們先移除掉pod template的livenessProbe配置，然后重新部署服務
livenessProbe:
httpGet:
path: /actuator/health
port: 9204
initialDelaySeconds: 60
periodSeconds: 20
timeoutSeconds: 10
這個時候使用exec命令進入pod
kubectl exec -it <pod name> -n <namespace> -- /bin/bash
訪問 curl -i http://localhost:9202/actuator/health 可以看到response status code是503,并且還可以看到具體失敗的組件是哪一個。
最終確定是redis訪問超時了，于是調(diào)整了下 livenessProbe的timeoutSeconds,然后在重啟就不報錯了。
root@noti-844567c558-2mvj8:/home/pro# curl -i http://localhost:9202/actuator/health
HTTP/1.1 200
X-XSS-Protection: 1; mode=block
Content-Security-Policy: default-src 'self'; script-src 'self'; frame-ancestors 'self'; object-src 'none'
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Content-Type: application/vnd.spring-boot.actuator.v3+json;charset=utf-8
Transfer-Encoding: chunked
Date: Sun, 18 Feb 2024 07:36:22 GMT
{"status":"UP","components":{"discoveryComposite":{"description":"Discovery Client not initialized","status":"UNKNOWN","components":{"discoveryClient":{"description":"Discovery Client not initialized","status":"UNKNOWN"}}},"diskSpace":{"status":"UP","details":{"total":133003395072,"free":94000709632,"threshold":10485760,"exists":true}},"livenessState":{"status":"UP"},"mail":{"status":"UP","details":{"location":"xxmail:465"}},"ping":{"status":"UP"},"readinessState":{"status":"UP"},"redis":{"status":"UP","details":{"version":"6.0.14"}},"refreshScope":{"status":"UP"}},"groups":["liveness","readiness"]}
minio數(shù)據(jù)遷移到Azure blob
項目中需要將minio中保存的文件遷移到azure的blob中,然后minio中保存文件的路徑是這樣的 2023/11/07/20231107164256A579/Image3.jpg 相當于文件夾中包含了時間戳等信息，雖然blob不支持目錄，但是它的虛擬目錄可以有相同的效果，這里我們使用azure提供的azcopy命令來進行數(shù)據(jù)遷移。
首先進入到minio所在的服務器,然后執(zhí)行下面的命令
1. sudo mkdir /home/azcopy
2. cd /home/azcopy
3. sudo wget -O azcopy_v10.tar.gz https://aka.ms/downloadazcopy-v10-linux &&
4. sudo tar -xf azcopy_v10.tar.gz --strip-components=1
5. sudo azcopy login // 登錄azure
6. 同步minio數(shù)據(jù)到blob,將sc-dev bucket的數(shù)據(jù)遷移到blob的container
// 這里的sc-dev是minio的bucket, saoscdev是azure blob的account name, bvsc是container name
a. sudo /home/azcopy/azcopy copy '/data/minio/data/sc-dev/*' 'https://saoscdev.blob.core.windows.net/bvsc' --recursive
// 將增量數(shù)據(jù)同步到blob中
b. sudo /home/azcopy/azcopy sync '/data/minio/data/sc-dev' 'https://saoscdev.blob.core.windows.net/bvsc' --recursive
總結(jié)
以上就是我最近遇到的問題，第一個字典表的那個當時第一反應是寫代碼，但是后來想到寫代碼的時候太長，成本太高還是需要借助工具，恰好提供給我的又是excel,于是就用excel順帶完成了這個功能，同時后面的其他字典數(shù)據(jù)如法炮制，也就變簡單了。
第二個問題本來是定位重啟的問題，但是看著看著就深入到了actuator的源碼當中起了，這一點很不好，不過有失必有得，有順帶看了下actuator的源碼,它其中的EntryPoint感覺很棒，后面針對這個寫一篇。
第三個問題的話就是微軟沒有提供如何遷移的文檔，不過好在它本生工具不少，多嘗試也就成功了，這里我把遷移的步驟給出來，希望能幫助到同樣有需求的人。
