Sean Kelly是Komad的首席工程師，在去年舉行的波士頓Golang開發者見面會上，他做了一次關于微服務使用體驗的閃電式演講，之后他寫了一篇文章。他以人們應該有所期待的內容作為開場：
我即將講到一些有關微服務的謬論和誤解，有些人堅定地認為對一個遺留的單體應用進行拆分就能挽救局面。我不希望這篇博文的觀點變成“微服務==拙劣”，如果閱讀這篇博文的人有想不明白遷移到微服務是否真正適合他們的話，那么最好請他們離開。
當然，有關微服務的討論都是從試圖定義清楚微服務是什么或不是什么開始的。不過，就像Sean指出的那樣，根本不存在“完美”或被一致認可的定義。
這意味著在實踐過程中，微服務只能在有限的領域發揮作用，所以它在你的架構里只做那些必要的事情，不會超出對它定義的范圍。
大部分微服務開發者使用REST（HTTP）或RPC協議作為微服務內外部的通信手段，導致開發者們認為微服務開發是一件很簡單的事情。
我們只是用某種REST API封裝了領域的一小部分，然后讓它們通過網絡進行交互。
不幸的是，這也恰是Sean想要表達的核心觀點。從他的經驗來看，這會把我們引向五種似是而非的微服務“真相”。首先，它們會讓代碼更干凈。不過不管怎樣，就像他說的，“你不必因為網絡邊界問題的存在才想把代碼寫好”。
事實上，微服務或者其它任何一種用來構建技術棧的手段，都不是寫出干凈或可維護代碼的必要條件。因為涉及的因素少了，寫出糟糕或缺少想法代碼的幾率也跟著減小，這個才是事實的真相。不然的話，等于說通過移除商店櫥窗里的誘人商品就可以降低犯罪率。實際上問題并沒有得到解決，你只是簡單粗暴地舍棄了一些可選的東西。
Sean說更粗粒度的“邏輯”服務架構或許會是更好的方案，至少在剛開始的時候是這樣的。根據Sean的說法，使用這種方案替代微服務的好處之一是它可以減少網絡通信開銷。他還說這種方案與面向服務架構非常類似。那么問題來了：在面向服務架構和微服務架構之間有什么不同點嗎？我們之前也針對這個問題進行過討論。
Sean所說的微服務的第二個“真相”是“目的性簡單的事情容易完成”。
事情在剛開始可能看起來很簡單，但大部分領域（特別是在那些需要構建原型、建立樞紐且要多次重定義領域的初創公司里）并不適合被分割成更小的塊。有些領域經常需要從外部獲取數據來完成內部的工作。如果需要把寫數據的工作委托到領域外部，那么情況會變得更加復雜。一旦沖破自己能夠支配的區域，在請求鏈條里引入第三方來操作數據，那么你就進入了分布式事務的領地（有時也被稱為Sagas）。
好吧，我們得承認Sagas只是分布式事務的一種形式，并非所有的分布式事務都是Sagas！Sean的主要意思是說，把多個遠程服務調用包含在一個請求里會帶來很多復雜性。例如，它們應該被并行調用還是串行調用？錯誤應該如何處理？最近我們就從Alvaro Videla那里聽到一些關于這些復雜性的例子。
Sean所說的第三個“真相”是“微服務比單體更快”。
這點很難撇清楚，因為通過減少工作量或減少啟動依賴項也能夠讓系統快起來。不過這終究是個非正式的結論。我相信正在使用微服務的同僚們能夠看到被分離出去的個體服務代碼確實是快了起來，不過同時也在互相調用間加入了額外的網絡開銷。網絡調用永遠不可能跟本地調用一樣快，雖然通常被認為“足夠”快。
Sean認為，有些人所說的微服務變快，可能是由其它因素導致的，特別是當使用了新的編程語言或新的技術棧進行重構或重新實現。如果這些語言或技術棧被用在原來的單體系統上，或許性能也會得到改善？
第四個“真相”是“開發者可以更容易地在獨立代碼庫上工作”。Sean可能因此得出的結論是“太多的開發者工作在獨立代碼庫上會導致‘不是我的問題’綜合癥”，引入微服務架構可能導致的問題會讓它所帶來的任何一個優勢都黯淡無光。
最大的一個問題是，你必須不斷增加服務數量來完成哪怕很小的一個改動。這意味著你要投入時間和精力為開發者構建和維護一個可以在本地運行所有組件的簡便方案。[…]另外，這也會加大編寫測試用例的難度，編寫一個恰當的集成測試用例要求對所有涉及到的服務調用了如指掌，并且要考慮所有可能出現的錯誤情況。
第五個也是最后一個“真相”——“因為有了Docker，處理自動伸縮變得非常容易”。
為了橫向擴展，把服務打包成相互獨立的單元，然后使用Docker這樣的容器來部署，可以說這是一個不錯的方案。不過，如果說只有在微服務架構里才能這么做那就不對了。其實單體應用也可以使用這種方式。[…]如果微服務在一開始讓你選擇了這種方式，那么你也可以把它應用在單體系統上。
Sean在結束他的演講（博文）之前，討論了開發者應該在什么時候使用微服務。他認為開發者和架構師是否理解自己的工作領域是很重要的，并以此展開討論：
如果你無法理解你所工作的領域，或者還在理解的路上，那么微服務可能帶來的問題會比好處多。如果你對它們有了深入的理解，你就會知道邊界在哪里，就會知道依賴關系是怎樣的，那么微服務會是正確的選擇。
Sean接著討論了理解工作流的重要性（又一個關于分布式事務的問題）。除了理解工作流，能夠對它們進行監控也非常重要，甚至比在單體系統里還要重要，因為你會發現，要精確定位造成性能瓶頸或發生錯誤的微服務會更難。在某種程度上，Sean提出的在使用微服務之前先把架構理解透徹的建議跟過去其他人所說的如出一轍，比如Simon Brown在談論分布式泥球時所說的：
如果你正在構建一個單體系統，而它正在變成一個大泥球，那么也許你該想想是否對自己的軟件架構做了足夠的功課。你是否真正理解它們核心的結構化抽象？它們的接口和責任是否有清晰的定義？如果你還沒有搞清楚這些問題，那么你憑什么認為使用微服務架構會給你帶來好處？當然，雖然物理上的服務分離沒有什么捷徑可走，不過在單體系統組件上應用服務分離也是可以達到預期效果的。
讓我們回到Sean的話題上。基于以上內容，針對人們看待微服務的方式，Sean會給出怎樣的建議？
如果有人問我這個問題，我的建議是構建“內部”服務。通過在代碼里定義清晰的模塊，再根據實際需要把它們歸并到各自的服務里。當然，這樣做不是必需的，它本身也不是壞代碼的靈丹妙藥。但它會讓你的系統走得更遠，跑得更快，然后你可以嘗試逐步往微服務遷移。
查看英文原文：Komad Principal Engineer Sean Kelly on Microservice Fallacies
京公網安備 11010502049343號