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將是其中之一）。團隊應該只容許將本身的代碼存儲在單獨的倉庫中。

最後的思考

與科技行業的大多數進步同樣，微服務採用了一個熟悉的概念，並將其顛覆。它們從新思考了大規模應用的設計、構建和維護方式。它們帶來了許多好處，但也帶來了新的挑戰。當咱們把這五個主要挑戰放在一塊兒看時，咱們能夠看到它們都源於同一個理念。所以，每當採用像微服務這樣的新技術時，底線是既須要從新思考，也須要從新調整代碼的構建、部署和觀察方式。微服務所帶來的優點是難以拒絕的——但風險也是巨大的。