你認為微服務架構能為你帶來什麼？難道微服務真的是一勞永逸的嗎？又或者，難道微服務的威力並不如傳聞所言？微服務架構應當如何設計才能真正彰顯它作為一種解決方案的好處呢？

文章速覽：

l 誤解一：微服務可以解決你的所有問題

l 誤解二：微服務降低了複雜性

l 誤解三：一種架構適用一切

l 誤解四：微服務主要是一種技術

l 誤解五：微服務允許團隊使用他們喜歡的技術

l 對微服務的誤解不止於此

一、誤解一：微服務可以解決你的所有問題

很多公司認為： “我們擁有這樣的應用程式架構，而微服務就是答案，”Redis的合作伙伴解決方案架構師Lars Rosenquist說道：“ 但首先，你需要了解什麼是微服務；接下來，你需要了解你自己應用程式架構的問題；然後兩者之間需要有一個匹配，而這種匹配並不常見 。 ”

 

許多技術解決的是特定規模的特定問題 。 “如果你像Netflix這樣的公司，你的應用程式消耗了網際網路流量的三分之一，你必須對你的架構進行一些調整才能使其正常執行，”Rosenquist解釋說：“但如果你是一個規模較小的公司，比如一家地方銀行，你的運營規模並不大，所以你不需要解決那個問題。人們經常會對他們期望解決的問題進行最佳化，而不一定是針對他們真正面臨的問題。”

人們經常針對他們 想象的問題 進行最佳化，而不一定針對他們 遇到的問題 。

——拉爾斯·羅森奎斯特

Redis 合作伙伴解決方案架構師

大多數情況下不需要使用微服務 。幾位程式設計專家建議，應避免 “單體應用是過時的做法”的觀念。

二、誤解二：微服務降低了複雜性

事實上，微服務架構幾乎總是會增加複雜性 。更糟糕得是，如果不加以控制，它就會變成一個分散式的獨立結構 ——甚至混亂不堪。

 

1.微服務不能解決系統設計問題。

“如果您無法建立具有高內聚和低耦合的整體設計，那麼您在微服務方面的表現可能會更差，”iDIA 計算公司的軟體開發顧問George Dinwiddie 說道。

 

從一個單體應用開始，然後隨著團隊的增加，應逐漸將服務從中分離出來，這是一些建議的做法。 康威法則適用於這種情況。

 

“透過單一應用程式，您可以將所有邏輯、通訊和複雜性集中在一個應用中”Rosenquist 表示，“透過微服務，你可以徹底改變這一點。” 結果就是：所有這些通訊模式現在都成為您的基礎設施的一部分。

 

 

羅森奎斯特認為， 許多公司並沒有真正理解這個問題。他們認為可以透過微服務消除複雜性。但實際上你並沒有消除複雜性，您只需將它移到了不同的抽象層。

 

"比如說，你有兩個應用元件相互通訊。它們存在於同一個應用程式、同一個程式、同一個CPU中。這個應用程式相當快，而且不太容易出現故障," 羅森奎斯特表示。但是，使用微服務後，你將這些應用元件放在不同的機器上，它們之間有網路，一整套基礎架構，甚至可能位於不同的雲上。"這將成為一個完全不同的挑戰，不僅涉及通訊和故障模式，還涉及效能方面的問題。"

 

2.複雜性使應用程式的除錯變得更加困難。

雖然微服務方法確實使你的程式碼更簡單，但羅森奎斯特指出，當涉及部署或管理時，它並不總是更容易 。 "現在你不僅需要除錯一個應用程式，還需要除錯六個或十個應用程式。這些應用程式還在多個例項上執行，它們也在整個架構上進行負載均衡。" 為了整合所有這些，要注意諸如日誌聚合和可觀察性之類的事項，所有這些通常比擁有單個應用程式更復雜。

 

3.程式碼更簡單並不一定意味著系統更簡單。

“從程式碼的角度來看，在孤島中更容易理解單獨的服務，” Redis 開發人員增長負責人William Johnston指出。“但是使用微服務建立的系統的複雜性比獨立系統要複雜得多。”

這也意味著需要更多的開發時間，尤其是對於已經超負荷的小團隊。但這並不總是壞事，因為它迫使開發人員瞭解應用程式領域和整個系統。從長遠來看，這可以使重構變得更加容易，因為它使整個系統的耦合度降低。不過，這會帶來高昂的成本，並且開發人員的生產力可能會大幅下降。

 

4 .影響質量保障 。

通常，一個微服務牽連著很多的依賴關係，以至於更難測試。 對於需要在緊迫的期限內完成任務或不能快速採用該技術的團隊來說，很難總是慢慢來。 “對於一小部分工程師或不熟悉它的團隊來說，這是一種完全不同的運營方式，令人無從下手”波士頓地區初創公司的軟體工程師 John Obelenus 表示。

