Categories
程式開發

微服務的定義、優缺點和最佳實踐


回顧四五年前,圍繞微服務架構的觀點已經發生了很大的變化。首先,在看到Netflix、亞馬遜和Gilt.com等公司的成功故事後,開發人員認為微服務實際上是應用程序開發的一部分,這是炒作階段。到現在為止,我們已經意識到微服務是另一種架構風格,當它以正確的方式應用於正確的問題時,會取得令人驚訝的成果,但它也有自己的優缺點。

為了了解微服務到底是什麼,什麼時候應該使用它們,什麼時候不應該使用它們,我們採訪了Jaime Buelta,他是Hands-On Docker for Microservices with Python一書的作者。在介紹微服務及其好處的同時,Buelta還分享了一些最佳實踐,如果開發人員決定將他們的單體架構遷移到微服務,那麼他們應該記住這些最佳實踐。

在開始使用微服務之前,Buelta建議在通用軟件架構和Web服務方面打下堅實的基礎。 “在處理微服務及其後續工作時,它們將會非常有用,”他說。

微服務:好處和風險

傳統的單體應用程序將所有的功能都封裝在一個單元中。相反,在微服務架構中,應用程序被劃分為可以單獨部署、升級和替換的小型獨立服務。每個微服務都是針對單個業務目的而構建的,它使用輕量級機制與其他微服務通信。

Buelta解釋說,“微服務架構是一種構建系統的方式,其中,幾個獨立的服務按定義好的方式彼此通信(通常通過Web RESTful服務)。關鍵在於每個微服務都可以獨立更新和部署。”

微服務架構不僅規定瞭如何構建應用程序,還規定瞭如何組織團隊。

他補充道,“雖然通常我們使用所涉及的技術來描述(它),但它也是一種組織結構。每個獨立的團隊都可以完全擁有一個微服務。這使得組織的發展可以不受開發人員衝突的影響”。

微服務的主要好處之一是它可以賦能創新,而不會對整個系統造成太大影響。使用微服務,你可以進行水平擴展、有確定的模塊邊界、使用多種技術進行並行開發。談到與微服務相關的風險時,Buelta說,“採用微服務的主要風險,尤其是當起步於一個單體應用時,是設計的服務不是真正獨立的。這將增加服務間通信的開銷和複雜性。”

他補充道,“從長遠來看,微服務系統的設計需要一個高層次的視角。我對正在朝著這種架構發展的組織的建議是,讓某人負責“大局”。你不想只見樹木不見森林。”

從單體遷移到微服務

著名作家和軟件顧問Martin Fowler建議採用“單體優先”的方法。這是因為,從一開始就使用微服務架構可能存在風險,因為它主要適用於大型系統和大型團隊。

Buelta同意他的觀點,“開始考慮進行這種遷移的主要標準是原來的團隊規模。對於小型團隊來說,這樣做是不值得的,因為開發人員了解所有正在發生的事情,並且可以向​​坐在房間裡的人詢問任何問題。單體在這些情況下效果很好,這就是為什麼幾乎每個系統都是這樣開始的。”這就是亞馬遜的“雙披薩團隊”原則。該原則規定,如果一個負責微服務的團隊兩個披薩都不夠吃,那麼這個團隊就太大了。

“隨著業務和團隊的增長,他們需要更好的協調。開發人員開始經常互相干擾。了解特定代碼段的意圖比較困難。這時候進行遷移,將功能分隔,獲得更好的清晰度,是有意義的。每個團隊都可以設定自己的目標,並且基本上可以獨立工作,暴露出一個清晰的外部接口。但要想讓這一切有意義,就必須有足夠數量的開發人員,”他補充道。

微服務遷移的最佳實踐

當被問及開發人員在遷移到微服務時可以採用哪些最佳實踐時,Buelta說,“微服務架構成功的關鍵是每個服務盡可能獨立。”

