SpringCloud與微服務
程式架構發展史
- ORM（All in One) 可承載并發量1~10
- MVC (Vertical Application) 可承載并發量 10~1000
- RPC (Distributed Service) 可承載并發量 1000~10000
- SOA (Elastic Computing) 10000+
Spring Cloud
- Spring Cloud是一系列框架的有序集合，是一種生態，、
- spring Cloud基于Springboot 提供了一整套的微服務解決方案，包括服務注冊與發現，配置中心，全鏈路監控，服務網關，負載均衡，熔斷器等組件，除了基于NetFlix的開源組件做高度抽象封裝之外，還有一些選型中立的開源組件，
微服務架構
-
由Martin Fowker提出，是一種架構形式，
-
微服務只是業務邏輯的代碼，不會和Html，CSS或其他界面組合，
-
微服務是弱耦合的每個服務都能獨立部署
微服務架構的四個核心問題
- 服務很多，客戶端該怎么訪問？
- 這么多服務，服務之間如何通信？
- 這么多服務，如何治理？
- 服務掛了怎么辦？
解決方案
（一）Spring Cloud NetFlix 一站式的解決方案，使用api網關，zuul組件
- http通信方式，同步阻塞式的
- 服務注冊與發現：Eureka
- 熔斷機制：Hystrix
（二）Apache Dubbo Zookeeper
- 半自動的，需要整合
- API無，找第三方組件或自己實作
- 沒有熔斷機制
- Dubbo方案不完善
Eureka服務注冊與發現
-
解決服務之間如何通信
-
NetFlix在設計Eureka時，遵循的就是AP原則
CAP原則
- C：Consistency強一致性
- A ：Availability 可用性
- P ：Partion tolerance 分離容錯性
分布式系統不可能同時滿足CAP原則
Zookeeper保證的時CP，Eureka保證的時AP
- Eureka時NetFlix的一個子模塊，也是核心模塊之一，Eureka是一個基于REST的服務，用于定位服務，以實作云端中間層服務發現和故障轉移，服務注冊與發現對于微服務來說是非常重要的，有了服務注冊與發現，只需要使用服務的識別符號，就可以訪問到服務，而不需要修改服務呼叫的組態檔，功能類似zookeeper
- Eureka采用C-S架構，EurekaServer作為服務注冊功能的服務端，是注冊中心
三大角色
-
Eureka Server 提供服務的注冊與發現
-
Service Provider 將自身服務注冊到Eureka中，從而方便消費者能夠找到
-
Service Consumer 服務消費方從Eureka中獲取注冊服務串列，從而找到消費服務
-
可以有多個Eureka組件，用以服務注冊與發現，
-
多個相同Service Provider來共服務，注意要在注冊中心的名稱相同，用以表示提供相同的服務，
Ribbon負載均衡
-
解決了服務治理問題
-
LB（Load Balance）負載均衡：即將用戶的請求平攤的分配到多個服務上，從而達到系統的高可用
分類
集中式LB ：如Nginx（反向代理服務器）
行程式：如Ribbon
Spring Cloud Ribbon 是基于 NetFlix Ribbon實作的一套客戶端負載均衡工具，
- Ribbon 和 Eureka整合后，不用關心IP地址和埠號，只需要知道在注冊中心的Application名稱即可，
實作演算法
- Ribbon 默認的實作演算法是輪詢
- randomRule隨機演算法，
- availabilityFilteringRule ：會過濾掉跳閘的，訪問故障的服務，對剩下的進行輪詢，
- retryRule： 會選按照輪詢獲取服務，如果服務獲取失敗，則會在指定的時間內重試
- 也可以自定義負載均衡演算法，如加權演算法等
Hystrix服務熔斷
- 解決服務掛了的問題
- Hystrix，能保證在一個以來出問題的情況下不會導致整體的服務失敗，避免聯級故障，以提高分布式系統的彈性，
- 作用：服務降級，服務熔斷，服務限流，接近實時的監控，
- 服務熔斷：熔斷機制是對應雪崩效應的一種微服務鏈路保護機制，5秒內20次呼叫失敗就會啟動熔斷機制，服務端某個服務超時或者例外就會引起熔斷
- 服務降級：客戶端，從整體網站請求負載考慮，當某個服務熔斷或者關閉之后，服務將不再被呼叫，此時在客戶端，我們可以準備一個FallbackFactory，會回傳一個默認值（預設值），整體服務水平下降，
Zuul路由網關
-
解決客戶端該怎么訪問
-
zuul包含了對請求的路由和過濾兩個最主要的功能，是實作外部訪問同一入口的基礎，
-
zuu最侄訓是會注冊進eureka
-
提供：代理+路由+過濾三大功能
SpringCloud與Dubbo的區別
-
SpringCloud拋棄了Dubbo的RPC通信，采用的是基于HttpRest的方式
-
后者犧牲了服務呼叫的性能，但也避免了原生RPC帶來的問題，而且REST相比RPC更加靈活，服務提供方和呼叫方的依賴只能依靠契約，不存在代碼級別的強以來，這在強調快速演化的微服務環境下，更加合適，
-
解決的問題不一樣：Dubbo的定位是一款RPC框架，而SpringCloud的目標是微服務框架下的一站式解決方案，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/279233.html
標籤：其他
下一篇：Hadoop Rpc簡單實作