微服務架構體現的思想及優缺點
微服務架構設計的核?思想就是“微”，拆分的粒度相對?較?，這樣的話單?職責、開發的耦合度就會降低、微?的功能可以獨?部署擴展、靈活性強，升級改造
影響范圍?，
單體應?（1.7—>1.8）
A(升級JDK) B C D E .....
微服務架構的優點: 微服務架構和微服務
微服務很?，便于特定業務功能的聚焦 A B C D
微服務很?，每個微服務都可以被?個?團隊單獨實施（開發、測驗、部署上
線、運維），團隊合作?定程度解耦，便于實施敏捷開發
微服務很?，便于重?和模塊之間的組裝
微服務很獨?，那么不同的微服務可以使?不同的語?開發，松耦合
微服務架構下，我們更容易引?新技術
微服務架構下，我們可以更好的實作DevOps開發運維?體化；
微服務架構的缺點
微服務架構下，分布式復雜難以管理，當服務數量增加，管理將越加復雜；
微服務架構下，分布式鏈路跟蹤難等；
服務注冊與服務發現
服務注冊：服務提供者將所提供服務的資訊（服務器IP和端?、服務訪問協議等）
注冊/登記到注冊中?
服務發現：服務消費者能夠從注冊中?獲取到較為實時的服務串列，然后根究?定
的策略選擇?個服務訪問
負載均衡
負載均衡即將請求壓?分配到多個服務器（應?服務器、資料庫服務器等），以此來提?服務的性能、可靠性
熔斷
熔斷即斷路保護，微服務架構中，如果下游服務因訪問壓?過??回應變慢或失敗，上游服務為了保護系統整體可?性，可以暫時切斷對下游服務的調?，這種犧
牲區域，保全整體的措施就叫做熔斷，
鏈路追蹤
微服務架構越發流?，?個項?往往拆分成很多個服務，那么?次請求就需要涉及到很多個服務，不同的微服務可能是由不同的團隊開發、可能使?不同的編程語?實作、整個項?也有可能部署在了很多服務器上（甚?百臺、千臺）橫跨多個不同的資料中?，所謂鏈路追蹤，就是對?次請求涉及的很多個服務鏈路進??志記錄、性能監控
API ?關
微服務架構下，不同的微服務往往會有不同的訪問地址，客戶端可能需要調?多個服務的接?才能完成?個業務需求，如果讓客戶端直接與各個微服務通信可能出
現：
1）客戶端需要調?不同的url地址，增加了維護調?難度
2）在?定的場景下，也存在跨域請求的問題（前后端分離就會碰到跨域問題，原本
我們在后端采?Cors就能解決，現在利??關，那么就放在?關這層做好了）
3）每個微服務都需要進?單獨的身份認證
那么，API?關就可以較好的統?處理上述問題，API請求調?統?接?API?關層，
由?關轉發請求，API?關更專注在安全、路由、流量等問題的處理上（微服務團隊
專注于處理業務邏輯即可），它的功能?如
1）統?接?（路由）
2）安全防護（統?鑒權，負責?關訪問身份認證驗證，與“訪問認證中?”通信，實
際認證業務邏輯交移“訪問認證中?”處理）
3）??名單（實作通過IP地址控制禁?訪問?關功能，控制訪問）
3）協議適配（實作通信協議校驗、適配轉換的功能）
4）流量管控（限流）
5）?短鏈接?持
6）容錯能?（負載均衡）
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/282302.html
標籤：其他
上一篇：13@nginx負載均衡
下一篇：MySQL主從復制安裝配置