譯者丨布加迪

策劃丨徐杰承

老式的單體應(yīng)用程序正逐步被微服務(wù)分解和取代。大大小小的企業(yè)都在進(jìn)行這種轉(zhuǎn)型，但這并不意味著轉(zhuǎn)型就很容易。在企業(yè)進(jìn)行微服務(wù)轉(zhuǎn)型的過程中是存在諸多挑戰(zhàn)的，但有一些選擇可以簡化工作。

轉(zhuǎn)型原因

企業(yè)向微服務(wù)轉(zhuǎn)型出于幾個(gè)原因。一個(gè)應(yīng)用程序被分解成小塊后，測試起來更容易、部署起來更快速。這種模塊化還為開發(fā)人員和團(tuán)隊(duì)帶來了范圍更明確的職責(zé)。

然而，即使最積極、最能干的公司也需要關(guān)注以下幾個(gè)重要的問題，才能確保成功轉(zhuǎn)型：

• 在重寫大量代碼時(shí)如何保持質(zhì)量？
• 如何理解所有活動組件？
• 如何觀察自己的環(huán)境？
• 如何監(jiān)測影響？

這些問題的答案歸結(jié)為兩大方面：可觀察性和監(jiān)測。雖然許多開發(fā)人員將兩個(gè)術(shù)語混為一談，但兩者之間還是存在一些細(xì)微的差別的。

可觀察性首先出現(xiàn)在整條鏈路中。系統(tǒng)或應(yīng)用程序必須是可觀測的，之后才能被監(jiān)測。實(shí)際上，這意味著需要安裝操作系統(tǒng)層面的服務(wù)或代理，而對應(yīng)用程序而言，則需要公開端點(diǎn)。一旦公開了關(guān)鍵信息，就可以對其進(jìn)行監(jiān)測。監(jiān)測告訴您哪些內(nèi)容損壞了（或即將損壞）、以及其中的損壞原因。

注意事項(xiàng)

從單體架構(gòu)向微服務(wù)轉(zhuǎn)型應(yīng)對用戶透明。為了實(shí)現(xiàn)這個(gè)目標(biāo)，您的監(jiān)測系統(tǒng)需要考慮一些關(guān)鍵問題。

• 是否可以通過提供足夠的正常運(yùn)行時(shí)間和可用性，滿足客戶的需求？
• 應(yīng)用程序響應(yīng)速度是否夠快？
• 發(fā)現(xiàn)問題并排除問題需要多久？
• 開發(fā)人員如何管理變更？

不妨讓我們更詳細(xì)地了解以一下這些問題、以及如何應(yīng)對它們：

1. 是否可以通過提供足夠的正常運(yùn)行時(shí)間和可用性，滿足客戶的需求？

在大多數(shù)情況下，對于目前的單體應(yīng)用程序，您已經(jīng)有了這個(gè)問題的答案。接下來將介紹的是面向客戶的應(yīng)用程序的正常運(yùn)行時(shí)間，以及部署或計(jì)劃外中斷導(dǎo)致的停機(jī)時(shí)間。

就微服務(wù)而言，跟蹤正常運(yùn)行時(shí)間與單體程序很相似，但在開發(fā)“關(guān)鍵路徑”微服務(wù)時(shí)需要確定更多的數(shù)據(jù)點(diǎn)。比如說，如果將登錄邏輯提取為單獨(dú)的微服務(wù)，前端微服務(wù)的可用性可能會上升。然而，登錄服務(wù)停機(jī)時(shí)間將對您的用戶產(chǎn)生重大影響。

換句話說，這個(gè)問題的答案對于微服務(wù)來說比較復(fù)雜，但是適當(dāng)?shù)墓ぞ吆蛷氖贾两K跟蹤請求的能力將幫助您實(shí)現(xiàn)這一目標(biāo)。

2. 應(yīng)用程序響應(yīng)速度是否夠快？

在單體應(yīng)用程序中，活動組件更加靠近——所有組件都在同一環(huán)境中。但在微服務(wù)中，由于請求不再通過單體應(yīng)用程序來傳輸，而是可能向不同的微服務(wù)生成多個(gè)請求，因此向分布式微服務(wù)轉(zhuǎn)型將影響應(yīng)用程序的響應(yīng)能力。

為了解決這個(gè)問題，您需要監(jiān)測自己的應(yīng)用程序和基礎(chǔ)設(shè)施，專注于監(jiān)測技術(shù)管理結(jié)構(gòu)中的智能化和可視化。通過獲取從請求到結(jié)果的指標(biāo)，并通過多個(gè)微服務(wù)和系統(tǒng)對其進(jìn)行跟蹤，能夠?yàn)槟峁┧璧囊娊夂痛鸢浮?/span>

3. 發(fā)現(xiàn)問題并排除問題需要多久？

