前提知識+相關的說明
1． 目前我們學習到最后的微服務架構SpringCloud，到我這里基本人需要大家熟悉以前的學習內容和知識，也即我默認大家已經熟悉了
SpringMVC+Spring/SpringBoot+Mybatis+Maven+git……
不再重復講解，
2． 本次Cloud的講解的方式，由於我們只有2.5天，大概21種技術之多，只能挑選最重要最常用的技能給大家分享，俗稱Cloud技術的五大神獸
public classDept{
private Integer id;
privateString deptName;
…..
}
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 是什么
官網說明
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/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。
3.2 能干嘛
Distributed/versioned configuration(分布式/版本控制配置)
Service registration and disconvery(服務注冊與發現)
Routing(路由)
Service-to-service-calls(服務到服務的調用)
Load balancing(負載均衡配置)
Distributed messaging(分布式消息管理)
…….
3.3 去哪下
官網
http://projects.spring.io/spirng-cloud/
參考書
https://springcloud.cc/spring-cloud-netflix.html
本次開發API說明
http://cloud.spring.io/spring-cloud-static/Dalston.SR1/
https://spirngcloud.cc/spring-cloud-dalston.html
SpringCloud中國社區
SpringCloud中文網
3.4 怎么玩
服務的注冊與發現（Eureka）
服務消費者（rest+Ribbon）
服務消費者（Feign）
斷路器（Hystrix）
斷路器監控（Hystrix Dashboard）
路由網關（Zuul）
分布式配置中心（Spring Cloud Config）
消息總線（Spring Cloud Bus）
服務鏈路追蹤（Spring Cloud Sleuth）
……..
All
3.5 SpringCloud國內使用情況
國內公司
阿里雲
面試的時候是不是需要有一種
理論知識+面試時候的談資！！！！！！
4.Rest微服務構建案例工程模塊
4.1 總體介紹
l 承接着我們的spirngmvc+mybatis+mysql初級高級課程，以Dept部門模塊做一個微服務通用案例Consumer消費者（Client）通過REST調用Provider提供者（Server）提供的服務
n 已經學習過的知識springmvc
n 已經學習過的知識mybaits
l Maven的分包分模塊架構復習
一個簡單的Maven模塊結構是這樣的：
----- app-parent 一個父項目（app-parent）聚合很多子項目（app-util,app-dao,app-service,app-web）
|----- pom.xml(pom)
|
|---------- app-util
||---------- pom.xml(jar)
|
|---------- app-dao
||---------- pom.xml(jar)
|
|---------- app-service
||---------- pom.xml(jar)
|
|---------- app-web
||---------- pom.xml(war)
l 直接動手干
n Maven的分包分模塊架構復習
一個Project帶着多個Module子模塊
MicroServiceCloud父工程（Project）下次次帶着3個子模塊（Module）
microservicecloud-api
封裝的整體entity/接口/公共配置等
microservicecloud-provider-dept-8001
微服務落地的服務提供
microservicecloud-consumer-dept-80
微服務調用的客戶端使用
80端口
80端口是為HTTP（HyperText Transport Protocol）即超傳輸協議開放的
此為上網沖浪使用次數最多的協議，主要用於WWW(World Wide Web)即萬維網傳輸信息的協議
可以通過HTTP地址（即常說的“網址”）加“：80”來訪問網站，
因為瀏覽網頁服務默認的端口號都是80，因此只需輸入網址即可，不用輸入“：80”了。
1 父工程
1.1 api公共模塊
1.2 GAV
1.3 GAV
1.4 GAV
…….
Dept.java.Entity
