微服務有什麼好處，它們會為您的業務買單嗎？
已發表: 2022-01-12微服務的概念，一種將軟件應用程序設計為一組小型服務的方法，至少從 2015 年就已經存在。微服務提供諸如組件的獨立部署和可擴展性等好處，如今風靡一時。 這是因為這些微服務優勢轉化為更快的軟件開發速度。 隨著消費者快速改變他們的偏好和行為，微服務採用者能夠跟上。 他們說，現在的生活很棒。 在最近的 IMB 調查中，多達 56% 的公司計劃在未來 24 個月內採用微服務方法。
近 80% 的當前用戶表示，他們的業務可能會加大對微服務的投資。 微服務優勢促使 Netflix、亞馬遜、eBay、Twitter 和許多其他科技巨頭從單體架構遷移到微服務架構。 但是您的公司應該使用微服務嗎？ 這取決於上下文以及微服務的優點是否大於應用程序的缺點。 本博客概述了微服務與單體方法以及使用微服務架構的五個關鍵優勢。 它還分享了 ITRex 的一些微服務經驗，並提供了有關企業何時應該（不）使用微服務的提示。 潛入。
微服務定義及與單體架構的比較
什麼是微服務架構？ 微服務風格是一種將雲原生軟件應用程序開發為一組小型組件或服務的方法，這些組件或服務圍繞單個業務工作流程設計並協同工作。 從本質上講，微服務是向 DevOps 根本轉變的一部分，在這種文化中，開發和 IT 運營團隊使用自動化工具緊密合作以更快地交付。
微服務：
- 自主開發，
- 使用他們自己的數據庫，並且可以用不同的語言編寫，
- 通過 API 與 HTTP、消息代理或事件流等輕量級協議進行通信，以及
- 執行特定的業務功能。
例如，基於微服務的電子商務應用程序可能具有負責產品圖像、用戶配置文件管理、搜索、庫存驗證、支付處理和運輸的獨立服務。 前端（網站面向客戶的一面）與後端（面向業務的一面）分離，因此可以單獨定制和管理它們。 如果您以亞馬遜為例，微服務架構可能看起來勢不可擋，如果不是可怕的話。
然而，如果不使用微服務架構，亞馬遜幾乎不會發展成為世界上最有價值的公司之一（截至 2021 年 12 月市值為 1.694 萬億美元）。 利用微服務優勢的決定是在 2000 年代初做出的，當時亞馬遜了解到，由於開發緩慢和編碼問題，它無法以客戶群增長的速度進行擴展。
Netflix 在 2000 年代後期因大量數據庫損壞而無法將 DVD 郵寄給客戶幾天后，才意識到基於雲的微服務架構的好處。 在將他們的應用程序分解為 700 多個微服務後，Netflix 工程師如今能夠每天部署數千次代碼，從而使公司能夠每天向全球 2 億多會員流式傳輸約 2.5 億小時的內容。 這些科技明星和許多其他公司以前使用什麼架構，在前云時代？ 他們使用了巨石。
什麼是單體架構？
單體應用程序構建為一個組合所有組件的單個單元，包括客戶端用戶界面、服務器端操作和數據庫。 通常，單體架構：
- 對所有功能都有一個單一的代碼庫，
- 是緊耦合的，並且
- 使用集中數據。
使用單體方法開發的電子商務應用程序將由緊密耦合的前端和後端服務組成，部署為一個單元，這意味著任何定制都需要更改代碼庫和前端平台（參見下圖比較）。
單體應用程序遠未消亡。 實際上，它們仍然是一個不錯的選擇，因為它們通常更容易構建並且更便宜（至少在早期）。 但是，它們也有缺點。 某一部分的更改，無論是出於升級還是擴展目的，通常都需要重建和重新部署整個系統。
同樣，整個系統可能會因一個行為不端的部分而崩潰，這意味著單體是脆弱的。 隨著單體應用的發展，它們也難以維護，與第三方工具的集成也不是一件好事。 在當今顛覆性的市場環境中，這些缺點是不容忽視的，在這種環境中，企業應迅速對變化做出反應以求生存和發展。 因此，關於由 DevOps 團隊構建的微服務的好處的嗡嗡聲。
微服務的 5 個主要優勢
1、獨立部署
這也許是微服務最重要的優勢，至少在微服務的早期先驅之一 Sam Newman 看來是這樣。 對應用程序進行更改以提高性能或添加新功能以響應新出現的用戶需求對於自包含微服務來說是輕而易舉的事。 每個服務都可以在不觸及整個系統的情況下進行修改和升級。 如果一個功能由於過多的請求而負載過大，它們也可以相互獨立地擴展。 例如，如果您收到更多付款，您可以僅擴展您的付款處理服務，而不會增加其他服務的資源消耗。 通過這種方式，該過程需要更少的基礎設施並節省成本。
2. 降低爆炸破壞半徑
微服務架構的鬆散耦合還提供了微服務的另一個優勢——更好的彈性。 服務之間的清晰界限，加上它們的微觀規模，限制了新版本的影響並確保了故障隔離。 一項服務的故障不會取消無關的功能，系統的其餘部分保持不變並繼續為用戶提供服務。
3.數據隔離
如果做得正確，這是微服務提供的第三個好處。 每個組件的數據主權是微服務的基本特徵。 微服務架構可以清楚地描述接觸數據的服務，這一點至關重要，尤其是在組織需要遵守醫療數據法規或 GDPR 的情況下。
4. 使用正確的技術
由於單體應用程序只有一個代碼庫，因此很難為每個功能定制技術方法，並且經常尋求折衷方案。 相比之下，微服務默認是圍繞業務功能設計的，允許團隊為特定功能選擇最佳可用技術以充分利用它。 這是因為微服務可以為不同的組件使用不同的技術或編程語言。 微服務還簡化了採用最新技術或根據需要與第三方工具集成的過程。 沒有供應商鎖定是另一個微服務優勢，自然源於其鬆散耦合的架構。
5.效率
微服務方法使公司能夠圍繞一個服務或一套可以以敏捷方式運行的服務建立小型跨職能團隊。 當一個團隊需要等待另一個團隊完成他們的任務（無論是部署還是測試）才能開始工作時，這種模型可以最大限度地減少交接。 不依賴其他團隊，開發速度加快。 根據 IMB 對 1,200 名 IT 高管和開發人員的調查，採用者報告了使用微服務的多種好處。 他們感受到的最重要的微服務優勢包括： 30% — 更高的客戶滿意度 29% — 更好的公司/客戶數據安全性 29% — 更快的上市時間 28% — 改進的應用程序性能 27% — 更大的擴展資源或擴展資源的靈活性下降 26% — 提高員工生產力 微服務是否存在挑戰？ 好吧，正如一句流行的名言所說，微服務不是免費的午餐。 繼續閱讀。
微服務的壞處
1. 複雜性
微服務固有的複雜性隨著服務數量的增加而增加。 這種複雜性是多方面的，歸因於以下幾點：
- 技術和運營層面的自上而下控制是不可能的
- 測試很難，永遠不會有太多的測試自動化
- 實現相互通信很棘手，因此需要有才華的開發人員
- 記錄的數據量太大，可能導致不一致
- 新版本可能會出現兼容性問題
- 提供適量的資源存在困難
2. 費用
微服務為公司提供了更多賺錢但不能省錢的選擇。 除了聘請能夠構建複雜微服務環境的開發人員的成本外，還有云和 API 費用。 好消息是，由於微服務在按需付費的基礎上使用按需資源，因此可以顯著優化持續成本。
3. 安全風險
IBM 調查中的一半受訪者將安全列為他們在微服務採用過程中面臨的最大挑戰。 需要從一開始就考慮安全性，因為每個微服務都有自己的一組入口點，可以通過各種基礎設施級別與其他人進行通信，從而增加了應用程序遭受攻擊的風險。 此外，擴展基礎設施會放大失去對應用程序組件的控制和可見性的風險。
何時（不）使用微服務
最後，我們的最後一個問題：什麼時候微服務架構值得麻煩？ 雖然微服務背後的嗡嗡聲自然適合雲原生應用程序是有道理的，但它們不應該成為您的默認樣式。 文獻簡單地說：從一個單體開始，當你遇到可擴展性或資源消耗問題時將其拆分，或者任何其他證明採取微服務路徑的理由。
以下是我們在不使用微服務時的關鍵提示：
1.如果你是一家初創公司，微服務是個壞主意。 明智的做法是從一個單一的應用程序開始，當它對一個兩個比薩餅的團隊來說變得太棘手時，將它分解成更小的組件。 您想要的是進行廉價的實驗，而不是投入大量時間、精力和金錢來為客戶價值尚未得到驗證的產品構建複雜的架構。 Monoliths 是測試（和丟棄）MVP 以快速了解什麼將為您的客戶帶來價值的完美方式。 正如另一位受人尊敬的微服務大師 Martin Fowler 所說：i) 幾乎所有成功的微服務故事都是從一個太大而被分解的單體開始的。 ii) 幾乎所有我聽說過的系統都是從頭開始構建為微服務系統的，它最終都陷入了嚴重的麻煩。 注意：如果產品領域不確定，那麼在開始時也不應該使用微服務。 現在跳入複雜的架構決策可能還為時過早，當您的項目成熟時，您建立溝通和邊界的方法很可能會偏離標準。
2.對於不復雜且可以由相對較小的團隊維護的解決方案，微服務並不是一個很好的選擇。 為您公司的事件調度工具推出一個複雜的微服務架構可能確實會讓您的開發人員感到開心，但所有的麻煩都值得嗎？ 微服務首先旨在解決一個問題：複雜性。 正如 Martin Fowler 所說，“甚至不要考慮微服務，除非您的系統過於復雜而無法作為單體進行管理。”
3.如果您的應用程序太小而無法證明它們的合理性，請不要選擇微服務。 如果您的庫存管理或採購系統運行良好，是否需要將它們轉換為微服務？ 再一次，使用微服務的想法是將復雜的應用程序分解為一組較小的服務。 分解已經很小且簡單的代碼只會增加複雜性 - 現在您必須使用大量工件導航所有部署、互操作性和調試問題，而不是以老式的方式部署整個單元。
好吧，但是什麼時候使用微服務來獲得好處呢？
當上述任何陳述為錯誤時，微服務才有意義。 換句話說：
- 當您的產品演變成需要馴服的複雜事物時，或者當您想要跟上變化並添加由於單體架構瓶頸而無法實現的重要功能時。
- 當您從頭開始構建具有定義範圍的大型複雜產品時。 每當一家公司想要組織數十名開發人員來構建具有明確功能集的大規模解決方案時，它應該考慮建立小型、跨職能的團隊，每個團隊負責一個組件。 這樣，每個團隊都可以獨立工作，由專門的人員處理 API 管理、數據管道、模式和其他功能。
ITRex 產品組合中的一個公平、真實的例子是客戶希望將其轉換為安全即服務平台的內部網絡安全工具。 微服務非常適合這個項目，因為單體架構無法提供 SaaS 解決方案所需的可擴展性來服務於越來越多的客戶，或者無法靈活地發展並保持領先於黑客。
另一個說明性項目是面向全球零售商的人工智能大數據平台。 我們的客戶想要一個從頭開始構建的與云無關的解決方案。 從一開始就很清楚，該平台將處理大量數據，並且應該設計為可擴展的，以適應未來添加的新數據源。 我們還必須考慮與多個外部服務建立通信的需要。 因此，在這個項目中實現微服務的好處也是一種自然的策略。 微服務架構使我們能夠順利推出這個複雜的系統，使用 Kubernetes 編排微服務和 API。
還有一個配備 3D 攝像頭的人工智能健身鏡和一個機器學習模型，該模型帶有連接到用戶設備的物聯網傳感器。 它的主要組件，包括管理面板、Android 應用程序和規則管理系統，由不同團隊在項目的不同階段構建，每個團隊使用不同的代碼和架構。 當處理它們的複雜性變得不堪重負時，我們明白我們需要為集中管理構建一個後端。 我們將它們轉換為微服務，重新設計它們的代碼並創建新的數據庫。 使用微服務方法還有其他好處，例如避免重複的代碼或功能。
因此，根據我們的經驗，當您需要管理不斷增長的數據量、處理互操作複雜性或確保您的系統足夠靈活以隨業務發展時，最好使用微服務。
尾註
隨著公司意識到微服務優勢以獲得市場優勢，微服務革命正在展開。 微服務的好處使組織能夠在已成為新常態的顛覆中保持敏捷和敏捷。 能夠更快地部署更好的軟件使他們為“下一步”之後的任何事情做好準備。 在跟進之前，重要的是您要知道您的公司可以獲得哪些微服務優勢以及這些麻煩是否合理。 除此之外，微服務可以創造奇蹟。
如果您的公司應該享受微服務的好處，您仍然感到困惑嗎？ 與 ITRex 顧問取得聯繫。 我們將幫助您弄清楚。
最初於 2022 年 1 月 10 日在 https://itrexgroup.com 上發布。