什么是 微服務


什么是 微服務

文章插圖
微服務架構是一種方法,其中單個應用程序由許多松散耦合且可獨立部署的較小服務組成 。
微服務(或微服務架構)是一種云原生架構方法,其中單個應用程序由許多松散耦合且可獨立部署的較小組件或服務組成 。
這些服務通常
雖然關于微服務的大部分討論都圍繞架構定義和特征展開,但它們的價值可以通過相當簡單的業務和組織優勢來更普遍地理解:
微服務也可以通過它們不是什么來理解 。
與微服務架構最常進行的兩個比較是單體架構和面向服務的架構 (SOA) 。
微服務和單體架構之間的區別在于,微服務由許多較小的、松散耦合的服務組成一個應用程序,而不是大型、緊密耦合的應用程序的單體方法
微服務和 SOA 之間的區別可能不太清楚 。
雖然可以在微服務和 SOA 之間進行技術對比,尤其是圍繞 企業服務總線 (ESB) 的角色,但更容易將差異視為范圍之一。
SOA 是企業范圍內的一項努力,旨在標準化組織中所有 Web 服務相互通信和集成的方式,而微服務架構是特定于應用程序的 。
微服務可能至少與開發人員一樣受高管和項目負責人的歡迎 。
這是微服務更不尋常的特征之一,因為架構熱情通常是為軟件開發團隊保留的 。
原因是微服務更好地反映了許多業務領導者希望構建和運行他們的團隊和開發流程的方式 。
換句話說,微服務是一種架構模型,可以更好地促進所需的操作模型 。
在IBM 最近對 1,200 多名開發人員和 IT 主管進行的一項調查中,87% 的微服務用戶同意微服務的采用是值得的 。
也許微服務最重要的一個特點是,由于服務更小并且可以獨立部署,它不再需要國會的法案來更改一行代碼或在應用程序中添加新功能 。
微服務向組織承諾提供一種解毒劑,以解決與需要大量時間的小改動相關的內心挫敗感 。
它不需要博士學位 。
在計算機科學中看到或理解一種更好地促進速度和敏捷性的方法的價值 。
但速度并不是以這種方式設計服務的唯一價值 。
一種常見的新興組織模型是圍繞業務問題、服務或產品將跨職能團隊聚集在一起 。
微服務模型完全符合這一趨勢,因為它使組織能夠圍繞一個服務或一組服務創建小型、跨職能的團隊,并讓他們以敏捷的方式運行 。
微服務的松散耦合還為應用程序建立了一定程度的故障隔離和更好的彈性 。
服務的小規模,加上清晰的邊界和溝通模式,使新團隊成員更容易理解代碼庫并快速為其做出貢獻——在速度和員工士氣方面都有明顯的好處 。
在傳統的 n 層架構模式中,應用程序通常共享一個公共堆棧,其中一個大型關系數據庫支持整個應用程序 。
這種方法有幾個明顯的缺點——其中最重要的是應用程序的每個組件都必須共享一個公共堆棧、數據模型和數據庫,即使對于某些元素的工作有一個清晰、更好的工具 。
它造成了糟糕的架構,并且對于那些不斷意識到構建這些組件的更好、更有效的方法是可用的開發人員來說是令人沮喪的 。
相比之下,在微服務模型中,組件是獨立部署的,并通過 REST、事件流和消息代理的某種組合進行通信——因此每個單獨服務的堆棧都可以針對該服務進行優化 。
技術一直在變化,由多個較小的服務組成的應用程序更容易和更便宜地隨著更理想的技術發展而變得可用 。
使用微服務,可以單獨部署單個服務,但也可以單獨擴展它們 。由此產生的好處是顯而易見的:如果做得正確,微服務比單體應用程序需要更少的基礎設施,因為它們只支持對需要它的組件進行精確擴展,而不是在單體應用程序的情況下對整個應用程序進行擴展 。
微服務的顯著優勢伴隨著重大挑戰 。
從單體架構到微服務意味著更多的管理復雜性——更多的服務,由更多的團隊創建,部署在更多的地方 。
一項服務中的問題可能會導致或由其他服務中的問題引起 。
【什么是 微服務】
日志數據(用于監控和解決問題)更加龐大,并且在服務之間可能不一致 。
新版本可能會導致向后兼容性問題 。
應用程序涉及更多的網絡連接,這意味著出現延遲和連接問題的機會更多 。
DevOps 方法可以解決其中的許多問題,但 DevOps 的采用也有其自身的挑戰 。
然而,這些挑戰并沒有阻止非采用者采用微服務——或者采用者深化他們的微服務承諾 。

推薦閱讀