SpringCloud學習之一前置知識理解

時間 2019-11-17

標籤 springcloud 學習之一前置知識理解简体版

原文原文鏈接

前提知識+相關的說明

1．目前咱們學習到最後的微服務架構SpringCloud，到我這裏基本人須要你們熟悉之前的學習內容和知識，也即我默認你們已經熟悉了html

SpringMVC+Spring/SpringBoot+Mybatis+Maven+git……前端

再也不重複講解，java

2．本次Cloud的講解的方式，因爲咱們只有2.5天，大概21種技術之多，只能挑選最重要最經常使用的技能給你們分享，俗稱Cloud技術的五大神獸mysql

public classDept{ios

private Integer id;git

privateString deptName;程序員

…..github

}web

POM/XXXMapper.xml/application.yml面試

重點講解和Cloud相關的新知識

3．本次課程只是Cloud的第一季

天上飛的理念，必然有落地的實現

1．從面試題開始

1.1什麼是微服務

1.2微服務之間是如何獨立通信的

1.3 SpringCloud和Dubbo有哪些區別

Dubbo通訊機制基於RPC遠程過程調用、SpingCloud基於RESTful API調用

1.4 SpringBoot和SpringCloud，請你談談對他們的理解

1.5 什麼是服務熔斷？什麼是服務降級

1.6 微服務的優缺分別是什麼？說下你在項目開發中碰到的坑

1.7你所知道的微服務技術棧有哪些？請列舉一二

1.8 eurek和zookeeper均可以提供服務註冊與發現的功能，請說說兩個的區別？

1.9……..

2.微服務概述

2.1 微服務是什麼

出處

業內大牛馬丁.福勒（MartinFowler）這樣描述微服務：

論文網址：

https://martinfowler.com/articles/microservices.html ’

l 就目前而言，對於微服務業界並無一個統一的、標信的定義（Whilethere is no precise definition of this architectural syle）

In short, the microservice architecturalstyle [1]is an approach to developing a single application as a suite of small services,each running in its own process and communicating with lightweight mechanisms,often an HTTP resource API. These services are built around businesscapabilities and independently deployable by fully automated deploymentmachinery. There is a bare minimum of centralized management of these services,which may be written in different programming languages and use different datastorage technologies.

總之，建築風格microservice[1]預算編制辦法一種應用於一套小服務，每一個運行在其自身和與輕量級方法機制，一般的HTTP資源API。這些服務是創建圍繞業務能力和獨立的徹底展開機械自動化部署。有限度的這些服務的集中化管理，能夠寫成不一樣的編程語言和使用不一樣數據存儲技術。

總結

l 但一般而言，微服務架構是一種架構模式或者說是一種架構風格，它提倡將單一應用程序劃分一組小的服務，每一個服務運行在其獨立的本身的進程中，服務之間互相協調、互相配合，爲用戶提供最終價值。服務之間採用輕量級的通訊機制互相溝通（一般是基於HTTP的RESTful API）。每一個服務都圍繞着具體業務進行構建，而且可以被獨立地部署到生產環境、類生產環境等。另外應儘可能避免統一的，集中的服務管理機制，對具體的一個服務而言，應根據業務上下文，選擇合適的語言、工具對其進行構建，能夠有一個很是輕量級的集中管理來協調這些服務，可使用不一樣的語言來編寫服務，也可使用不一樣的數所存儲。

單機系統All In One

能夠看做eclipse工做空間裏面只有一個工程

如：Tmall

com.atguigu.service

商品/交易/積分/訂單…….

分佈式

專業的事交給專業的人作，儘可能下降耦合度

各個模塊/服務，各自獨立出來，分竈吃飯

各自微小的一個過程，讓專業的人專業的模塊，來作專業的事情

獨立部署

l 拆分

l 各自獨立的進程

l 擁有本身獨立的數據庫

Dubbo通訊機制基於RPC遠程過程調用、SpingCloud基於RESTful API調用

技術維度理解

微服務化的核心就是將傳統的一站式應用，根據業務拆分紅一個一個的服務，完全地去耦合，每個微服務提供單個業務功能的服務，一個服務作一件事，

從技術角度就是一種小而獨立的處理過程，相似進程的概念，可以自行單獨啓動或銷燬，擁有本身獨立的數據庫

