共計 2557 個字符，預計需要花費 7 分鐘才能閱讀完成。

這篇文章主要介紹“讓生產環境微服務更流暢的方式有哪些”，在日常操作中，相信很多人在讓生產環境微服務更流暢的方式有哪些問題上存在疑惑，丸趣 TV 小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”讓生產環境微服務更流暢的方式有哪些”的疑惑有所幫助！接下來，請跟著丸趣 TV 小編一起來學習吧！

微服務的另一面

關注點分離并不是什么新概念，分布式計算也不是。優勢很明顯，但是它們的代價通常是時間和金錢上更高的運維成本。將這兩者混合在一起，就會遇到所有類型的問題。將其上生產環境，問題會變成四倍。調試修復，但是等一下——

調試并不能讓問題消失。

就像 Bryan Cantrill 在其 QCon 演講里所指出的，“調試已經退化成了口頭傳說，期望問題能夠神話般消失。”事實上，調試更像一門科學，要理解系統是如何工作的，而不是我們認為它是如何工作的。

調試不僅僅是微不足道的邊緣任務，而是個根本性問題。Sir Maurice Wilkes，創造出首批程序之一的調試者，那時候就已經認識到調試會成為開發人員需要承擔的主要職責。

“在開始編程的 1949 年，我們驚訝地發現讓程序像我們認為地那樣工作并不容易。必須找到調試方法。我還能記得那一刻，我意識到從今之后我生命的很大一部分會花在尋找自己編寫的程序的錯誤上。”

我們曾經認為這是為了解決問題。但是實際挑戰是要理解系統到底是如何工作的。

問題 #1：如果監控單體應用還不夠困難

無論你是逐步將單體應用分解成微服務，還是從頭構建一個新系統，現在你都有更多的服務需要監控。每個都很有可能：

使用不同的技術 / 語言

在不同機器 / 容器里

有自己的版本

要點是智慧地監控，系統是高度碎片化的，迫切需要中央化監控和日志，才能夠理解到底發生了什么事情。

比如，在最近持續討論播客描述的一個場景里是需要回滾的差版本。這是單體應用最直接的方式。但是——現在我們有微服務了。因此需要確定哪個服務需要回滾，這樣的回滾對其他服務會有什么影響，或者可能只是需要添加一些功能，但是也可能就直接將問題推到另一個服務里。

要點 #1：如果你認為監控單體架構很難，那么微服務會更難 10 倍，并且需要預先計劃更多的投資。

問題 #2：日志分布在服務間

日志 日志 日志。服務器每天都會產生數 GB 的非結構化文本。IT 界和二氧化碳排放等價的東西，是溢出的硬盤和瘋狂的 Splunk 賬單 /ELK 存儲費用。另外，如果想學習 Splunk 或者 ELK，可以看看我們最新的電子書：《Splunk vs ELK：日志管理工具決策指導》。

在單體架構下，日志很可能已經分散在不同的地方，單體思維里就得使用日志記錄在不同地方的幾層設計。在微服務里 – 日志更加分散。現在當研究一些用戶事務相關的場景時，不得不從所有可能使用到的服務那里將所有的不同日志收集到一起，才能理解什么地方出錯了。

在 Takipi 里，我們的團隊通過使用 Takipi 解決這樣的問題。對于來自生產 JVM 里的所有日志錯誤或者報警，我們在日志里注入了可以指引事件分析的鏈接。包括每一幀完整的 stack trace 和變量狀態，即使它們分布在一定數量的服務 / 機器上。

要點 #2：微服務是指將東西分解成單個組件。這么做的副作用是，運維和監控也隨之分解到每個服務里，并且失去了作為整體的系統的力量。這里的挑戰是使用合適的工具重新將這些中央化。

問題 #3：一個服務導致的問題，會造成其他地方的問題

如果跟蹤某個特定服務的故障事務，你無法保證正在查看的服務就是出問題的地方。假定服務間有一些消息傳遞機制，比如 RabbitMQ、ActiveMQ 或者可能使用的是 Akka。
 

即使服務行為正常，沒有找到什么問題，也可能會發生如下場景：

它接收到的輸入是錯的，那么你需要理解是什么導致前一個服務的異常行為

其結果的接收方返回了一些異常響應，那么你需要理解下一個服務是如何工作的

如果這些依賴條件比 1:1 更加復雜會如何？或者多個服務受益于該問題呢？

無論問題是什么，微服務下的第一步都是要知道從哪里開始尋找答案。數據完全分散，很有可能完全不在日志和儀表盤里。
 

要點 #3：單體應用里，你通常能夠知道檢查的方向是正確的，微服務讓理解問題的來源在哪里，以及應該到哪里得到數據變得更加困難。

問題 #4：找到問題的根本原因

好的，讓我們繼續調查。現在的出發點是我們已經找到了有問題的服務，拿到了需要的數據，從日志里找到了 stack trace 和一些變量值。如果使用的是 APM（就像 New Relic、AppDynamics 或者 Dynatrace，我們也有文章介紹，在這里和這里），你可能還得到其他一些數據，有關一些方法的高速處理時間 / 對問題的嚴重性做了一些基本的評估。

但是——實際問題是什么呢？真正的根本原因？要找到實際出錯的代碼。

大多數情況下，從日志里首先得到的變量數據并不是真正需要的數據。它們通常指到下一個線索，要求你發現更多的真相，并且添加更多的日志聲明。部署變更，期望問題能夠重現，或者不重現，因為——有時候僅僅添加一條日志聲明似乎就能解決問題。

要點 #4：當某個微服務的根本原因影響多個服務時，有可用的中央化根本原因檢測工具至關重要。如果你使用 Java/ 其他 JVM 語言，一定要來看看我們 Takipi 是怎么做的。

Takipi 的錯誤分析儀表盤——每一幀的變量值放在實際代碼之上

問題 #5：版本管理和服務間的循環依賴

持續討論博客里提到的另一個問題是從典型單體架構的單層模型到微服務的圖模型。
 

這里可能發生的兩個問題和依賴有關。

如果在服務間存在循環依賴，當某個事務可能死鎖在循環里時，就會出現溢出錯誤。

如果兩個服務共享某個依賴，并且你以會影響它們的方式更新了其他服務的 API，那么就需要一次更新所有這三個服務。這會帶來這樣的問題，你應該先更新哪個？怎么才能讓這樣的更新平穩過渡？

更多的服務意味著每個服務都有不同的發布周期，大大增加了這里的復雜度。當問題在一個版本消失，在新版本又出現時，重現問題就會很復雜。
 

要點 #5：在微服務架構里，你更容易遇到依賴相關的問題。

到此，關于“讓生產環境微服務更流暢的方式有哪些”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注丸趣 TV 網站，丸趣 TV 小編會繼續努力為大家帶來更多實用的文章！