生産環境中保持微服務井然有序的五大措施

監控是一種明智的做法。系統會逐漸變得高度碎片化，為了對系統的運作狀況獲得更全面的了解，人們對集中式監控和日志會産生越來越高的需求。

alex談到了在最新一期播客節目中所涉及的一個場景，這個場景中需要對有問題的版本進行復原，這就要确定相應的微服務，并确定進行復原可能會對其他服務産生的影響。他認為：

結論1：如果你認為對單層（monolith）體系結構進行監控已經很困難，微服務的監控要比這個難十倍，需要事先做好極為充分的規劃和更大的投入。

對于第二個問題，alex談到了我們已經從sam newman和adrian cockcroft等人處多次聽到的一種觀點：

單層體系結構的日志檔案很可能已經分散在不同位置，就算心裡想着“單層”，但最終依然可能會使用多個不同技術層，并可能将日志儲存在不同地方。微服務則會讓日志進一步分散。現在如果需要調查有關某些使用者事務的場景，為了了解實際發生的一切，你可能需要從不同位置擷取所有服務的全部日志。

這就産生了他的下一個結論：

結論2：微服務的目标就是将所有東西拆分為零散元件。但這種做法的副作用之一是運維規程和監控工作也需要分别應用給每個服務，進而導緻無法發揮“整體系統”的強大之處。通過恰當的工具以統一方式管理這一切已成為此時最大的挑戰。

第三個問題引述自leslie lamport對于分布式系統的定義中的一句話：“分布式系統是指某台我從未聽說過的計算機也能導緻我的程式崩潰的體系。”或者按照alex的說法：“一個服務引發的問題，會造成其他地方出現連鎖反應。”那麼這個結論也就不言自明了：

結論3：對于單層體系，遇到問題後通常你會知道需要調查哪些方面，微服務使得人們難以确定問題根源以及要從哪裡拿到所需資料。

在分布式系統中，“确定問題根源”這一需求進一步産生了下個問題，此時日志可以提供一定的幫助，但日志隻是解決方案的一部分：

大部分情況下，你寄希望于日志檔案中獲得的前幾位變量資料，但這些可能根本無法解決你的問題。這些資訊隻能讓你繼續追查下一條線索，進而需要進一步深入這樣的“魔法世界”，繼續運作更多日志語句。随後部署改動，期待着問題能夠重制或永不再現，因為… 有時候僅僅添加一條日志語句似乎就能解決問題。這類似于墨菲法則的一次糟糕的大逆轉。

這也産生了我們的下一個結論：

結論4：如果微服務中一個問題的根源涉及到多個服務，就很有必要使用一個集中的根源檢測工具。

alex提到的最後一個問題是版本管理和服務之間的循環依賴。同時他也提到了在檢查依賴性時需要注意的兩個問題。

1，如果服務之間存在循環依賴，一旦某個事務卡在循環中，就很容易産生分布式堆棧溢出錯誤。2，如果兩個服務共享同一個依賴項，并且使用會影響到這些服務的方式更新了其他服務的api，那麼就需要同時對這三個服務進行更新。這就造成了另一種問題，例如：要先更新哪個服務？如何確定所有服務能順利地完成更新？

互相獨立的服務越多意味着可移植性越高，不同服務可以使用互不幹涉的釋出周期，但同時這樣做也會增加整個系統的複雜度，尤其是在可再生性（reproducibility）方面。那麼這就引出了我們的第五個，也是最後一個結論：

結論5：在微服務體系結構中，更容易産生依賴性問題所導緻的錯誤。

很高興看到在生産環境中運用微服務的人就此展開的讨論，更讓人高興的是，很多人已經就其中的一些核心問題和解決這些問題的常見方法達成了一緻。

本文轉自d1net（轉載）