2.2 微服務與微服務架構

微服務

強調的是的大小，它關注的是某一個點，是具體解決某一個問題/提供落地對應服務的一個服務應用，狹義的看，能夠看做Eclipse裏面一個個微服務工程/或者Module

Eclipse工具裏面用maven開發的一個個獨立的小moudle，它具休是使用SpringBoot開發的一個小模塊，專業的事情交給專業的模塊來作，一個模塊就作這一件事情

強調的是一個個的個體，每一個個體完成一個具體的任務或者功能

醫院一個個的科室

微服務架構

微服務架構是一種架構模式，它提倡將單一應用程序劃分紅一組小的服務，服務之間相協調、互相配合，爲用戶提供最終價值。每一個服務運行在其獨立的進程中，服務與服務間採用輕量級的通訊機制互相協做（一般是基於HTTP的RESTful API）。每一個都圍繞着具體業務進行構建，而且可以獨立的部署到生產、類生產環境等。另外，應當儘可能避免統一的、集中式的服務管理機制，對具體的一個服務而言，應根據業務上下文，選擇合適的語言，工具對其進行構建。

2.3 微服務優缺點

優勢

l 每一個服務足夠內聚，足夠小，代碼容易理解這樣能彙集一個指定的業務功能或業務需求

l 開發簡單、開發效率提升，一個服務可能就是專注的只幹一件事

l 微服務可以被小團隊單獨開發，這個小團隊是2到5人的開發人員組成

l 微服務是鬆耦合的，是有功能意義的服務，不管是在開發階段或部署階段都是獨立的

l 微服務能使用不一樣的語言開發

l 易於和第三方集成，微服務容許容易且靈活的方式集成自動部署，經過持續集成工具，如Jenkins，Hudson，bamboo

l 微服務易於被一個開發人員理解、修改和維護，這樣小團隊可以更關注本身的工做成果。無需經過合做體現價值。

l 微服務容許你利用整合最新技術

l 微服務只是業務邏輯的代碼，不會和HTML,CSS或其餘界面組件混合

l 每一個微服務都有本身的存儲能力，能夠有本身的數據庫，也能夠有統一數據庫

缺點

開發人員要處理分佈式系統的複雜性

多服務運維難度，隨着服務的增長，運維的壓力也在增大

系統部署依賴

服務間通訊成本

數據一致性

系統集成測試

性能監控…………

開發中，咱們們有兩種開發模式

1．先後端分離

a) 咱們Java程序員，相對而言比較幸福，why?

b) 咱們只須要管理後端，給前端的H5工程師就按照約定

c) Rest地址+輸入參數格式和報文約定+輸出參數

$.post{rest,jsonParameter,callBack}

能夠靈活搭配，鏈接公共庫+鏈接獨立庫？？？

2.全棧工程師

H5+javaEE+………..

2.4 微服務技術棧有哪些

微服務技術棧：多種技術的集合體

咱們再討論一個分佈式的微服務架構的話，它須要有哪些維度？？

一個分佈式的微服務架構維度 E時代下的數字化生活

服務治理手機

服務註冊電腦

服務調用充電寶

服務負載均衡路由器

服務監控 …… 小米科技

各個雜牌

SpringCloud

微服務條目	落地技術	備註
服務開發	SpringBoot、Spring、SpringMVC
服務配置與管理	Netflix公司的Archaius、阿里的Diamond等
服務註冊與發現	Eureka、Consul、Zookeeper等
服務調用	Rest、RPC、GRP C
服務熔斷器	Hystrix、Envoy等
負載均衡	Ribbon、Nginx等
服務接口調用（客戶端調用服務的簡化工具）	Feign等
消息隊列	Kafka、RabbitMQ、ActiveMQ等
服務配置中心管理	SpringCloudConfig、Cherf等
服務路由（API網關）	Zuul等
服務監控	Zabbix、Nagios、Metrics、Spectator等
全鏈路追蹤	Zipkin、Brave、Kubernetes等
服務部署	Docker、OpenStack、Kubernetes等
數據流操做開發包	SpringCloud Stream(封裝與Redis、Rabbit、Kafka等發送接收消息)
事件消息總線	Spring Cloud Bus
……

