1. 為什么是 Manjaro systemd微服務(wù)跑在 Arch 系發(fā)行版上的真實(shí)體驗(yàn)先說(shuō)結(jié)論把微服務(wù)跑在 Manjaro Linux 上再用 systemd 把啟動(dòng)順序和資源配額管起來(lái)這套組合解決的不只是開(kāi)機(jī)之后手動(dòng)敲一串 docker start這種體力活而是把整臺(tái)開(kāi)發(fā)機(jī)或者邊緣節(jié)點(diǎn)的服務(wù)生命周期真正納入一個(gè)統(tǒng)一控制系統(tǒng)里。很多人一聽(tīng) systemd 就想到開(kāi)機(jī)自啟和查看日志但它在微服務(wù)場(chǎng)景下的能力遠(yuǎn)不止這些——依賴編排、故障自愈、資源限額、啟動(dòng)時(shí)序分析這些都是生產(chǎn)環(huán)境里天天要面對(duì)的問(wèn)題而 systemd 全部原生支持不需要額外裝 supervisor 或者 monit。為什么單獨(dú)說(shuō) Manjaro因?yàn)樗?Arch 系發(fā)行版里對(duì)普通開(kāi)發(fā)者和運(yùn)維最友好的一檔預(yù)裝桌面、硬件驅(qū)動(dòng)全、軟件源更新及時(shí)但同時(shí)保留了 Arch 的 systemd 體系和滾動(dòng)更新節(jié)奏。這意味著你可以直接在物理機(jī)或者虛擬機(jī)上跑微服務(wù)不用像容器方案那樣先折騰一層 Docker daemon也不用擔(dān)心 RHEL 系那種 systemd 版本偏老導(dǎo)致某些新指令不可用。Manjaro 自帶的 systemd 版本常年保持較新cgroup v2 默認(rèn)開(kāi)啟MemoryMax、CPUQuota 這些資源控制指令能直接用這在某些老發(fā)行版上是要額外配置甚至踩坑的。這篇文章適合誰(shuí)兩種情況最對(duì)口一是你的微服務(wù)還在起步階段團(tuán)隊(duì)想在開(kāi)發(fā)機(jī)上把十幾個(gè)服務(wù)跑起來(lái)而不是非得先上 Kubernetes二是你已經(jīng)有一套微服務(wù)代碼但每次開(kāi)機(jī)、斷電、或者更新系統(tǒng)之后服務(wù)啟動(dòng)順序亂掉、內(nèi)存被某個(gè)異常進(jìn)程吃滿、某個(gè)服務(wù)崩潰后沒(méi)人拉起想找一個(gè)輕量但靠譜的解決方案。這兩種場(chǎng)景systemd 都能覆蓋——畢竟它是 Linux 世界的 init 系統(tǒng)本身就長(zhǎng)在進(jìn)程管理的土壤上。我自己在 Manjaro 上維護(hù)過(guò)一套約 20 個(gè)微服務(wù)的模擬項(xiàng)目從配置中心、網(wǎng)關(guān)到訂單、支付、通知前后折騰了大概三周才把啟動(dòng)鏈路調(diào)到穩(wěn)定。這個(gè)過(guò)程里踩過(guò)的坑、驗(yàn)證過(guò)的參數(shù)、總結(jié)出的套路我盡量在這篇文章里一次說(shuō)透你照著做基本能少走一半彎路。1.1 微服務(wù)在開(kāi)發(fā)機(jī)上最頭疼的三件事聊具體配置之前先說(shuō)說(shuō)我們到底在解決什么問(wèn)題。微服務(wù)拆到十幾二十個(gè)以后開(kāi)發(fā)機(jī)上最常碰到的三件事第一啟動(dòng)順序失控。網(wǎng)關(guān)要等注冊(cè)中心先起來(lái)業(yè)務(wù)服務(wù)要等配置中心拉完配置再注冊(cè)但如果你只是把這些服務(wù)一股腦寫成 shell 腳本加上扔到后臺(tái)每次啟動(dòng)都像開(kāi)盲盒。某一個(gè)服務(wù)啟動(dòng)慢了幾秒后面依賴它的服務(wù)全部注冊(cè)失敗報(bào)錯(cuò)信息還千奇百怪排查半天發(fā)現(xiàn)根本不是代碼問(wèn)題。第二資源互相擠占。二十個(gè)服務(wù)跑在一臺(tái)機(jī)器上里面有內(nèi)存泄漏的、有瘋狂刷日志的、有定時(shí)任務(wù)并發(fā)拉滿 CPU 的。沒(méi)有配額的情況下任何一個(gè)失控服務(wù)都可能拖垮整臺(tái)機(jī)器——最典型的是某服務(wù)把內(nèi)存吃到 swap整機(jī)響應(yīng)變慢其他服務(wù)跟著超時(shí)。第三故障恢復(fù)靠人肉。開(kāi)發(fā)環(huán)境里服務(wù)崩潰太常見(jiàn)了測(cè)試同學(xué)跑一個(gè)邊界 case 就能把服務(wù)打崩。如果沒(méi)有自動(dòng)拉起機(jī)制你吃個(gè)午飯回來(lái)發(fā)現(xiàn)服務(wù)從上午十點(diǎn)就死了一下午的驗(yàn)證工作全白費(fèi)。手動(dòng)systemctl restart一次兩次還行天天盯就太浪費(fèi)了。這三件事恰好都是 systemd 的原生能力覆蓋范圍用After和Requires聲明依賴用CPUQuota和MemoryMax限制資源用Restart配置自動(dòng)拉起。不需要額外引入編排框架不用學(xué)新 DSL把 unit 文件寫好就夠了。1.2 systemd 不是只會(huì) start/stop它本身就是一套進(jìn)程編排器很多人對(duì) systemd 的認(rèn)知停留在systemctl start nginx這種層面實(shí)際上它內(nèi)置了相當(dāng)完整的進(jìn)程編排能力。After、Requires、Wants這些指令組合起來(lái)就是一個(gè)聲明式的依賴圖Typenotify配合服務(wù)內(nèi)部的sd_notify能讓 systemd 判斷服務(wù)真正就緒而不只是進(jìn)程已 forkRestart配合StartLimitBurst則是故障自愈策略。換句話說(shuō)你在 Kubernetes 里常用的探針、重啟策略、資源 limitsystemd 在單機(jī)層面全部有對(duì)應(yīng)物只是名字不叫 probe、policy 而已。這套機(jī)制的底層是 cgroup。Manjaro 默認(rèn)啟用 cgroup v2每個(gè) service unit 啟動(dòng)后都會(huì)自動(dòng)掛到獨(dú)立的 cgroup 下systemd 能精確統(tǒng)計(jì)這個(gè)服務(wù)用了多少 CPU、多少內(nèi)存、多少 IO也能在超出配額時(shí)直接干預(yù)。這個(gè)特性對(duì)微服務(wù)的意義很大——你不用假裝它們彼此隔離systemd 在進(jìn)程樹層面就把隔離做掉了。另外systemd 的并行啟動(dòng)能力常被忽略。默認(rèn)情況下沒(méi)有依賴關(guān)系的 unit 會(huì)被并行拉起相比 shell 腳本的串行執(zhí)行十幾二十個(gè)服務(wù)的總啟動(dòng)時(shí)間能從幾分鐘壓到幾十秒。配合systemd-analyze blame還能精準(zhǔn)看出每個(gè)服務(wù)耗時(shí)多少優(yōu)化瓶頸一目了然。就沖這一點(diǎn)systemd 就值得認(rèn)真學(xué)一下。1.3 Manjaro 的滾動(dòng)更新對(duì)服務(wù)管理帶來(lái)的特殊挑戰(zhàn)Manjaro 是個(gè)滾動(dòng)更新發(fā)行版pacman -Syyu一天不跑就可能落后一個(gè)版本。好處是 systemd 和內(nèi)核都是新的壞處是更新完之后服務(wù)可能因?yàn)橐蕾囎兓鸩粊?lái)——比如某服務(wù)鏈接的動(dòng)態(tài)庫(kù)升級(jí)了或者系統(tǒng)的 cgroup 配置變了。所以在 Manjaro 上做 systemd 服務(wù)管理要比在 Ubuntu LTS 上多考慮一層更新之后必須做一次完整的服務(wù)健康巡檢而不是只看系統(tǒng)能不能開(kāi)機(jī)。我習(xí)慣的做法是每次系統(tǒng)大版本更新之后跑一遍systemctl list-units --failed把所有異常狀態(tài)一次性撈出來(lái)然后逐個(gè)journalctl -u 服務(wù)名 -b看啟動(dòng)日志。另外Manjaro 的 mkinitcpio 或者內(nèi)核更新之后重啟一定要確認(rèn) systemd 版本和 cgroup 掛載情況這些是服務(wù)管理穩(wěn)定性的底座。2. 動(dòng)手前先搞懂 systemd 的幾個(gè)核心機(jī)制這一節(jié)不直接上配置而是先把編排微服務(wù)最關(guān)鍵的幾個(gè) systemd 機(jī)制講清楚。這些概念看著簡(jiǎn)單但組合方式千變?nèi)f化理解不到位后面排錯(cuò)會(huì)毫無(wú)頭緒。2.1 依賴關(guān)系A(chǔ)fter、Requires、Wants 到底怎么選依賴是微服務(wù)編排的核心。systemd 里有三組常用指令語(yǔ)義完全不同After和Before只決定啟動(dòng)順序不決定要不要啟動(dòng)。也就是說(shuō)即使Aftermysql.service如果 mysql 沒(méi)啟用你的服務(wù)照樣會(huì)啟動(dòng)只是順序上排在后面。這相當(dāng)于說(shuō)如果它存在那就在它后面啟動(dòng)而不是必須等它啟動(dòng)成功。Requires是硬依賴。如果Requiresmysql.service且 mysql 啟動(dòng)失敗你的服務(wù)也會(huì)被停止。這類指令適合沒(méi)有依賴方就完全沒(méi)有意義的服務(wù)比如網(wǎng)關(guān)沒(méi)有注冊(cè)中心就玩不轉(zhuǎn)。Wants是軟依賴。依賴方啟動(dòng)失敗不會(huì)影響你的服務(wù)啟動(dòng)它只是表達(dá)能啟動(dòng)的話盡量啟動(dòng)啟動(dòng)不了我自己也能活著。BindsTo則更嚴(yán)格依賴方停止時(shí)你的服務(wù)必須跟著停止適合同生共死的強(qiáng)綁定關(guān)系。實(shí)操經(jīng)驗(yàn)90% 的場(chǎng)景用AfterWants組合就夠。原因很簡(jiǎn)單微服務(wù)之間大多不是啟動(dòng)即硬失敗的依賴而是晚點(diǎn)起來(lái)也能趕上注冊(cè)的弱依賴。真正的硬依賴留給基礎(chǔ)設(shè)施比如通用數(shù)據(jù)庫(kù)、消息隊(duì)列這類。如果用Requires把所有依賴都硬連起來(lái)任何一個(gè)服務(wù)掛了整條鏈上的服務(wù)全被拖下水故障隔離性反而更差。這個(gè)取舍一定要想清楚別一上來(lái)就是Requires拉滿。2.2 重啟策略與啟動(dòng)窗口把崩了自動(dòng)拉起來(lái)變成可控行為Restart選項(xiàng)有幾個(gè)值no不重啟、on-success正常退出才重啟實(shí)際用得少、on-failure非零退出碼才重啟、on-abnormal信號(hào)異常才重啟、always無(wú)論如何都重啟。對(duì)微服務(wù)來(lái)說(shuō)最常用的是always和on-failure。always適合那種就算主動(dòng) stop 也要馬上拉起來(lái)的服務(wù)——尤其是你希望它在系統(tǒng)里長(zhǎng)期存在的守護(hù)類服務(wù)。但要注意always在某些場(chǎng)景會(huì)造成困擾你明明執(zhí)行了systemctl stop它又立刻被拉起來(lái)排查時(shí)一臉懵。所以我更推薦開(kāi)發(fā)環(huán)境用on-failure配合RestartSec3這樣的退避時(shí)間既保證崩潰后自動(dòng)拉起又保留人工 stop 的控制力。RestartSec是重啟間隔設(shè)多少合適經(jīng)驗(yàn)上3~5 秒比較常用。太短會(huì)導(dǎo)致崩潰循環(huán)時(shí)瘋狂重啟CPU 飆高太長(zhǎng)又讓恢復(fù)時(shí)間難以接受。真正要防的是崩潰循環(huán)——服務(wù)一直起不來(lái)systemd 會(huì)進(jìn)入start-limit-hit狀態(tài)默認(rèn)策略是 10 秒內(nèi)失敗 5 次就放棄。這個(gè)默認(rèn)值對(duì)微服務(wù)來(lái)說(shuō)往往太激進(jìn)建議用StartLimitIntervalSec30和StartLimitBurst10放寬窗口給服務(wù)更多自愈機(jī)會(huì)但同時(shí)也別放到無(wú)上限否則雪崩發(fā)生時(shí)系統(tǒng)會(huì)非常難恢復(fù)。2.3 資源配額CPUQuota 和 MemoryMax 的取值怎么算資源配額這塊Manjaro 上的 systemd 直接映射 cgroup v2語(yǔ)義很明確CPUQuota的單位是百分比CPUQuota150表示最多用 1.5 個(gè)核。注意這是相對(duì)單核的百分比不是相對(duì)整機(jī)。比如你機(jī)器有 8 核 CPU給某個(gè)服務(wù)設(shè)CPUQuota100它最多用滿一個(gè)核完全不理會(huì)其他核是否空閑。這個(gè)設(shè)計(jì)的好處是行為可預(yù)期缺點(diǎn)是如果整機(jī)只有這一服務(wù)在跑其余 7 個(gè)核被白白浪費(fèi)。所以計(jì)算時(shí)要結(jié)合服務(wù)的實(shí)際情況對(duì)計(jì)算密集型的消費(fèi)者服務(wù)給200甚至300都合理對(duì)大部分 IO 型微服務(wù)50到100已經(jīng)足夠。MemoryMax是硬限制超過(guò)就 OOM。MemoryHigh是軟限制超過(guò)后會(huì)加大回收壓力但不一定殺掉。這兩個(gè)參數(shù)組合起來(lái)非常實(shí)用MemoryHigh512MMemoryMax768M意味著平時(shí)超過(guò) 512M 就開(kāi)始回收內(nèi)存逼近 768M 才會(huì)被殺給了服務(wù)一定的緩沖。取值怎么算我的方法是先在無(wú)限制狀態(tài)下穩(wěn)定跑一周用systemd-cgtop觀察每個(gè)服務(wù)的峰值內(nèi)存和 CPU 使用然后取一個(gè)峰值上浮 30%的余量作為MemoryHigh再上浮 50% 作為MemoryMax。別拍腦袋寫 1G那一會(huì)兒 OOM 一會(huì)兒資源的完全不可控。3. 實(shí)操給一套典型微服務(wù)寫 unit 文件光講理論沒(méi)用這一節(jié)我?guī)惆岩惶渍鎸?shí)場(chǎng)景完整搭一遍。先說(shuō)清楚這套方案針對(duì)的是單機(jī)部署的微服務(wù)開(kāi)發(fā)環(huán)境不是生產(chǎn)級(jí) K8s 集群的替代品但把 systemd 玩透之后很多思路遷移到生產(chǎn)環(huán)境一樣成立。3.1 場(chǎng)景定義與技術(shù)選型為了演示我定義一個(gè)模擬項(xiàng)目 X包含 6 個(gè)服務(wù)分別是基礎(chǔ)組件和業(yè)務(wù)服務(wù)混編infra-db數(shù)據(jù)庫(kù)技術(shù)棧不限但必須有服務(wù)端守護(hù)進(jìn)程infra-mq消息隊(duì)列負(fù)責(zé)服務(wù)間異步通信app-config配置中心其他服務(wù)啟動(dòng)時(shí)先拉取配置app-gatewayAPI 網(wǎng)關(guān)依賴配置中心和注冊(cè)中心app-order訂單服務(wù)依賴數(shù)據(jù)庫(kù)、消息隊(duì)列、配置中心app-notify通知服務(wù)消費(fèi)消息隊(duì)列中的通知消息這 6 個(gè)服務(wù)的依賴圖其實(shí)是有層次感的數(shù)據(jù)庫(kù)和消息隊(duì)列是底座配置中心屬于中間層網(wǎng)關(guān)和訂單、通知屬于上層。用 systemd 表達(dá)這種層次就是底層層After掛掉所有上層上層之間盡量并行。實(shí)際項(xiàng)目中注冊(cè)中心通常也要提前啟動(dòng)演示里我把它并入配置中心的服務(wù)內(nèi)不單獨(dú)拆開(kāi)。unit 文件統(tǒng)一放在/etc/systemd/system/目錄下寫完后執(zhí)行systemctl daemon-reload讓 systemd 重新加載配置。3.2 基礎(chǔ)設(shè)施服務(wù)的 unit 編寫基礎(chǔ)設(shè)施服務(wù)的 unit 是最容易寫的因?yàn)樗鼈兓臼仟?dú)立進(jìn)程 外部訪問(wèn)的模式。以infra-db為例# /etc/systemd/system/infra-db.service [Unit] DescriptionInfrastructure Database Service Afternetwork.target Wantsnetwork.target [Service] Typenotify ExecStart/usr/local/microsvc/bin/infra-db --config/etc/microsvc/db.yaml ExecReload/bin/kill -HUP $MAINPID Restarton-failure RestartSec3 # 資源配額 CPUQuota150 MemoryHigh768M MemoryMax1G TasksMax256 # 安全加固 NoNewPrivilegestrue PrivateTmptrue [Install] WantedBymulti-user.target這里有幾個(gè)值得解釋的細(xì)節(jié)。Typenotify意味著程序內(nèi)部要實(shí)現(xiàn)sd_notify在真正監(jiān)聽(tīng)端口成功后告訴 systemd我準(zhǔn)備好了。如果程序不支持sd_notify退一步用Typesimple也行——但要接受進(jìn)程一啟動(dòng)就算就緒的語(yǔ)義可能在端口尚未監(jiān)聽(tīng)時(shí)就被依賴方拉起。ExecReload/bin/kill -HUP $MAINPID是給數(shù)據(jù)庫(kù)類服務(wù)用的平滑重載生產(chǎn)環(huán)境經(jīng)常用systemctl reload而不是 restart避免連接閃斷。TasksMax256限制了服務(wù)能創(chuàng)建的線程和進(jìn)程總數(shù)防止線程泄漏的服務(wù)無(wú)限增長(zhǎng)。NoNewPrivilegestrue和PrivateTmptrue屬于安全加固對(duì)微服務(wù)來(lái)說(shuō)成本低收益高建議默認(rèn)加上。infra-mq的 unit 類似只是資源配額可以寬松一點(diǎn)畢竟消息隊(duì)列通常要扛吞吐。我給它的CPUQuota200MemoryHigh1G其他保持一致。3.3 業(yè)務(wù)服務(wù)的依賴編排與并行啟動(dòng)業(yè)務(wù)服務(wù)的 unit 才是編排的重點(diǎn)。看app-gateway# /etc/systemd/system/app-gateway.service [Unit] DescriptionAPI Gateway Service Afternetwork.target infra-db.service infra-mq.service app-config.service Wantsinfra-db.service infra-mq.service app-config.service PartOfapp-cluster.target [Service] Typenotify ExecStart/usr/local/microsvc/bin/app-gateway --config/etc/microsvc/gateway.yaml ExecStartPre/bin/bash -c until curl -sf http://127.0.0.1:8848/health /dev/null 21; do sleep 1; done Restarton-failure RestartSec5 # 資源配額 CPUQuota100 MemoryHigh512M MemoryMax768M [Install] WantedByapp-cluster.target注意ExecStartPre這一行的寫法。systemd 的After只保證順序不保證可用如果配置中心的健康檢查接口還沒(méi)就緒網(wǎng)關(guān)即使按順序啟動(dòng)也會(huì)注冊(cè)失敗。所以我在ExecStartPre里加了一個(gè)輪詢命令每 1 秒檢查一次配置中心健康接口通了才繼續(xù)啟動(dòng)。實(shí)際生產(chǎn)里我甚至見(jiàn)過(guò)有人把這種健康檢查直接寫進(jìn)服務(wù)代碼的啟動(dòng)流程中但用ExecStartPre做的好處是不侵入代碼改 systemd 配置就能調(diào)。PartOfapp-cluster.target配合末尾的WantedByapp-cluster.target相當(dāng)于把所有業(yè)務(wù)服務(wù)歸攏到一個(gè)上層 target 下。這樣你執(zhí)行systemctl start app-cluster.target就能拉起一整組服務(wù)反過(guò)來(lái)systemctl stop app-cluster.target也能整體停掉比逐個(gè)操作高效得多。target 本身不是一個(gè)進(jìn)程它只負(fù)責(zé)聚合 unit。再看app-order它依賴數(shù)據(jù)庫(kù)、消息隊(duì)列、配置中心但啟動(dòng)順序上不需要等通知服務(wù)所以# /etc/systemd/system/app-order.service [Unit] DescriptionOrder Service Afternetwork.target infra-db.service infra-mq.service app-config.service Wantsinfra-db.service infra-mq.service app-config.service PartOfapp-cluster.target [Service] Typenotify ExecStart/usr/local/microsvc/bin/app-order --config/etc/microsvc/order.yaml ExecStartPre/bin/bash -c until curl -sf http://127.0.0.1:8848/health /dev/null 21; do sleep 1; done Restarton-failure RestartSec3 CPUQuota100 MemoryHigh512M MemoryMax768M [Install] WantedByapp-cluster.target那app-notify呢它只依賴消息隊(duì)列和配置中心不依賴數(shù)據(jù)庫(kù)和網(wǎng)關(guān)。unit 文件的After就只寫infra-mq.service app-config.service。這樣 systemd 就能在滿足依賴的前提下讓app-order和app-notify并行啟動(dòng)整體啟動(dòng)時(shí)間大幅縮短。這就是 systemd 和 shell 腳本最大的區(qū)別你只需要描述依賴關(guān)系不需要關(guān)心執(zhí)行順序systemd 自己會(huì)做拓?fù)渑判蚝筒⑿姓{(diào)度。3.4 用 systemd-analyze 驗(yàn)證啟動(dòng)鏈路寫完 unit 文件后第一件事不是反復(fù)重啟服務(wù)而是用systemd-analyze驗(yàn)證配置正確性。兩條命令必用systemd-analyze verify /etc/systemd/system/*.service systemd-analyze critical-chain app-cluster.targetverify會(huì)檢查 unit 文件語(yǔ)法錯(cuò)誤和路徑問(wèn)題比如寫錯(cuò)指令名、引用了不存在的服務(wù)文件它都會(huì)直接報(bào)出來(lái)。critical-chain則是打印關(guān)鍵啟動(dòng)鏈路能看到哪個(gè)服務(wù)是瓶頸、哪個(gè)服務(wù)花費(fèi)的時(shí)間最長(zhǎng)。如果發(fā)現(xiàn)某兩步之間順序不對(duì)優(yōu)先檢查After有沒(méi)有寫全。常見(jiàn)的遺漏是把中間層服務(wù)漏掛在某個(gè)上層服務(wù)的After里導(dǎo)致上層提前啟動(dòng)。我在初期就犯過(guò)這個(gè)錯(cuò)網(wǎng)關(guān)忘了等配置中心結(jié)果每次重啟都間歇性注冊(cè)失敗日志里全是連接超時(shí)。后來(lái)用critical-chain一眼定位加上Afterapp-config.service后世界清凈了。啟動(dòng)時(shí)間的驗(yàn)證用這兩條systemd-analyze blame systemd-analyze plot /tmp/boot.svgblame按耗時(shí)排序列出所有服務(wù)plot生成可視化時(shí)間軸把每個(gè)服務(wù)的啟動(dòng)區(qū)間畫出來(lái)?？催@兩張圖你就能直觀發(fā)現(xiàn)哪個(gè)服務(wù)拖了后腿、哪個(gè)階段是完全可以并行的。我實(shí)際調(diào)優(yōu)的那次初始串行啟動(dòng)全部服務(wù)大約需要 95 秒罪魁禍?zhǔn)资悄硞€(gè)服務(wù)在ExecStartPre里 sleep 了 30 秒。去掉無(wú)腦 sleep、換成健康檢查輪詢?cè)侔巡幌嚓P(guān)的服務(wù)盡可能并行跑起來(lái)總時(shí)間直接壓到 38 秒。這個(gè)優(yōu)化結(jié)果對(duì)于一個(gè)單機(jī) Microservices 開(kāi)發(fā)環(huán)境來(lái)說(shuō)已經(jīng)是質(zhì)變了。4. 資源效率調(diào)優(yōu)從能跑到跑得省啟動(dòng)速度解決了接下來(lái)是資源效率。微服務(wù)的資源開(kāi)銷很大一部分不是業(yè)務(wù)邏輯本身而是無(wú)效損耗日志刷爆磁盤、線程無(wú)限增長(zhǎng)、內(nèi)存閾值寫得太保守導(dǎo)致頻繁 GC、CPU 配額過(guò)寬導(dǎo)致相互爭(zhēng)搶。systemd 在資源管理上有一套完整的控制手段這一節(jié)把關(guān)鍵點(diǎn)全部拆開(kāi)講。4.1 cgroup 層面的配額落實(shí)前面已經(jīng)講過(guò)CPUQuota和MemoryMax但真正落實(shí)到整體資源效率時(shí)還需要關(guān)注幾個(gè)容易被忽略的細(xì)節(jié)。首先是IOWeight和IOAccounting。微服務(wù)里經(jīng)常有某個(gè)服務(wù)瘋狂寫日志或者批量讀寫磁盤把整機(jī) IO 拖垮其他服務(wù)跟著卡頓。給關(guān)鍵服務(wù)設(shè)置IOWeight10左右的低權(quán)重配合IOAccountingtrue開(kāi)啟 IO 統(tǒng)計(jì)再用systemd-cgtop觀察能有效抑制單點(diǎn) IO 風(fēng)暴。注意 cgroup v2 的 IO 控制依賴 io 調(diào)度器Manjaro 默認(rèn)情況一般沒(méi)問(wèn)題但如果你用的是某些特殊內(nèi)核參數(shù)可能需要額外確認(rèn)。其次是CPUWeight與CPUQuota的區(qū)別。CPUQuota是絕對(duì)上限CPUWeight是相對(duì)權(quán)重只在競(jìng)爭(zhēng)時(shí)生效。對(duì)微服務(wù)來(lái)說(shuō)我建議所有關(guān)鍵服務(wù)都設(shè)絕對(duì)上限避免自適應(yīng)權(quán)重在突發(fā)流量下失控。唯一的例外是基礎(chǔ)設(shè)施服務(wù)比如數(shù)據(jù)庫(kù)我傾向于用CPUWeight100給它相對(duì)較高的權(quán)重但不用絕對(duì)配額讓它按需伸縮。然后是內(nèi)存層面的MemorySwapMax。cgroup v2 允許單獨(dú)控制 swap 使用量。開(kāi)發(fā)機(jī)上如果有 swap服務(wù)內(nèi)存溢出時(shí)會(huì)先交換而不是被殺掉但這會(huì)帶來(lái)嚴(yán)重的性能抖動(dòng)。我通常給微服務(wù)設(shè)置MemorySwapMax0強(qiáng)制超過(guò)MemoryMax就直接 OOM把它殺得干凈利落寧可重啟也不拖垮整機(jī)。這個(gè)取舍在開(kāi)發(fā)環(huán)境尤其有效——你會(huì)立刻在日志里看到 OOM 報(bào)錯(cuò)而不是整機(jī)卡死之后找不到原因。最后提一下TasksMax。線程泄漏是微服務(wù)最常見(jiàn)的隱形殺手。一個(gè)服務(wù)線程數(shù)從 100 漲到 10000內(nèi)存可能還沒(méi)到上限系統(tǒng)線程表已經(jīng)滿了。給每個(gè) unit 設(shè)置TasksMax512既保證正常業(yè)務(wù)并發(fā)又能阻止泄漏線程無(wú)限增長(zhǎng)。排查時(shí)看到某個(gè)服務(wù)的 PID 數(shù)量異常一查線程數(shù)往往就是這里出了問(wèn)題。4.2 journal 日志的瘦身與輪轉(zhuǎn)微服務(wù)的日志是資源黑洞。默認(rèn) journald 會(huì)把日志寫到/var/log/journal/不設(shè)限制的話幾個(gè)服務(wù)的高頻日志一周就能吃掉幾個(gè) GB 磁盤。所以日志策略必須主動(dòng)管理。systemd 提供兩種維度的控制全局的/etc/systemd/journald.conf和每個(gè)服務(wù)內(nèi)部的StandardOutput/StandardError。journald.conf里我有幾個(gè)習(xí)慣配置[Journal] SystemMaxUse1G SystemMaxFileSize100M MaxRetentionSec7day CompressyesSystemMaxUse1G把整個(gè) journal 總大小限制在 1GSystemMaxFileSize100M控制單個(gè)日志文件大小MaxRetentionSec7day保證最多保留七天Compressyes開(kāi)啟壓縮日志體積通常能再縮一半。這套組合下來(lái)日志對(duì)磁盤的壓力基本可以忽略。服務(wù)側(cè)的日志策略要區(qū)分場(chǎng)景。如果是Typenotify的服務(wù)程序通常自己處理日志文件如果是Typesimple的腳本類服務(wù)可以把輸出重定向到獨(dú)立文件StandardOutputappend:/var/log/microsvc/app-order.log StandardErrorappend:/var/log/microsvc/app-order.error.log注意append:前綴直接寫路徑是覆蓋模式重啟一次就丟歷史。這個(gè)坑我踩過(guò)——第一次配的時(shí)候用的StandardOutput/var/log/xxx.log服務(wù)一重啟日志全沒(méi)了排查問(wèn)題連現(xiàn)場(chǎng)都沒(méi)有。日志輪轉(zhuǎn)用logrotate配合 systemd timer 做核心是寫/etc/logrotate.d/microsvc配置把按大小切割和保留周期都定義好然后確保相應(yīng)的 timer 服務(wù)在跑。Manjaro 默認(rèn)已經(jīng)安裝了 logrotate 的 timer 配置你只要把服務(wù)配置文件填進(jìn)去就行。4.3 定時(shí)清理與維護(hù)讓滾動(dòng)更新不拖慢啟動(dòng)Manjaro 滾動(dòng)更新的特點(diǎn)是systemd 的自身行為可能會(huì)變但這個(gè)變化不會(huì)主動(dòng)向你報(bào)告。最典型的例子是某個(gè)服務(wù)的 unit 寫法和新版本 systemd 不再兼容systemd-analyze verify能查出來(lái)但沒(méi)人每天跑一次。所以我把服務(wù)健康檢查做成了定時(shí)任務(wù)每周自動(dòng)跑一次。我的做法是用 systemd timer 自己管自己# /etc/systemd/system/microsvc-weekly-check.service [Unit] DescriptionWeekly microservice health check [Service] Typeoneshot ExecStart/usr/local/microsvc/scripts/health-check.sh# /etc/systemd/system/microsvc-weekly-check.timer [Unit] DescriptionRun weekly microservice check [Timer] OnCalendarSun 03:00 Persistenttrue [Install] WantedBytimers.targethealth-check.sh腳本的核心邏輯是先systemctl list-units --failed檢查失敗狀態(tài)再逐個(gè)systemctl is-active檢查關(guān)鍵服務(wù)最后用journalctl --since 7 days ago -p err掃描最近一周的錯(cuò)誤日志把異常匯總到報(bào)告文件。這套自動(dòng)巡檢在滾動(dòng)更新后特別有用能第一時(shí)間發(fā)現(xiàn) systemd 升級(jí)導(dǎo)致的行為變化。還有一個(gè)細(xì)節(jié)Manjaro 每次大版本更新后重啟時(shí)機(jī)要選對(duì)。我習(xí)慣在更新完所有包、確認(rèn)systemd --version穩(wěn)定后主動(dòng)重啟一次讓系統(tǒng)在新內(nèi)核和新 systemd 下完整初始化。不重啟的話舊 systemd 跑在新文件系統(tǒng)上某些 unit 的狀態(tài)緩存可能會(huì)異常。5. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄這一節(jié)把我實(shí)際踩過(guò)、也幫別人排查過(guò)的問(wèn)題整理成速查表。每個(gè)問(wèn)題都給出定位方法和解決思路不再展開(kāi)理論直接上操作。5.1 啟動(dòng)順序還是不對(duì)怎么定位如果你已經(jīng)寫了After但服務(wù)還是亂序啟動(dòng)第一反應(yīng)不是改 unit 文件而是先確認(rèn) systemd 看到的依賴圖長(zhǎng)什么樣。systemctl list-dependencies app-order.service systemctl show app-order.service -p After -p Requires -p Wants第一條會(huì)遞歸打印所有依賴第二條直接查看生效的指令值。很多時(shí)候問(wèn)題出在After寫在了錯(cuò)誤的 section——注意After必須放在[Unit]段落里如果放到[Service]里systemd 會(huì)直接忽略并且verify報(bào)錯(cuò)。還有一種隱蔽情況你依賴的服務(wù)根本沒(méi)有啟用enable也沒(méi)被任何 target 拉起來(lái)。After只排順序不負(fù)責(zé)啟動(dòng)。如果你執(zhí)行systemctl start app-order.service但app-config.service沒(méi)在運(yùn)行順序?qū)α藚s還是連不上。此時(shí)必須確認(rèn)基礎(chǔ)設(shè)施服務(wù)已經(jīng) enable 且 active或者用Wants把它們一起拉起來(lái)。排查順序的建議list-dependencies看結(jié)構(gòu) →show看實(shí)際生效值 →critical-chain看時(shí)序 → 最后看 journal 確認(rèn)服務(wù)到底在等什么。5.2 服務(wù)反復(fù)重啟進(jìn)入 start-limit-hit這個(gè)報(bào)錯(cuò)幾乎每個(gè)用 systemd 管理服務(wù)的人都遇到過(guò)。表現(xiàn)為systemctl status里寫著start-limit-hit服務(wù)處于failed狀態(tài)你手動(dòng) start 都拉不起來(lái)。原因是 systemd 默認(rèn)的啟動(dòng)失敗計(jì)數(shù)窗口太短服務(wù)短時(shí)間連續(xù)失敗多次就被熔斷。解決辦法兩個(gè)方向一是調(diào)整 window二是找根因。調(diào)整參數(shù)在 service 文件里加StartLimitIntervalSec30 StartLimitBurst10意思是 30 秒內(nèi)最多失敗 10 次超過(guò)才熔斷。這個(gè)閾值適合多數(shù)微服務(wù)。如果還是頻繁觸發(fā)就要看日志找根因journalctl -u app-order.service -b -p err定位到崩潰棧后先修代碼問(wèn)題別指望調(diào)大 window 就能掩蓋一切。實(shí)際調(diào)優(yōu)時(shí)建議把 window 調(diào)寬一點(diǎn)的同時(shí)增加RestartSec的退避時(shí)間比如 5 秒。這樣崩潰循環(huán)時(shí)每次重啟間隔 5 秒10 次就是 50 秒的窗口systemd 不會(huì)誤判也給服務(wù)恢復(fù)留了時(shí)間。5.3 內(nèi)存限制導(dǎo)致 OOM 崩潰如何區(qū)分是配額還是代碼問(wèn)題MemoryMax設(shè)置不合理最直接的后果是服務(wù)被 OOM kill。現(xiàn)象是journalctl里有內(nèi)核的 OOM 記錄服務(wù)退出碼變成 137SIGKILL。問(wèn)題是到底是配額設(shè)太低還是代碼真的泄漏區(qū)分方法很簡(jiǎn)單。先把MemoryMax臨時(shí)調(diào)到無(wú)限制刪掉該行或者設(shè)個(gè)極大值觀察一段時(shí)間。如果內(nèi)存仍然持續(xù)上漲直到系統(tǒng)告警基本可以斷定是代碼泄漏去找 heap profile如果內(nèi)存穩(wěn)定在某個(gè)水平說(shuō)明是配額問(wèn)題按實(shí)測(cè)峰值重新計(jì)算即可。我維護(hù)的一套模擬項(xiàng)目中某個(gè)服務(wù)MemoryMax512M老是崩潰把限制放寬到 1G 后穩(wěn)定再觀察發(fā)現(xiàn)它實(shí)際峰值就是 800M 左右。后來(lái)定位到是某段批量任務(wù)一次性加載了太多數(shù)據(jù)到內(nèi)存優(yōu)化成流式處理之后峰值降到 300M再把配額調(diào)回 512M一切正常。配額限制本身是最后的防線不是優(yōu)化手段——真正省內(nèi)存還得從代碼層面做。5.4 快速排查工具組合拳最后整理一套我每天都會(huì)用到的排查組合拳# 看全局失敗狀態(tài) systemctl list-units --failed # 看單個(gè)服務(wù)的完整狀態(tài)和最近日志 systemctl status app-order.service journalctl -u app-order.service -n 200 --no-pager # 看服務(wù)的資源占用排行 systemd-cgtop # 看某服務(wù)關(guān)聯(lián)的 cgroup 配置 systemctl show app-order.service -p MemoryMax -p CPUQuota -p TasksMax這套流程覆蓋了有沒(méi)有掛、掛了為什么、資源占了多少、配置對(duì)不對(duì)四個(gè)問(wèn)題。實(shí)際排查時(shí)我基本是按這個(gè)順序一路查下去80% 的問(wèn)題能在五分鐘內(nèi)定位。另外強(qiáng)烈建議給journalctl配置別名我日常用的是alias jlogsjournalctl -u $1 -n 200 --no-pager -f-f是 follow 模式配合-n 200可以先看最近 200 行再持續(xù)跟蹤調(diào)試啟動(dòng)問(wèn)題非常好用。--no-pager在腳本里順手加上免得每次都卡在 less 里。還有一個(gè)小技巧確認(rèn)某個(gè)服務(wù)是不是真的就緒了別只看進(jìn)程狀態(tài)要看它監(jiān)聽(tīng)的端口。用ss -tlnp | grep app-order查看實(shí)際監(jiān)聽(tīng)情況比systemctl is-active更靠譜——is-active只代表 systemd 認(rèn)為它活著不代表業(yè)務(wù)端口通了。寫在最后一些實(shí)際體會(huì)這套 systemd 方案我在 Manjaro 上跑了差不多三個(gè)月從最初的頻繁起不來(lái)、連不上、被打崩到現(xiàn)在的開(kāi)機(jī)啟動(dòng)一條命令、資源占用穩(wěn)定、崩潰自動(dòng)拉起整個(gè)過(guò)程的收益非常直接。我個(gè)人體會(huì)最深的一點(diǎn)是別一上來(lái)就想著上 K8s。單機(jī)階段的微服務(wù)systemd 已經(jīng)解決掉了 90% 的進(jìn)程管理問(wèn)題而且沒(méi)有額外的運(yùn)維負(fù)擔(dān)。等到真有多機(jī)、彈性伸縮的需求再遷移到容器編排也不遲——那時(shí)你對(duì)依賴編排、健康檢查、資源配額的理解都是從 systemd 這套機(jī)制里長(zhǎng)出來(lái)的遷移成本反而低了。最后再分享一個(gè)小經(jīng)驗(yàn)unit 文件里寫注釋非常有用。systemd 的 unit 文件支持#注釋我會(huì)在每個(gè)服務(wù)的文件頭部寫清楚它的依賴關(guān)系、資源配額的取值依據(jù)、以及最近一次修改的原因。三個(gè)月后回來(lái)看這些注釋幫了大忙——你不可能記住當(dāng)時(shí)為什么給某個(gè)服務(wù)設(shè)了CPUQuota100而不是 150但注釋會(huì)替記憶買單。如果你也在 Manjaro 或者任何 systemd 發(fā)行版上跑微服務(wù)建議先把 unit 文件的骨架搭好再逐步加上資源配額和健康檢查從能跑進(jìn)化到跑得穩(wěn)、跑得省。這套思路不挑語(yǔ)言、不挑框架只要是 systemd 體系都能直接套用。