Buelta解釋說,“這裡出現的問題是’如何使服務獨立?’發現系統之間的相互依賴關係的最佳方法是從新特性的角度進行思考:如果有一個新特性,是否可以通過修改單個服務來實現?什麼樣的特性需要協調幾個微服務?是常見的需求,還是罕見的需求?沒有哪種設計是完美的,但至少有助於做出明智的決定。”

Buelta建議使用正確的方法做而不是做兩次。他補充道,“一旦遷移完成,就很難對微服務的邊界進行更改。在項目初期投入的時間是值得的。”

從一個架構模式遷移到另一個架構模式是一個很大的變化。我們問他和他的團隊在這個過程中遇到了什麼挑戰,他說,“最困難的挑戰其實是人。它們往往被低估,但轉向微服務實際上改變了人們的工作方式。這可不是件容易的事!”

他補充道,“我遇到過這樣一些問題,比如必須為開發人員提供足夠的培訓和支持。特別是,解釋一些改變背後的根本原因。這有助於開發人員理解,為什麼他們要做出這些讓人感到如此沮喪的改變。”

例如,從單體應用遷移的一個常見抱怨是部署時需要協調,而以前是一次單體發布。這需要更多地考慮如何確保向後兼容和最小化風險。這有時不是很明顯,需要專門說明。 ”

關於選擇Docker、Kubernetes和Python作為技術棧

我們問Buelta,他更喜歡用什麼技術來實現微服務。對於語言,他的回答很簡單:“對我來說,Python是一個非常自然的選擇。這是我最喜歡的編程語言!”

他補充道,“它非常適合這項任務。它不僅可讀性強、易於使用,而且對Web開發也有足夠的支持。除此之外,它還有一個充滿活力的第三方模塊生態系統,可以滿足任何可能的需求。這些需求包括連接到其他系統,如數據庫、外部API等。”

Docker通常被說成是微服務中最重要的工具之一。 Buelta解釋了原因,“Docker允許將應用程序封裝並複製到一個便捷的標準包中。這減少了不確定性和環境複雜性。它極大地簡化了應用程序從開發到生產的過程。它還有助於降低硬件利用率。你可以在同一個物理機或虛擬機中安裝多個具有不同環境、甚至不同操作系統的容器。”

對於Kubernetes,他說,“最後,Kubernetes使我們能夠協調部署多個Docker容器。它迫使你以集群的方式進行思考,同時還需要時刻考慮生產環境。它還允許我們使用代碼定義集群,在文件中定義新的部署或配置更改。所有這些都支持我在這本書中描述的GitOps之類的技術,將完整的配置存儲在源代碼控制系統中。這使得任何更改都是明確的、可逆的,因為它們是常規的Git合併。它還使得從零開始恢復或複制基礎設施變得簡單。”

“Docker和Kubernetes有一定的學習曲線,但是完全值得。兩者都是非常強大的工具。他們適合於避免生產環境崩潰,”他分享道。

關於多語言微服務

微服務允許你使用不同的技術,因為在理想情況下,每個微服務都由一個獨立的團隊處理。

Buelta分享了他對多語言微服務的看法,“多語言微服務很棒!這是它最大的優勢之一。典型的例子是將用某種語言編寫的遺留代碼遷移到另一種語言。可以用一個微服務替換另外一個公開了相同外部接口的微服務,而它們的內部卻完全不同。例如,我已經完成了從舊的PHP應用程序到Python應用程序的遷移。”他補充說,“作為一個組織,同時使用兩個或多個框架有助於更好地理解這兩個框架,以及何時使用其中一個框架。”

雖然使用多語言微服務是一個很大的優勢,但它也會增加運維開銷。 Buelta建議,“不過,需要保持平衡。每次都使用不同的工具,就不能在團隊之間共享知識,這不合理。具體的數字可能取決於公司的規模,但一般來說,超過2或3個應該就需要一個很好的解釋,為什麼需要在技術棧中引入新工具。保持工具在一個合理的水平也有助於分享知識以及如何最有效地使用它們。”

英文原文

Microservices require a high-level vision to shape the direction of the system in the long term