回顧微服務架構
微服務架構4個核心問題：
1. 服務很多，客戶端該怎么訪問？
2. 這么多服務，服務之間如何通信？
3. 這么多服務，如何治理？
4. 某個服務掛了怎么辦？
解決方案：
springCoud：它是一種生態！它是基於springboot構建的
它落地的流行實現有以下三個：
1.Spring Cloud NetFlix 一站式解決方案!（NetFlix停更不停用）
api網關：zuul組件
Feign:它是基於HttpClient的，也就是基於Http的通信方式：同步阻塞的
eureka：服務注冊與發現，就是來服務治理的
Hystrix：熔斷機制，某個服務掛了采用的機制
。。。。等其他組件
2.Apache Dubbo Zookeeper 半自動，需要整合別人的東西!
API網關：沒有，需要找第三方組件，或者自己實現
Dubbo: RPC框架，用於服務間通信(很專業)
Zookeeper: 服務注冊與發現
熔斷機制：沒有，可以借助Hystrix組件
可以得出個結論：Dubbo這個方案並不完善
3.Spring Cloud Alibaba 最新的一站式解決方案! 更簡單
新概念：服務網格 server Mesh
它的代表落地實現: istio
萬變不離其宗：
1.API網關解決服務路由
2.HTTP，RPC解決服務通信
3.服務注冊與發現，實現高可用
4.熔斷機制，解決服務掛了的問題，也就是服務降級
本質: 網絡不可靠
常見面試題
1.1 什么是微服務？
1.2 微服務之間是如何獨立通訊的？
1.3 SpringCloud 和 Dubbo有那些區別？
1.4 SpringBoot 和 SpringCloud，請談談你對他們的理解
1.5 什么是服務熔斷？什么是服務降級？
1.6 微服務的優缺點分別是什么？說下你在項目開發中遇到的坑
1.7 你所知道的微服務技術棧有哪些？列舉一二
1.8 Eureka和Zookeeper都可以提供服務注冊與發現的功能，請說說兩者的區別
…
微服務概述
什么是微服務？
微服務(Microservice Architecture) 是近幾年流行的一種架構思想，關於它的概念很難一言以蔽之。
究竟什么是微服務呢？我們在此引用ThoughtWorks 公司的首席科學家 Martin Fowler 於2014年提出的一段話：
原文：https://martinfowler.com/articles/microservices.html
漢化：https://www.cnblogs.com/liuning8023/p/4493156.html
- 就目前而言，對於微服務，業界並沒有一個統一的，標准的定義。
- 但通常而言，微服務架構是一種架構模式，或者說是一種架構風格，它體長將單一的應用程序划分成一組小的服務，每個服務運行在其獨立的自己的進程內，服務之間互相協調，互相配置，為用戶提供最終價值，服務之間采用輕量級的通信機制(HTTP)互相溝通，每個服務都圍繞着具體的業務進行構建，並且能狗被獨立的部署到生產環境中，另外，應盡量避免統一的，集中式的服務管理機制，對具體的一個服務而言，應該根據業務上下文，選擇合適的語言，工具(Maven)對其進行構建，可以有一個非常輕量級的集中式管理來協調這些服務，可以使用不同的語言來編寫服務，也可以使用不同的數據存儲。
再來從技術維度角度理解下：
- 微服務化的核心就是將傳統的一站式應用，根據業務拆分成一個一個的服務，徹底地去耦合，每一個微服務提供單個業務功能的服務，一個服務做一件事情，從技術角度看就是一種小而獨立的處理過程，類似進程的概念，能夠自行單獨啟動或銷毀，擁有自己獨立的數據庫。
微服務與微服務架構
微服務
強調的是服務的大小，它關注的是某一個點，是具體解決某一個問題/提供落地對應服務的一個服務應用，狹義的看，可以看作是IDEA中的一個個微服務工程，或者Moudel。IDEA 工具里面使用Maven開發的一個個獨立的小Moudel，它具體是使用SpringBoot開發的一個小模塊，專業的事情交給專業的模塊來做，一個模塊就做着一件事情。強調的是一個個的個體，每個個體完成一個具體的任務或者功能。
微服務架構
一種新的架構形式，Martin Fowler 於2014年提出。
微服務架構是一種架構模式，它體長將單一應用程序划分成一組小的服務，服務之間相互協調，互相配合，為用戶提供最終價值。每個服務運行在其獨立的進程中，服務與服務之間采用輕量級的通信機制(如HTTP)互相協作，每個服務都圍繞着具體的業務進行構建，並且能夠被獨立的部署到生產環境中，另外，應盡量避免統一的，集中式的服務管理機制，對具體的一個服務而言，應根據業務上下文，選擇合適的語言、工具(如Maven)對其進行構建。
微服務優缺點
優點
- 單一職責原則；
- 每個服務足夠內聚，足夠小，代碼容易理解，這樣能聚焦一個指定的業務功能或業務需求；
- 開發簡單，開發效率高，一個服務可能就是專一的只干一件事；
- 微服務能夠被小團隊單獨開發，這個團隊只需2-5個開發人員組成；
- 微服務是松耦合的，是有功能意義的服務，無論是在開發階段或部署階段都是獨立的；
- 微服務能使用不同的語言開發；
- 易於和第三方集成，微服務允許容易且靈活的方式集成自動部署，通過持續集成工具，如jenkins，Hudson，bamboo；
- 微服務易於被一個開發人員理解，修改和維護，這樣小團隊能夠更關注自己的工作成果，無需通過合作才能體現價值；
- 微服務允許利用和融合最新技術；
- 微服務只是業務邏輯的代碼，不會和HTML，CSS，或其他的界面混合;
- 每個微服務都有自己的存儲能力，可以有自己的數據庫，也可以有統一的數據庫；
缺點
- 開發人員要處理分布式系統的復雜性；
- 多服務運維難度，隨着服務的增加，運維的壓力也在增大；
- 系統部署依賴問題；
- 服務間通信成本問題；
- 數據一致性問題；
- 系統集成測試問題；
- 性能和監控問題；
微服務技術棧有那些？
| 微服務技術條目 | 落地技術 |
|---|---|
| 服務開發 | SpringBoot、Spring、SpringMVC等 |
| 服務配置與管理 | Netfix公司的Archaius、阿里的Diamond等 |
| 服務注冊與發現 | Eureka、Consul、Zookeeper等 |
| 服務調用 | Rest、PRC、gRPC |
| 服務熔斷器 | Hystrix、Envoy等 |
| 負載均衡 | Ribbon、Nginx等 |
| 服務接口調用(客戶端調用服務的簡化工具) | Fegin等 |
| 消息隊列 | Kafka、RabbitMQ、ActiveMQ等 |
| 服務配置中心管理 | SpringCloudConfig、Chef等 |
| 服務路由(API網關) | Zuul等 |
| 服務監控 | Zabbix、Nagios、Metrics、Specatator等 |
| 全鏈路追蹤 | Zipkin、Brave、Dapper等 |
| 數據流操作開發包 | SpringCloud Stream(封裝與Redis，Rabbit，Kafka等發送接收消息) |
| 時間消息總棧 | SpringCloud Bus |
| 服務部署 | Docker、OpenStack、Kubernetes等 |
為什么選擇SpringCloud作為微服務架構
-
選型依據
- 整體解決方案和框架成熟度
- 社區熱度
- 可維護性
- 學習曲線
-
當前各大IT公司用的微服務架構有那些？
-
阿里：dubbo+HFS
-
京東：JFS
-
新浪：Motan
-
當當網：DubboX
…
-
-
各微服務框架對比
| 功能點/服務框架 | Netflix/SpringCloud | Motan | gRPC | Thri t | Dubbo/DubboX |
| —————— | ———————————————————————————— | —————————————————- | ————————— | ———— | —————————— |
| 功能定位 | 完整的微服務框架 | RPC框架，但整合了ZK或Consul，實現集群環境的基本服務注冊發現 | RPC框架 | RPC框架 | 服務框架 |
| 支持Rest | 是，Ribbon支持多種可拔插的序列號選擇 | 否 | 否 | 否 | 否 |
| 支持RPC | 否 | 是(Hession2) | 是 | 是 | 是 |
| 支持多語言 | 是(Rest形式) | 否 | 是 | 是 | 否 |
| 負載均衡 | 是(服務端zuul+客戶端Ribbon)，zuul-服務，動態路由，雲端負載均衡Eureka（針對中間層服務器） | 是(客戶端) | 否 | 否 | 是(客戶端) |
| 配置服務 | Netfix Archaius，Spring Cloud Config Server 集中配置 | 是(Zookeeper提供) | 否 | 否 | 否 |
| 服務調用鏈監控 | 是(zuul)，zuul提供邊緣服務，API網關 | 否 | 否 | 否 | 否 |
| 高可用/容錯 | 是(服務端Hystrix+客戶端Ribbon) | 是(客戶端) | 否 | 否 | 是(客戶端) |
| 典型應用案例 | Netflix | Sina | Google | Facebook | |
| 社區活躍程度 | 高 | 一般 | 高 | 一般 | 2017年后重新開始維護，之前中斷了5年 |
| 學習難度 | 中等 | 低 | 高 | 高 | 低 |
| 文檔豐富程度 | 高 | 一般 | 一般 | 一般 | 高 |
| 其他 | Spring Cloud Bus為我們的應用程序帶來了更多管理端點 | 支持降級 | Netflix內部在開發集成gRPC | IDL定義 | 實踐的公司比較多 |
SpringCloud入門概述
SpringCloud是什么？
Spring官網：https://spring.io/
SpringCloud和SpringBoot的關系
- SpringBoot專注於開發方便的開發單個個體微服務；
- SpringCloud是關注全局的微服務協調整理治理框架，它將SpringBoot開發的一個個單體微服務，整合並管理起來，為各個微服務之間提供：配置管理、服務發現、斷路器、路由、為代理、事件總棧、全局鎖、決策競選、分布式會話等等集成服務；
- SpringBoot可以離開SpringCloud獨立使用，開發項目，但SpringCloud離不開SpringBoot，屬於依賴關系；
- SpringBoot專注於快速、方便的開發單個個體微服務，SpringCloud關注全局的服務治理框架；
Dubbo 和 SpringCloud技術選型
1. 分布式+服務治理Dubbo
目前成熟的互聯網架構，應用服務化拆分 + 消息中間件
2. Dubbo 和 SpringCloud對比
可以看一下社區活躍度：
https://github.com/spring-cloud
對比結果：
| Dubbo | SpringCloud | |
|---|---|---|
| 服務注冊中心 | Zookeeper | Spring Cloud Netfilx Eureka |
| 服務調用方式 | RPC | REST API |
| 服務監控 | Dubbo-monitor | Spring Boot Admin |
| 斷路器 | 不完善 | Spring Cloud Netfilx Hystrix |
| 服務網關 | 無 | Spring Cloud Netfilx Zuul |
| 分布式配置 | 無 | Spring Cloud Config |
| 服務跟蹤 | 無 | Spring Cloud Sleuth |
| 消息總棧 | 無 | Spring Cloud Bus |
| 數據流 | 無 | Spring Cloud Stream |
| 批量任務 | 無 | Spring Cloud Task |
最大區別：Spring Cloud 拋棄了Dubbo的RPC通信，采用的是基於HTTP的REST方式
嚴格來說，這兩種方式各有優劣。雖然從一定程度上來說，后者犧牲了服務調用的性能，但也避免了上面提到的原生RPC帶來的問題。而且REST相比RPC更為靈活，服務提供方和調用方的依賴只依靠一紙契約，不存在代碼級別的強依賴，這個優點在當下強調快速演化的微服務環境下，顯得更加合適。
品牌機和組裝機的區別
社區支持與更新力度的區別
總結：二者解決的問題域不一樣：Dubbo的定位是一款RPC框架，而SpringCloud的目標是微服務架構下的一站式解決方案。
SpringCloud能干嘛？
- Distributed/versioned configuration 分布式/版本控制配置
- Service registration and discovery 服務注冊與發現
- Routing 路由
- Service-to-service calls 服務到服務的調用
- Load balancing 負載均衡配置
- Circuit Breakers 斷路器
- Distributed messaging 分布式消息管理
- …
SpringCloud下載
官網：http://projects.spring.io/spring-cloud/
版本號有點特別：
SpringCloud有些並沒有采用數字編號的方式命名版本號，而是采用了倫敦地鐵站的名稱，同時根據字母表的順序來對應版本時間順序，比如最早的Realse版本：Angel，第二個Realse版本：Brixton，然后是Camden、Dalston、Edgware，目前最新的是2020.0.3 CURRENT GA通用穩定版。
自學參考書：
- SpringCloud Netflix 中文文檔：https://springcloud.cc/spring-cloud-netflix.html
- SpringCloud 中文API文檔(官方文檔翻譯版)：https://springcloud.cc/spring-cloud-dalston.html
- SpringCloud中國社區：http://springcloud.cn/
- SpringCloud中文網：https://springcloud.cc
Spring Cloud 五大組件
- 服務注冊與發現——Netflix Eureka
- 負載均衡：
- 客戶端負載均衡——Netflix Ribbon
- 服務端負載均衡：——Feign(其也是依賴於Ribbon，只是將調用方式RestTemplete 更改成Service 接口)
- 斷路器——Netflix Hystrix
- 服務網關——Netflix Zuul
- 分布式配置——Spring Cloud Config