2.5 爲何選擇SpringCloud做爲微服務架構

選型依據

總體解決方案和框架成熟度

社區熱度

可維護性

學習曲線

當前各大IT公司用的微服務架構有哪些？

阿里Dobbo/HSF

京東JSF

新浪微博Motan

噹噹網DubboX

……

各微服務框架對比

功能點/服務框架	備選方案
功能點/服務框架	Netflix/Spring Cloud	Motan	gRPc	Thrift	Dubbo/DubboX
功能定位	完整的微服務框架	RPC框架，但整合了ZK 或Consul，實現集羣環境的基本的服務註冊/發現	RPC框架	RPC框架	服務框架
支持Rest	是 Ribbon支持多種可插拔的序列化選擇	否	否	否	否
支持RPC	否	是（Hession2）	是	是	是
支持多語言	是（Rest形式）？	否	是	是	是
服務註冊/發現	是（Eureka） Eureka服務註冊表，Karyon服務端框架支持服務自注冊和健康檢查	是（Zookeeper/consul）	否	否	是
負載均衡	是（服務端zuul+客戶端Ribbon） Zuul-服務，動態路由雲端負載均衡Eureka（針對中間層服務器）	是（客戶端）	否	否	是（客戶端）
配置服務	Netflix Archaius Spring Cloud Config Server集中配置	是（zookeeper提供）	否	否	否
服務調用鏈監控	是（zuul） Zuul提供邊緣服務，API網關	否	否	否	否
高可用/容錯	是（服務端Hystrix+客戶端Ribbon）	是（客戶端）	否	否	是（客戶端）
典型應用案例	Netflix	Sina	Gooogle	Fackbook
社區活躍程度	高	通常	高	通常	2017.8從新啓動
學習難度	中等	低	高	高	低
文檔豐富度	高	通常	通常	通常	高
其餘	Spring Cloud Bus爲咱們的應用程序帶來了更多管理端點	支持降級	Netflix內部在開發集成gRPC	IDL定義	實踐的公司比較多

3.SpringCloud入概述

3.1 是什麼

官網說明

https://spring.io/

SpringCloud，基於SpringBoot提供了一套微服務解決方案，包括服務註冊與發現，配置中心，全鏈路監控，服務網關，負載均衡，熔斷器等組件，除了基於NetFlix的開源組件作高度抽象封裝以外，還有一些選型中立的開源組條件

SpringCloud利用SpringBoot的開發便利性巧妙地簡化了分佈式系統基礎設施的開發，SpringCloud爲開發人員提供了快速創建分佈式系統的一些工具，包括配置管理、服務發現、斷路器、路由、微代理、事件總線、全局鎖、決策競選、分佈式會話等等，它們均可以用SpringBoot的開發風格作到一鍵啓動和部署。

SpringBoot並無重複製造輪子，它只是將目前各家公司開的比較成熟、經得起實際考驗的服務框架組合起來，經過SpringBoot風格進行再封裝屏蔽掉了複雜的配置和實現原理，最終給開發者留出了一套簡單易懂、易部署和易維護的分佈式系統開發工具包

SpringCloud=分佈式微服務架構下的一站式解決方案，是各個微服務架構落地技術的集合體，俗稱微服務全家桶

SpringCloud和SpringBoot是什麼關係

SpringBoot專一於快速方便的開發單個個體微服務

SpringCloud是關注全局的微服務協調整理治理框架，它將SpringBoot開發的一個個單體微服務整合並管理起來，爲各個微服務之間提供，配置管理、服務發現、斷路器、路由、微代理、事件總線、全局鎖、決策競選、分佈式會話等等集成服務

SpringBoot能夠離開SpringCloud獨立使用開發項目，可是SpringCloud離不開SpringBoot，屬於依賴的關係

SpringBoot專一於快速、方便的開發單個微服務個體，SpringCloud關注於全局的服務治理框架。

Dubbo是怎麼到SpringCloud的？哪些優缺點讓去技術選項

n 目前成熟的互聯網架構（分佈式+服務治理Dubbo）

n 咱們把SpringCloud VS DUBBO進行一番對比

u 活躍度

https://github.com/dubbo

https://github.com/spring-cloud

u 對比結果

	Dubbo	Spring Cloud
