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