當微服務是個壞主意時 這篇文章可能是給大家潑冷水,請各位理性看待。從書面上看,微服務聽起來很好。它們是模塊化、可擴展和容錯的。很多公司使用這種模式取得了巨大的成功,所以微服務可能自然而然地成為卓越的架構和啟動新應用程式的最佳方式。然而,大多數利用微服務取得成功的公司並不是從微服務開始的。考慮一下Ai ...
當微服務是個壞主意時
這篇文章可能是給大家潑冷水,請各位理性看待。從書面上看,微服務聽起來很好。它們是模塊化、可擴展和容錯的。很多公司使用這種模式取得了巨大的成功,所以微服務可能自然而然地成為卓越的架構和啟動新應用程式的最佳方式。然而,大多數利用微服務取得成功的公司並不是從微服務開始的。考慮一下Airbnb和Twitter的例子,它們在超越了它們的單體後走了微服務路線,現在正在與它的複雜性作鬥爭。即使是使用微服務的成功公司,似乎也仍在摸索使其發揮作用的最佳方式。很明顯,微服務有其自身的權衡因素。 從單體遷移到微服務也不是一件簡單的事情,而創建一個未經測試的產品作為一個新的微服務則更加複雜。只有在評估了其他路徑之後,才應該認真考慮微服務。
微服務只對成熟的產品可行
關於從微服務設計開始的話題,Martin Fowler洞察:
1. 幾乎所有成功的微服務故事都是從一個單體開始的,這個單體變得太大,被分解了。
2. 幾乎所有的案例都是以微服務系統的形式從頭開始構建的,最後都陷入了嚴重的麻煩。
這種模式導致很多人認為,你不應該用微服務開始一個新的項目,即使你確信你的應用會足夠大,使它值得。
第一個設計很少是完全優化的。任何新產品的前幾次迭代都是在尋找用戶真正需要的東西。因此,成功的關鍵在於保持敏捷,並且能夠快速地改進、重新設計和重構。在這一點上,微服務顯然比單體差。如果你沒有搞定最初的設計,你就會有一個艱難的開始,因為重構一個微服務比重構一個單體要難得多。
你是一個初創企業還是在做一個新建項目?
作為一個初創企業(在這種經濟環境下不太可能),你已經在與時間賽跑,在下一個壞事發生之前尋找突破口。你現在不需要可擴展性(可能在幾年內也不需要),那麼為什麼要使用複雜的架構模型來忽視你的客戶呢?
在從事新建項目時,也可以提出類似的論點,因為新建項目不受早期工作的限制,因此沒有任何決策的依據。《構建微服務:Designing Fine-Grained Systems》一書的作者Sam Newman表示,用微服務來構建一個新建項目是非常困難的。
仍然相信,對現有的 "新 "系統進行分區要比對一個新的、新系統進行分區容易得多。你有更多的工作可以做。你有可以檢查的代碼,你可以與使用和維護該系統的人交談。你也知道 "好 "是什麼樣子的--你有一個可以改變的工作系統,使你更容易知道什麼時候你可能弄錯了什麼,或者在決策過程中過於激進。
微服務並不適合在企業內部使用
由於所有的移動部件,微服務部署需要強大的自動化。在正常情況下,我們可以依靠持續部署管道來完成工作--開發人員部署微服務,客戶只需線上使用應用程式。這對於內部部署的應用程式來說是不可行的,因為開發人員會發佈一個包,而客戶則需要在他們的私有系統上手動部署和配置一切。微服務使所有這些任務變得特別有挑戰性,所以這是一個與微服務架構不相稱的發佈模式。說白了,開發一個內部微服務應用程式是完全可行的。。然而,正如我們一路走來所意識到的,有幾個挑戰需要剋服。在決定採用內部部署的微服務之前,請考慮以下幾點:
1.企業內部微服務的版本管理規則更為嚴格。你必須跟蹤參與發佈的每個單獨的微服務。
2.你必須進行徹底的集成和端到端測試,因為你不能在生產中測試。
3.如果不能直接進入生產環境,微服務應用程式的故障排除就會變得更加困難。
你的單體可能還有生命力
每個軟體都有一個生命周期。你可能會因為一個單體的老舊和它的併發症而想把它廢掉。但是扔掉一個正在工作的產品是一種浪費。只要稍加努力,你也許能從你目前的系統中再擠出幾年好時光。
有兩個時刻,似乎微服務是唯一的出路:
1. 糾結的代碼庫:很難在不破壞其他功能的情況下進行修改和添加功能。
2. 性能:你在擴展單體方面有困難。
模塊化的單體
開發人員希望避免使用單體的一個常見原因是,單體有惡化成代碼糾結的傾向。當我們走到這一步的時候,增加新的功能是很有挑戰性的,因為所有的東西都是相互聯繫的。
但是,單體不一定是一團糟。以Shopify為例:他們擁有超過300萬行的代碼,是世界上最大的Rails單體之一。有一次,該系統發展得如此之大,給開發人員帶來了很多麻煩。
該應用程式非常脆弱,新的代碼會產生意想不到的影響。一個看似無害的改變可能會引發一連串不相關的測試失敗。例如,如果計算運費的代碼被調用到計算稅率的代碼中,那麼改變我們計算稅率的方式可能會影響運費計算的結果,但可能並不明顯。這是高度耦合和缺乏邊界的結果,這也導致了測試難以編寫,而且在CI上運行非常緩慢。
Shopify沒有將他們的整個單體重寫為微服務,而是選擇了模塊化作為解決方案:
模塊化有助於設計更好的單體和微服務。如果沒有精心定義的模塊,我們要麼落入傳統的分層單體(大泥球),要麼更糟糕,成為分散式單體,結合了單體和微服務的最糟糕的特征。
模塊化是一項大量的工作,這是事實。但它也增加了大量的價值,因為它使開發更直接。新的開發人員不必在開始修改之前瞭解整個應用程式。他們一次只需要熟悉一個模塊。模塊化使一個大的單體感覺很小。
模塊化是過渡到微服務前的一個必要步驟,它可能是比微服務更好的解決方案。模塊化單體與微服務中一樣,通過將代碼分割成獨立的模塊,解決了糾結的代碼庫問題。與微服務不同的是,微服務的通信是通過網路進行的,而單體中的模塊則是通過內部API調用進行通信。
分層與模塊化的單體。模塊化單體與微服務架構的許多特征相同,但沒有最困難的挑戰
單體可以擴展
關於單體的另一個誤解是它們不能擴展。如果你遇到了性能問題,並認為微服務是唯一的出路,請再想想。Shopify已經向我們展示了健壯的工程可以使單體在一個令人難以置信的規模上工作。
架構和技術棧將決定如何優化單體;這個過程幾乎無一例外地從模塊化開始,並可以利用雲技術進行擴展。
部署單體的多個實例,並使用負載均衡來分配流量。
使用CDN分佈靜態資產和前端代碼。
使用緩存來減少資料庫的負載。
用邊緣計算或無伺服器功能實現高需求的功能。
如果它在工作,就不要修複它
如果我們用隨著時間推移實現的增值功能的數量來衡量生產力,那麼在生產力很強的情況下,轉換架構就沒有什麼意義。
由於維護開銷的原因,微服務最初是生產力較低的架構。隨著單體的增長,它變得更加複雜,而且更難增加新的功能。微服務只有線上路交叉後才會有回報。
誠然,有些東西最終將不得不改變。但那可能是多年以後的事了,到那時,需求可能已經改變了--誰知道在此期間會出現什麼新的架構模式呢?
布魯克定律和開發人員的生產力
在《人月神話》(1975年)中,小弗雷德-布魯克說:"為一個延期的軟體項目增加人力會使它變得更延遲"。這種情況的發生是因為新的開發人員必須先接受指導,才能在複雜的代碼庫上工作。另外,隨著團隊的壯大,溝通的開銷也在增加。更加難以組織和做出決定。
適用於複雜軟體開發的布魯克定律指出,在一個延期的軟體項目中增加更多的開發人員只會使其花費更長的時間。微服務是減少布魯克定律影響的一種方法。然而,這種影響只有在複雜而龐大的代碼庫中才能看到,因為在這種情況下,我們不能把開發分成不連續的任務。
在使用微服務之前,你必須確定布魯克定律是否會影響你的單體。過早地切換到微服務,不會增加多少價值。
你準備好過渡了嗎?
在你開始使用微服務之前,必須滿足一些條件。在準備好你的單體的同時,你還需要:
1.建立持續集成和持續交付以實現自動部署。
2.實施快速配置,按需構建基礎設施。
3.瞭解雲原生技術棧,包括容器、Kubernetes和無伺服器。
4.熟悉領域驅動設計、測試驅動開發和行為驅動開發。
5.重組團隊,使之成為跨職能的團隊,消除孤島,扁平化層次,以便於創新。
6.培養一種DevOps文化,使開發人員和運營工作之間的界限變得模糊。
7.改變一個組織的文化可能需要幾年時間。學習所有的知識需要幾個月的時間。如果沒有準備,向微服務的過渡是不可能成功的。
結論
我們可以用一句話來總結關於向微服務過渡的整個討論:除非你有充分的理由,否則不要這樣做。那些在沒有準備和沒有堅實設計的情況下開始微服務之旅的公司將有一個非常艱難的過程。在考慮將微服務作為一種選擇之前,你需要實現關鍵的工程文化和伸縮特性。同時,如果你的系統表現良好,而且你還在以適當的速度開發功能,為什麼要改變呢?
今天先到這兒,希望對雲原生,技術領導力, 企業管理,系統架構設計與評估,團隊管理, 項目管理, 產品管理,團隊建設 有參考作用 , 您可能感興趣的文章:
領導人怎樣帶領好團隊
構建創業公司突擊小團隊
國際化環境下系統架構演化
微服務架構設計
視頻直播平臺的系統架構演化
微服務與Docker介紹
Docker與CI持續集成/CD
互聯網電商購物車架構演變案例
互聯網業務場景下消息隊列架構
互聯網高效研發團隊管理演進之一
消息系統架構設計演進
互聯網電商搜索架構演化之一
企業信息化與軟體工程的迷思
企業項目化管理介紹
軟體項目成功之要素
人際溝通風格介紹一
精益IT組織與分享式領導
學習型組織與企業
企業創新文化與等級觀念
組織目標與個人目標
初創公司人才招聘與管理
人才公司環境與企業文化
企業文化、團隊文化與知識共用
高效能的團隊建設
項目管理溝通計劃
構建高效的研發與自動化運維
某大型電商雲平臺實踐
互聯網資料庫架構設計思路
IT基礎架構規劃方案一(網路系統規劃)
餐飲行業解決方案之客戶分析流程
餐飲行業解決方案之採購戰略制定與實施流程
餐飲行業解決方案之業務設計流程
供應鏈需求調研CheckList
企業應用之性能實時度量系統演變
Openshift與Kubernetes的區別
如有想瞭解更多軟體設計與架構, 系統IT,企業信息化, 團隊管理 資訊,請關註我的微信訂閱號:
作者:Petter Liu
出處:http://www.cnblogs.com/wintersun/
本文版權歸作者和博客園共有,歡迎轉載,但未經作者同意必須保留此段聲明,且在文章頁面明顯位置給出原文連接,否則保留追究法律責任的權利。
該文章也同時發佈在我的獨立博客中-Petter Liu Blog。