5個規則，確定你的微服務優化運作

微服務已經成為一大趨勢，在本文中将介紹微服務面臨的5種常見挑戰并分别給予解決方案，比如如何監控所有微服務、如何找到問題的根源、如何進行版本管理等，幫助你優化運作你的微服務，趕緊戳文看噜！

最近幾年好像大家都開始對微服務着迷，與此同時單體架構也在慢慢淡出人們的視線。

當然，熱門的趨勢總是來來去去，而且它們所受到的關注往往被媒體誇大了，實際情況并不總是如此。不過，對于微服務來說，人們似乎已經達成共識，認為這個趨勢會一直存在下去。這是有道理的。從概念的角度來說，微服務擴充了工程師們幾十年來采用的相同原則。

一旦你開始使用微服務架構，也許你需要本文中提到的5個規則，幫助你成功運作它們。

微服務的另一面

關注點分離(SoC)是一項設計原則，規定軟體的建構應根據 "關注點 "或總體功能來确定不同的部分，30多年來一直被用來決定如何建構技術。在單體應用中，它展現在典型的3層架構中的表現層、業務層和資料層的分離。

微服務采用了這個概念，并将其颠覆。它們将同一個應用程式以這樣的方式分離出來，應用程式的單一代碼庫可以被分解并單獨部署。這樣做的好處是巨大的，但也是有代價的，通常展現在時間和金錢兩方面的運維成本較高。除了将現有的應用程式過渡到容器所帶來的巨大的前期投資之外，維護該應用程式也帶來了新的挑戰。

挑戰1：似乎很難監控整體

雖然單體應用程式也有其自身的挑戰，但在單體中復原一個“壞”版本的過程是相當簡單的。在容器化應用中，事情就變得複雜許多。無論你是将單體應用逐漸分解為微服務，還是從頭開始建構一個新系統，你現在都有更多的服務需要監控。其中每一個都可能會：

• 使用不同的技術和/或語言。
• 運作在不同的機器和/或容器上
• 使用K8s或類似的技術進行容器化和編排

随之而來的是，系統變得高度分散，更需要集中監控。遺憾的是，這也意味着需要監控的東西也多了起來。以前隻有一個單體程序，而現在可能有幾十個容器化程序運作在不同的區域，有時甚至是不同的雲。這意味着不再有一套單一的運維名額來統治它們，IT/運維團隊可以用它來評估應用程式的一般正常運作時間。取而代之的是，團隊現在必須處理數以百計（甚至數以千計）的名額、事件和告警類型，他們需要從中分離出有效信号和無效噪音。

解決方案

DevOps監控需要從扁平化的資料模型轉向分層模型，在這種模型中，可以随時觀察到一系列進階系統和業務KPI。隻要有一點偏差，團隊就必須能夠進入名額層次結構，檢視幹擾來自于哪個微服務，并從那裡了解實際發生故障的容器。這很可能需要從資料存儲和可視化的角度重新調整DevOps工具鍊。開源的時序DB工具，諸如Prometheus和Grafana 7.0等使得這個目标非常容易實作。

挑戰2：跨服務日志記錄

在談論監控應用程式時，首先要提出的事情之一是：日志、日志、日志。伺服器每天都會産生的IT日志相當于碳的排放量，最終導緻溢出的硬碟驅動器以及瘋狂攝取、存儲和工具成本。即使采用單體架構，你的日志也可能已經使你的工程師有些頭疼。

使用微服務，日志變得更加分散。一個簡單的使用者業務現在可以通過許多服務進行，所有這些服務都有自己的日志記錄架構。要解決問題，你必須從業務可能通過的所有服務中提取所有不同的日志，以了解問題所在。

這裡的主要挑戰是了解單個業務如何在不同服務之間“流動”。為了實作這一點，需要對傳統的單體程式在順序業務執行期間通常如何記錄所有事件的方式進行大量修改。盡管已經出現了許多架構來幫助開發人員進行處理（我們特别喜歡Jaeger的方法），但對于希望将單體重構為微服務的企業而言，轉向異步、跟蹤驅動的日志記錄仍需要付出艱巨的努力。

