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