微服務架構是一種軟件開發(fā)模式,它將一個復雜的應用程序拆分為多個個獨立的、小型的、可復用的服務,每個服務負責一個特定的業(yè)務功能。
微服務架構有許多優(yōu)點,例如提高系統(tǒng)的可擴展性、可維護性、可測試性和故障容忍性。
但是,微服務架構也有很多問題需要注意,例如如何設計合理的劃分服務接口、如何在服務間實現(xiàn)高效通信、如何保證數(shù)據(jù)一致性等。因此要想成功地使用微服務架構,我們需要遵循一些最佳實踐。
以下是一些微服務架構的最佳實踐,我將盡我所了解的知識給大家進行講解。本文大綱如下,
圖片
沒錯,我們應該盡量避免使用微服務架構。
認真地說,使用微服務架構只能被視為最后的選擇。從項目實際應用場景開發(fā),少看一些網上關于微服務的吹捧。務實一點,根據(jù)項目體量、業(yè)務復雜度選擇一個適合當前項目的架構。
首先嘗試構建一個單體的模塊化架構,而不是一上來就搞微服務架構。
在任何使用微服務的分布式系統(tǒng)里面,總是有調用失敗的可能,比如網絡分區(qū)、某個服務宕機不可用等。
所以我們在系統(tǒng)調用層面針對失敗場景的處理,應該設計得越早越好。
故障設計最好三個級別,
實際的針對失敗場景處理,可以使用斷路器、服務降級和 "隔板模式"。
隔板模式在分布式系統(tǒng)中就是指資源隔離,在分布式系統(tǒng)里,資源隔離通常按業(yè)務分為進程級別的隔離和線程級別的隔離,某些簡單的服務質量要求不高的業(yè)務場景下實現(xiàn)進程級別的隔離就夠了,但是在某些對服務質量要求較高的分布式場景下需要線程級別的細粒度隔離。
微服務架構中,每個服務應該都按單一職責進行設計。
每個微服務應該只負責一個業(yè)務領域,并且盡量避免涉及其他領域。
這樣可以提高代碼的可讀性、可測試性和可維護性,也可以降低系統(tǒng)的復雜度和耦合度。
微服務架構中,服務之間的通信協(xié)議時非常重要的。因為在一些對性能要求較高的場景里,選擇一個輕量級協(xié)議所能帶來的 QPS 提升,也是非常客觀的。
比如服務間可以使用 REST、GRPC 或消息隊列等通信協(xié)議,這樣可以盡可能減少服務通信帶來的開銷并提升性能。
微服務架構下,服務實例的網絡地址是動態(tài)分配和變化的,因此需要一種機制,能夠及時獲取服務實例的最新的網絡地址,以便進行服務間通信。
并且服務實例的數(shù)量和狀態(tài)都是隨著業(yè)務需求和故障情況而變化的,還需要有能夠及時感知服務實例的上線、下線、故障等情況的能力。
因此我們需要使用服務發(fā)現(xiàn)組件,它負責自動發(fā)現(xiàn)服務實例,負載均衡和故障轉移。
服務發(fā)現(xiàn)組件有 Eureka 、Consul、Nacos 等,國內的話,推薦大家使用 Nacos。
微服務架構下,每個服務的數(shù)據(jù)庫應該都是單獨部署的,它們之間相互隔離。
一個服務要操作另一個服務數(shù)據(jù)庫中的數(shù)據(jù)時,都應該只能通過調用另一個服務的接口來實現(xiàn),而不是粗暴的直接訪問其他服務的數(shù)據(jù)庫進行讀寫。
數(shù)據(jù)庫隔離的最終目標就是為了減少服務之間的耦合,使它們能夠獨立發(fā)展。
為了提高微服務架構中各個服務的彈性,我們應該盡量使用彈性模式。
所謂彈性,其實就是服務的可用性,專業(yè)一點的話說就是從某些類型的故障中恢復并保持自身服務的能力。
那么,我們應該如何實施實施彈性模式嘞?
其實很簡單,我給大家分成兩個部分進行講解,一個是服務內,另一個是服務外。
服務內指的是別人調用我們的服務時,需要注意的點有,
服務外指的是我們調用別人的服務時,需要注意的點有,
有句話說得好,"在任何分布式系統(tǒng)中,會宕機的服務最終都會宕機"。
本文鏈接:http://www.www897cc.com/showinfo-26-52589-0.html微服務開發(fā),這十個點你要知道
聲明:本網頁內容旨在傳播知識,若有侵權等問題請及時與本網聯(lián)系,我們將在第一時間刪除處理。郵件:2376512515@qq.com
下一篇: 一文讀懂JWT