服務註冊中心	Zookeeper	Spring Cloud Netflix Eureka
服務調用中心	RPC	REST API
服務監控	Dubbo-monitor	Spring Boot Admin
斷路器	不完善	Spring Cloud Netflix Hvstrix
服務網關	無	Spring Cloud Netflix
分佈式配置	無	Spring Cloud Config
服務跟蹤	無	Spring Cloud Sleuth
消息總線	元	Spring Cloud Bus
數據流	無	Spring Cloud Stream
批量任務	無	Spring Cloud Task
……	……	……

最大區別：SpringCloud拋棄了Dubbo的RPC通訊，採用的是基於HTTP的REST方式

嚴格來講，這兩種方式各有優劣，雖然從必定程度上來講，後者犧牲服務調用的性能，但也避免了上面提到的原生RPC帶來的問題。並且REST相比RPC更爲靈活，服務提供方和調用方的依賴只依靠一紙契約，不存在代碼級別的強依賴，這在強調快速深化的微服務環境下，顯得更加合適

品牌機與組裝機的區別

很明顯，Spring Cloud的功能比DUBBO更增強大，涵蓋面更廣，並且做爲Spring的拳頭項目，它也可以與Spring Framework、Spring Boot、Spring Data、Spring Batch等其餘Spring項目完美整合，這些對於微服務而言是相當重要的。使用Dubbo構建的微服務架構就像組裝電腦，各環節咱們的選擇自由度很高，可是最終結果極可能由於一條內存質量不行就點不亮了，老是讓人不怎麼放心，可是若是你是一名高手，那這些都不是問題；而Spring Cloud就像品牌機，在Spring Source的整合下，作了大量的兼容性測試，保證了機器擁有更高的穩定性，可是若是要在使用非原裝組件外的東西，就須要對其基礎有足夠的瞭解。

社區支持與更新力度

最爲重要的是，DUBBO中止了5年左右的更新，雖然2017.7重啓了。對於技術發展的新需求，須要由開發者自行拓展升級（好比噹噹網弄出了DubboX）,這對於不少想要採用微服務架構的中小軟件組織，顯然是不太合適的，中小公司沒有這麼強大的技術能力去修改Dubbo源碼+周邊的一整套解決方案，並非每個公司都有阿里的大牛+真實的線上生產環境測試過。

n 總結Cloud與Dubbo

問題：

曾風靡國內的開源RPC服務框架Dubbo在重啓維護後，令許多用戶爲這雀躍，但同時，也迎來一些質疑的聲音。互聯網技術發展迅速，Dubbo是否還能跟上時代？Dubbo與Spring Cloud相比又有何優點和差別？是否會有相關舉措保證Dubbo的後續更新頻率？

人物：Dubbo重啓維護開發的劉軍，主要負責人之一

劉軍，阿里巴巴中間件高級研發工程師，主導了Dubbo重啓維護之後的幾個發版計劃，專一於高性能RPC框架和微服務相關領域。曾負責網易考拉RPC框架的研發及指導在內部使用，參與了服務治理平臺、分佈式跟蹤系統、分佈式一致性框架等從無到有的設計與開發過程。

關於Dubbo和Spring Cloud間的關係，咱們在開源中國年終盛典的Dubbo分享中也做了簡單闡述，首先要明確的一點是Dubbo和Spring Cloud並非徹底的競爭關係，二者所解決的問題域並不同：Dubbo定位始終是一款RPC框架，而Spring Cloud的目標是微服務架構下的一站式解決方案。若是非要比較的話，我以爲Dubbo能夠類比Netflix OSS技術棧，而SpringCloud集成了Netflix OSS做爲分佈式服務治理解決方案，但除此以外Spring cloud還提供了包括config、stream、security、sleuth等等分佈式問題解決方案。

當前因爲RPC協議、註冊中心元數據不匹配等問題，在面臨微服務基礎框架造型時Dubbo與Spring Cloud是隻能二選一，這也是爲何你們老是拿Dubbo和Spring Cloud作對比的緣由之一。Dubbo以後會積極尋求適配到SpringCloud生態，好比做爲Spring Cloud的二進制通訊方案來發揮Dubbo的性能優點，或者Dubbo經過模塊化以及對http的支持適配到Spring Cloud。