挑戰3：部署一項服務會破壞另一項服務

單片機世界中的一個關鍵假設是，所有代碼都是在同一時間部署的，這意味着應用程式處于最脆弱狀态的時間範圍是一個已知的、相對較短的時間段（即部署後的前24-48小時）。在微服務的世界裡，這個假設不再成立：由于微服務本質上是互相交織的，其中一個服務細微的變更可能會導緻行為或性能問題，而這些問題會在另一個服務中展現出來。是以所面臨的挑戰是，目前出現故障的微服務使得另一個開發團隊并沒有預料到他們的代碼會出現中斷。這既會導緻整個應用意外的不穩定性，也會導緻一些組織内部的摩擦。雖然微服務架構可能讓部署代碼的過程變得更容易，但實際上卻讓部署後驗證代碼行為的過程變得更難。

企業必須建立共享的釋出月曆，并且每當部署相關的微服務時，都要配置設定資源用于密切測試和監控整個應用的行為。在沒有跨團隊協調的情況下部署新版本的微服務，就像牛油果加吐司一樣，是解決這一挑戰的成功秘訣。

挑戰4：難以找到問題的根本原因

在這一點上，你已經鎖定了有問題的服務，提取了所有需要提取的資料，包括堆棧跟蹤和日志中的一些變量值。你可能還有一些APM解決方案，比如New Relic、AppDynamics或Dynatrace。從那裡，你會得到一些額外的資料，關于一些相關方法的異常高處理時間。但是......問題的根本原因呢？

你（希望）從日志中得到的前幾位變量資料很可能不會是那些移動針的資料。它們通常更像是面包屑，指向下一條線索的方向，而不是更進一步的原因。在這一點上，我們需要盡我們所能，發掘出更多應用程式下的 "魔力"。傳統上，這需要發出關于每個失敗事務狀态的詳細資訊（即到底為什麼失敗）。這裡的挑戰是，需要開發人員具有巨大的預見性，以知道他們需要哪些資訊來提前排除問題。

當微服務中的錯誤根源橫跨多個服務時，制定一個集中的問題根源檢測方法至關重要。團隊必須考慮需要哪些資訊顆粒來診斷未來的問題，以及它們應該在什麼層級上發出日志，以考慮到性能和安全因素——這是一座高高的山，而且是一座永無止境的山。

挑戰5：版本管理

我們認為值得強調的問題是，從典型的單體架構中的層模型過渡到微服務的圖模型。由于超過80％的應用程式代碼通常是第三方代碼，是以在公司的不同微服務之間管理第三方代碼的共享方式成為避免陷入前所未有的“依賴地獄”的關鍵因素。

考慮這樣一種情況：一些團隊在使用第三方元件或共享執行個體程式的X.Y版本（幾乎所有公司都有），而其他團隊則使用X.Z版本。這就增加了由于不同版本之間缺乏相容性而産生的關鍵軟體問題的風險，或者說，不同版本之間行為的輕微變化，可能會導緻需要排查最特異和痛苦的軟體bug。

而在這一切之前，我們還要提醒自己，任何一個微服務使用第三方代碼的舊版本、更脆弱的版本，都會産生安全問題——這是黑客的天堂。允許不同的團隊在孤島般的repo中管理他們的依賴性，在單體世界中可能是可行的，但在微服務架構中，這是絕對不可以的。

公司必須在重新設計他們的建構流程方面進行投資，以便為第三方和共享實用程式代碼利用集中式artifact倉庫（Artifactory将是其中之一）。團隊應該隻允許将自己的代碼存儲在單獨的倉庫中。

最後的思考

與科技行業的大多數進步一樣，微服務采用了一個熟悉的概念，并将其颠覆。它們重新思考了大規模應用的設計、建構和維護方式。它們帶來了許多好處，但也帶來了新的挑戰。當我們把這五個主要挑戰放在一起看時，我們可以看到它們都源于同一個理念。是以，每當采用像微服務這樣的新技術時，底線是既需要重新思考，也需要重新調整代碼的建構、部署和觀察方式。微服務所帶來的優勢是難以拒絕的——但風險也是巨大的。