譯者丨布加迪

策劃丨徐杰承

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

轉型原因

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

然而，即使最積極、最能干的公司也需要關注以下幾個重要的問題，才能確保成功轉型：

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

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

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

注意事項

從單體架構向微服務轉型應對用戶透明。為了實現(xiàn)這個目標，您的監(jiān)測系統(tǒng)需要考慮一些關鍵問題。

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

不妨讓我們更詳細地了解以一下這些問題、以及如何應對它們：

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

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

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

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

2. 應用程序響應速度是否夠快？

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

為了解決這個問題，您需要監(jiān)測自己的應用程序和基礎設施，專注于監(jiān)測技術管理結構中的智能化和可視化。通過獲取從請求到結果的指標，并通過多個微服務和系統(tǒng)對其進行跟蹤，能夠為您提供所需的見解和答案。

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

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

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

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

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

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

工具幫助

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

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

自建or開源

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

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

在這種架構中，您將使用安裝在系統(tǒng)上或作為庫包含在應用程序代碼中的Prometheus客戶端。客戶端捕獲指標后將其公開，供Prometheus服務器抓取并存儲在時序數(shù)據(jù)庫中。

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

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

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

總結

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