單體應(yīng)用程序中的一個(gè)重大問題可能會使整個(gè)系統(tǒng)陷入停頓。然而，當(dāng)系統(tǒng)建立在解耦和模塊化的微服務(wù)架構(gòu)上時(shí)，其中的問題可能是潛伏性的，這將更加難以發(fā)展。

快速識別問題的能力需要可觀察性和監(jiān)測的共同支持。因此，微服務(wù)的組件需要可觀察性，以便對其進(jìn)行監(jiān)測。而在出現(xiàn)問題時(shí)，需要警告提供詳細(xì)信息，以縮短排除和解決故障的時(shí)間。比如說，沒有其他信息的“CPU使用率高”警報(bào)幾乎沒有用處。但如果警報(bào)顯示“在X時(shí)間段內(nèi)系統(tǒng)上的CPU使用率持續(xù)保持高位”，并有能夠顯示過去幾分鐘內(nèi)進(jìn)程使用大量CPU資源的視圖。這種警報(bào)會大大縮短解決故障的時(shí)間。

4. 開發(fā)人員如何管理變更？

開發(fā)人員的情緒可能難以衡量，但這非常重要。減員在企業(yè)生命周期的任何階段都是一種風(fēng)險(xiǎn)，尤其是當(dāng)您正在進(jìn)行重大轉(zhuǎn)型時(shí)，減員對企業(yè)的影響將更加顯著。

解決這個(gè)問題的最簡單方法是，是通過與相關(guān)團(tuán)隊(duì)進(jìn)行非正式對話，或者對開發(fā)人員進(jìn)行較正式的調(diào)查。即便您開發(fā)團(tuán)隊(duì)中的大部分人都感受到了單體架構(gòu)的弊端，并希望進(jìn)行這種轉(zhuǎn)型，但了解團(tuán)隊(duì)中每個(gè)開發(fā)人員的想法仍非常重要。

工具幫助

工具很重要，這點(diǎn)毫無疑問。工具有助于確定和衡量服務(wù)級別指標(biāo)（SLI)，這些指標(biāo)會影響您的服務(wù)級別目標(biāo)（SLO）。借助良好的工具，您可以實(shí)現(xiàn)快速的啟動運(yùn)行，并減少麻煩。

向微服務(wù)轉(zhuǎn)型應(yīng)該會對您的SLI/SLO帶來積極的影響，但若要做到胸有成竹，唯一的辦法是借助良好的可觀察性、更好的監(jiān)測，以及對環(huán)境整體的了解。

自建or開源

決定使用哪些工具時(shí)，許多企業(yè)的本能反應(yīng)是自己搞。畢竟，沒有人比自己的開發(fā)人員或SRE團(tuán)隊(duì)更了解本企業(yè)的可觀察性和監(jiān)測需求？事實(shí)上，“自己搞”工具（尤其是要做到有效和準(zhǔn)確）困難重重，且容易出錯(cuò)。大多數(shù)選擇自己開發(fā)工具的企業(yè)，都會后悔走這條艱難的道路。

另外的選擇是走開源路線。Prometheus + Jaeger + Grafana架構(gòu)可滿足您在轉(zhuǎn)型期間的大部分需求。

在這種架構(gòu)中，您將使用安裝在系統(tǒng)上或作為庫包含在應(yīng)用程序代碼中的Prometheus客戶端?？蛻舳瞬东@指標(biāo)后將其公開，供Prometheus服務(wù)器抓取并存儲在時(shí)序數(shù)據(jù)庫中。

Jaeger執(zhí)行分布式跟蹤，為通過微服務(wù)系統(tǒng)的事務(wù)捕獲指標(biāo)和數(shù)據(jù)。

同時(shí)，Grafana與Prometheus和Jaeger數(shù)據(jù)源一起提供可視化和儀表板。

這種開源架構(gòu)讓您有機(jī)會根據(jù)需要來修改和配置工具。它還可能直接支持一些基本的使用場景。當(dāng)然其缺點(diǎn)是，對于每個(gè)工具，您都需要緊跟版本，更新安全補(bǔ)丁及配置變動。此外，開源解決方案常常會在以后帶來擴(kuò)展方面的難題。隨著更多微服務(wù)不斷構(gòu)建，管理軟件和存儲遙測數(shù)據(jù)的成本都會上升。因此在選擇工具時(shí)，建議企業(yè)還是要從自身需求角度出發(fā)。

總結(jié)

當(dāng)企業(yè)從單體架構(gòu)像微服務(wù)轉(zhuǎn)型時(shí)，所面臨的挑戰(zhàn)是確保順利轉(zhuǎn)型，同時(shí)自始至終保持（或提高）應(yīng)用程序的質(zhì)量。而在這個(gè)過程中，可觀察性和監(jiān)測是保持質(zhì)量的關(guān)鍵。