1. 首頁 > 生活百科 > >

什么是 微服務( 三 )

生活百科單體


BFF 模式允許開發人員使用該界面的最佳選項為每個用戶界面創建和支持一種后端類型，而不是嘗試支持適用于任何界面但可能會對前端性能產生負面影響的通用后端 。
例如，在電子商務網站上，產品對象可能通過產品名稱、類型和價格來區分 。
聚合是應被視為一個單元的相關實體的集合 。
因此，對于電子商務網站，訂單將是買家訂購的產品（實體）的集合（集合） 。
這些模式用于以有意義的方式對數據進行分類 。
在微服務架構中，服務實例會因伸縮、升級、服務故障甚至服務終止而動態變化 。
這些模式提供了發現機制來應對這種短暫性 。
負載平衡可以通過使用 健康 檢查和服務故障作為重新平衡流量的觸發器來使用服務發現模式 。
適配器模式的目的是幫助翻譯不兼容的類或對象之間的關系 。
依賴第三方 API 的應用程序可能需要使用適配器模式來確保應用程序和 API 可以通信 。
這個色彩繽紛的名字指的是藤蔓（微服務）如何隨著時間的推移慢慢地超越并扼殺一棵樹（單體應用程序） 。
雖然有很多模式可以很好地完成微服務，但同樣數量的模式可以很快讓任何開發團隊陷入困境 。
其中一些——改寫為微服務“不要”——如下：
一旦應用程序變得太大且難以輕松更新和維護，微服務是一種管理復雜性的方法 。
只有當您感覺到單體架構的痛苦和復雜性開始蔓延時，才值得考慮如何將該應用程序重構為更小的服務 。
在你感受到那種痛苦之前，你甚至沒有真正擁有需要重構的單體 。
嘗試在沒有 a) 適當的部署和監控自動化或 b) 托管云服務來支持您現在龐大的異構基礎設施的情況下進行微服務，會帶來很多不必要的麻煩 。
省去你自己的麻煩，這樣你就可以把時間花在擔心狀態上 。
最好傾向于更大的服務，然后只在它們開始開發微服務解決的特征時才將它們分開——即部署更改變得困難和緩慢，通用數據模型變得過于復雜，或者不同部分服務有不同的負載/規模要求 。
微服務和 SOA 之間的區別在于，微服務項目通常涉及重構應用程序以便更易于管理，而 SOA 關注的是改變 IT 服務在企業范圍內的工作方式 。
一個演變成 SOA 項目的微服務項目可能會因自身的重量而崩潰 。
你最好從一個你可以處理的速度開始，避免復雜性，并盡可能多地使用現成的工具 。
微服務架構是一種軟件設計方法，它將應用程序分解為通過定義明確的 API 進行通信的小型獨立服務 。由于每個服務都可以由自治團隊開發和維護，因此它是最具可擴展性的軟件開發方法 。
微服務設計與單體開發截然相反 。單體是一個實現所有功能的大型代碼庫（“廚房水槽”） 。一切都在一個地方，沒有一個組件可以孤立地工作 。這意味著應用程序必須作為一個整體進行測試 。
從好的方面來說，單體應用很容易啟動和運行 。由于單體架構不同部分之間的關系是透明的，因此進行廣泛的更改很容易 。
然而，隨著公司的發展和團隊規模的擴大，單體開發變得更加困難 。很快，系統就不能再裝在一個頭上了——移動部件太多了，所以事情變慢了 。
微服務使公司能夠保持團隊規模小而敏捷 。這個想法是將應用程序分解為可以由緊密結合的團隊自主開發和部署的小型服務 。
公司采用微服務的主要原因是可擴展性。服務可以獨立開發和發布，無需在組織內安排大規模的協調工作 。
擁有分布式系統的一個好處是能夠避免單個故障點 。您可以使用支持云的技術在不同的可用區部署微服務，確保您的用戶永遠不會遇到中斷 。
使用微服務，開發團隊可以保持小而有凝聚力 。小組越小，溝通開銷越少，協作越好 。
亞馬遜通過他們的兩個披薩團隊將團隊規模發揮到了極致 。這意味著一個團隊應該足夠小，可以吃兩個比薩餅 。
對于單體應用，語言和技術堆棧選項幾乎從一開始就設置好了 。新開發人員必須適應過去做出的任何選擇 。
相比之下，每個微服務都可以使用最適合解決手頭任務的技術堆棧 。因此，團隊可以為工作和他們的技能選擇最佳工具 。例如，您可以使用 Go 或 C 實現高性能服務，并使用 Erlang 或 Elixir 實現高容錯微服務 。
隨著小團隊迭代速度更快，開發和測試周期更短 。而且，由于他們還可以隨時部署更新，微服務的部署頻率比單體應用要高得多 。
有這么多好處，似乎為新項目選擇微服務是一件輕而易舉的事 。但是微服務設計也帶來了一些嚴峻的挑戰：

推薦閱讀