1. 整體目錄介紹
第一章 微服務介紹
1.1 傳統單體架構
1.2 SOA架構
1.3 微服務架構
1.4 微服務的拆分建議
1.5 微服務與集群的關系
1.6 微服務架構的組件
1.7 SpringBoot與SpringCloud的區別
1.8 SpringCloud與Dubbo區別
1.9 Spring Cloud for Alibaba
第二章 微服務環境搭建
2.1 技術選型
2.2 創建服務
第三章 Nacos注冊/配置中心
3.1 nacos介紹
3.2 nacos入門使用
3.3 服務調用Feign
第四章 GetWay服務網關
4.1 網關介紹
4.2 GetWay入門使用
第五章 Sentinel服務容錯
5.1 高並發帶來的問題
5.2 Sentinel入門使用
第六章 Sleuth鏈路追蹤
第七章 RabbitMQ消息中間件
第八章 SMS短信服務
第九章 Seata分布式事務
2. 傳統單體應用架構
程序在編寫完成之后會被打包並部署為一個具體的應用。Java Web項目打包成WAR包，Java項目打包成JAR包。
但是隨着用戶人數的增加，一台機器可能滿足不了系統的負載，此時我們就會考慮水平擴展。
面對上述情況，我們通常會增加服務器的數量，並將打包好的應用拷貝到不同服務器，然后通過負載均衡器實現應用的水平擴展。
缺點
// 1. 應用維護困難 隨着時間推移項目逐漸變大，一旦項目變得龐大而復雜，就很難進行二次開發與維護。
// 2. 可靠性低 因為所有模塊都運行在一個進程中，任何一個模塊出現問題，都會導致整個進程崩潰，進而影響到整個應用。
// 3. 不利於技術更新 如果需要更改某個技術，可能需要將整個應用重新開發。
3. SOA架構
針對傳統單體架構的問題，企業開始通過SOA【面向服務的架構】來解決。
SOA：把應用中相近的功能聚合到一起，以服務的形式提供出去。即：他將原來的單體架構細分為不同的子系統，再由各個子系統互相調用所需的服務。
優點
// 1. 將項目拆分成若干個子項目，不同的團隊可以負責不同的子項目，從而提高開發效率。
// 2. 把模塊拆分，使用接口通信，降低了模塊之間的耦合度。
// 3. 能夠升級單個服務而無需重寫整個應用。
缺點
// SOA中各個相互獨立的服務還是部署在同一個Tomcat實例，隨着業務功能的增多，會導致SOA服務越來越復雜。
4. 微服務架構
微服務架構：是一種架構風格和架構思想。
它倡導我們在傳統單體架構的基礎上，將系統按照功能拆分為更加細粒度的服務。
所拆分的每一個服務都是一個獨立的應用，單獨部署。這些應用對外提供公共的API，可以獨立承擔對外服務的職責。
圍繞着這一思想的一系列體系結構【開發，測試，部署等等】，我們就可以稱它為“微服務架構”。
優點
// 1. 每個微服務可以獨立部署 當某個微服務發生變更時，不需要重新部署整個項目。
// 2. 技術選型靈活 各個微服務的技術選型可以不一樣，當需要對某個微服務技術升級時，不需要面臨對整個項目的重新開發。
// 3. 復雜度可控 每個微服務專注單個功能，體積小，復雜度低，便於維護。
// 4. 易於容錯 當某個服務發生故障時，在設計良好的情況下，其他服務一般不會被影響。
// 5. 易於擴展 單個服務可以水平擴展，比如：訂單服務訪問高，我可以對其多部署幾個服務。
SOA與微服務區別
SOA項目分為多個子系統，粗粒度。微服務項目分為多個微服務，細粒度。
SOA項目服務部署在一起，互相依賴。微服務項目每個微服務可以獨立部署。
https://mp.weixin.qq.com/s/WKsTHikswGUYugMHKmA3hw
4. 微服務的拆分建議
-
通過業務功能分解並定義與業務功能相對應的服務。
-
按照動詞或用例分解，並定義負責特定操作的服務。例如：一個負責完成訂單的航運服務。
-
通過定義一個對給定實體或資源的所有操作負責的服務。例如：一個負責管理用戶賬戶的賬戶服務。
補充. 分布式微服務與集群的關系
分布式：多個獨立的計算機集合，每個計算機做不同的事，共同支撐一個系統。
集群：多個獨立的計算機集合，每個計算機做相同的事，共同支撐某一個服務。
分布式中的每一個節點也都可以做集群。
5. 微服務架構的組件
前言：開發微服務架構的項目，我們一般采用如下組件。
// 1. 微服務注冊中心 注冊系統中所有服務的地方。
// 2. 服務注冊 服務提供方將自己的調用地址注冊到服務注冊，用於讓服務調用方能夠方便快速地調用自己
// 3. 服務發現 服務調用方從注冊中心找到自己要調用的服務的地址。
// 4. 負載均衡 服務提供方以多實例的形式提供服務，使用負載均衡能讓服務調用方連接到合適的服務節點。
// 5. 服務容錯 通過一系列保護機制，保證服務調用者在調用到異常服務時能快速返回結果，免得長時間等待。
// 6. 服務網關 服務調用的唯一入口，一般用來實現用戶鑒權，動態路由，負載均衡，限流等功能。
// 7. 分布式配置中心 將本地的配置信息注冊到配置中心統一管理。 為什么要統一管理呢？ 各個微服務的配置文件可能不一樣，而且配置在本地，如果要修改配置，修改完需要重啟。有了分布式配置中心，就可以解決這些問題。
// 微服務實例的開發 springBoot
// 服務注冊 eureka zookeeper nacos consul
// 服務發現 feign dubbo
// 負載均衡 ribbon
// 服務容錯 hystrix sentinal
// Api網關 zuul gateway
// 分布式配置中心 springcloud config nacos
// 分布式事務 seata lcn
6. SpringBoot與SpringCloud的區別
SpringCloud
它是在SpringBoot的基礎上構建的，它不是一個具體的技術，而是一個簡化分布式系統構建的工具集。
Spring Cloud中包含多個子項目，如：Spring Cloud Netflix，Spring Cloud Config，Spring Cloud Starters等。
SpringBoot
它是一個用來開微服務實例的。
7. SpringCloud與Dubbo區別
Spring Cloud：本身也是基於SpringBoot開發而來，SpringCloud是一系列框架的有序集合，就是把非常流行的微服務的技術整合到一起。
dubbo：本身只是眾多分布式開發中解決問題的一種方式，它主要是做服務調用，而spring cloud 是一系列的有序集合。
7. Spring Cloud for Alibaba
spring cloud中的幾乎所有的組件都使用Netflix公司的產品【eureka，hystrix，rabbin，zuul，config...】，然后在其基礎上做了一層封裝【比如推出openFeign(對feign進行了一個升級)，推出了gateWay來替換zuul】，還增加了幾個沒什么大作用的組件，然后就推出來了。
然而Netflix公司的18年12月12日宣布的服務旗下產品進行維護，其發現組件Eureka，Hystrix等 已經停止更新，而其他的眾多組件預計會在明年(即2020年)停止維護。如此一來，SpringCloud就要涼涼了。
此時開發者們急需其他的一些替代產品，此時spring cloud alibaba就來了，它是由阿里巴巴提供的。Spring Cloud 這時就急了鴨，他就與spring cloud alibaba達成合作，將Spring cloud alibaba整合到sping cloud，將其作為Spring Cloud 下的子項目。
整合之后，依托 Spring Cloud Alibaba，您只需要添加一些注解和少量配置，就可以將 Spring Cloud 應用接入阿里微服務解決方案，通過阿里提供的某些中間件來迅速搭建分布式應用系統。
說說Spring Cloud Alibaba的版本號
SpringCloud的版本號是英文方式。因為springcloud是微服務的解決方案，他會有很多子項目，每個子項目都維護這自己的版本號，為了避免沖突，就使用了倫敦地鐵站的名字作為版本號。以首字母作為順序，a,b,c,d....排列。
再說咱們國人開發的，我們沒有用英文名，還是數字那種方式。
SpringCloud for alibaba：https://spring.io/projects/spring-cloud-alibaba