三、誤解三：一種架構適用於一切

不要誤以為你可以採用一種架構並將其應用到整個應用程式中。也不要認為你可以立即開始重構舊應用程式。正如羅森奎斯特說，您的舊應用程式可能不支援這些模式。  

 

要區分單體應用、微服務和函式。 一個函式只做一件事。 Rosenquist 表示，它們確實適用於特定架構，因為它們受事件驅動。情況就是如此，尤其是企業流程。如果你分解你所有的系統，最終將產生大量元件，這樣您將失去所有的優勢。

 

最適合的方法實際上取決於特定的用例 。例如，銀行很可能會有相當多的單體應用， Rosenquist說。“但是，如果您檢視為移動銀行應用程式提供支援的最普通的應用程式，您會發現這是微服務——大約 50% 到 60%。其餘部分由函式組成。因此， 一個典型的企業最終會在架構方面出現多樣化的情況，而不是單一的 。 ”

 

歸根結底，這實際上取決於構建軟體的人 。約翰斯頓說： “無論您使用什麼軟體架構或模式，優秀的工程團隊都會找到一種有效的方法，而不稱職的團隊會找到一種方法把事情搞砸，無論是微服務、單體應用還是其他任何東西”。  

四、誤解四：微服務主要是一種技術

“ 關於微服務最常見的誤解之一是它們解決了技術問題 ， ”約翰斯頓說。“ 但它們實際上解決了業務或組織的可擴充套件性問題 。 ” 如果微服務不能實現這一目標，那就是浪費時間，而不是技術的錯。

 

"我看到很多人在開始一個新的應用程式時，即使是作為一個大型企業的一部分，他們認為他們需要從分離領域入手，從微服務開始，" Johnston指出。" 但如果您沒有明確定義的業務領域，您不應該從微服務開始 。 "

 

再次引用康威定律，軟體架構中的通訊模式模仿整個組織的通訊模式 。 Rosenquist 說：“假設您想從單體架構轉向微服務架構，看看你的組織架構是怎樣的。例如，拆分團隊以確保一個微服務屬於一個團隊。” 這是一個管理問題，而不是技術挑戰。

確保每個人都瞭解微服務是什麼，以及如何使用這項技術來解決業務問題。不同部門通常對微服務的性質有不同的觀點。採用微服務架構的優勢將取決於問題領域和採用該技術的團隊。

五、誤解五：微服務允許團隊使用他們喜歡的技術

微服務的一個常見好處是每個人都可以使用他們喜歡的語言、工具和平臺 。約翰斯頓說， “如果您有一個非常大的組織，有多個團隊分佈在世界各地，那麼一些團隊可能擅長.NET，而另一些團隊則擅長Java。然後，根據其特定服務的業務領域，使用一種技術可能比使用另一種技術更有利。” 但是，他警告說 ， 對額外開發環境的支援是以系統複雜性增加為代價的 。 “這就是企業架構師存在的原因，”約翰斯頓說。“他們需要了解系統的複雜性。”

 

"是的，你可以為每個微服務選擇不同的技術，但我真的建議你不要這麼做，"Rosenquist 建議。“如果你有 500 個微服務，那麼你不應該有 500 種不同的技術。大約5個會是更好的數字。” 當然，這些只是例子；沒有一種通用的方法。要理性思考，找到可管理和不會阻礙開發人員的平衡點。

六、對微服務的誤解不止於此

以上是一些較為普遍的對微服務的誤解，但不止於此，我們的專家還提出了其他一些關於微服務的誤解：

l 微服務可以加快速度 ： “ 由於網路跳數的增加，微服務可能會導致速度變慢 。您必須接受最終一致性，而在其他型別的應用程式中則不一定需要這樣做， ”Johnston 解釋道。

l 微服務實際上很小 ：技術諮詢公司 Archium 的聯合創始人 Graham Lea 表示，不要迷失於微服務中的“微”。“微服務應該比整體更小，但理想情況下，服務封裝了一箇中等規模的領域。” 小是一個相對術語，但努力讓它們變得很小並不是重點 。

l 每 種客戶端型別都需要一個微服務 ： “沒有人自覺如此，但他們一直這樣做！” Blue Herring 諮詢公司的 DevOps 架構師 Mark W. Schumann 說道。“相反，考慮根據不同的業務資源型別建立微服務。”

 

你是否有這樣的誤解呢，如果沒有，那麼恭喜您，你自己也是一位專家。但如果你有，也不要感到難過，你並不孤獨。我們希望您現在能夠更加自信地前進，在公司中以更權威的方式談論這個話題，並享受微服務可以提供的好處。