0.前后端動靜分離的登錄驗證：沒有實際的session概念了沟启，通過token實現(xiàn)驗證操作
1.SpringCloud主要技術點：
* Eureka服務發(fā)現(xiàn)：
是Spring Cloud Netflix微服務套件中的一部分躺坟，基于Netflix Eureka做了二次封裝邻辉，主要負責微服務架構中的服務治理功能
* Ribbon負載均衡、Hystrix斷路器刨沦、Feign代理
* Zuul網(wǎng)關/Config/Bus/Stream
* SpringCloud Bus 分布式消息隊列天然實現(xiàn)：Kafka和RabbitMQ
* Bus：消息總線，基于Config（配置中心）
* Zuul+Redis實現(xiàn)token登錄驗證
* Activiti工作流
2.阿里巴巴的Dubbo中的服務發(fā)現(xiàn)（治理）的幾個概念：
* 服務的提供者（Provider）
* 服務的調用者（Consumer）
* 注冊中心（服務發(fā)現(xiàn)配置中心）（Registry）
3.Spring Cloud服務治理（發(fā)現(xiàn)）只需要遵循Spring配置文件配置即可：
* 在pom.xml中引入響應的配置
* 在主入口（Application類）中加入@EnableEurekaServer注解
* 在配置文件中對服務中心進行對應的配置
*
4.微服務架構：是一項在云中部署應用和服務的新技術（需要合理的定義業(yè)務邊界）
* 可以以模塊為邊界，進行定義微服務（清晰的業(yè)務邊界）
* 高度的模塊化服務
* 每個模塊都能完成自己的功能稻扬，并且每個模塊都可以使用自己本身所需的技術
* 獨立部署運行
* 可以相互進行通信，可以使用Rest方式羊瘩，也可以使用RPC方式泰佳，更可以使用消息中間件進行消息總線處理
5.垂直系統(tǒng)VS微服務
* 垂直系統(tǒng)：傳統(tǒng)行業(yè)的業(yè)務系統(tǒng)
* 垂直系統(tǒng)的弊端（微服務的優(yōu)點）：
* 隨著業(yè)務的增加，復雜性逐漸變高尘吗，代碼耦合太深逝她，不利于開發(fā)和維護
* 技術債務逐漸加劇
* 阻礙新技術的加入和使用，只能依賴于原有技術框架開發(fā)
* 無法進行高可用睬捶，負載均衡黔宛、水平擴展和合理的伸縮
* 部署的服務速度會隨著代碼的累積，逐漸變慢侧戴，性能降低
6.微服務優(yōu)缺點：
* 優(yōu)點：
* 擴展性強宁昭，便于開發(fā)和維護跌宛，局部修改簡單
* 啟動較快，性能积仗，壓力測試更有針對性疆拘。調節(jié)cpu，內(nèi)存寂曹，磁盤IO性能等參數(shù)指標方便哎迄。
* 技術棧不受限制，可以使用任何技術框架隆圆、編程語言等
* 可伸縮性漱挚、擴展性、高可用性等
* 缺點：
* 運維要求比較高渺氧，需要分布式監(jiān)控旨涝，自動化部署測試等
* 分布式的復雜性，邏輯復雜侣背，以及分布式事務等
* 接口調試白华，模塊與模塊之間聯(lián)調測試比較復雜
7.SpringCloud與Dubbo主要區(qū)別：
* Springcloud主要通過http直連的方式進行通信，而dubbo底層通過netty的方式進行通信
* Springcloud沒有明確的服務提供者和服務發(fā)現(xiàn)的概念贩耐，任何服務都是可以成為服務提供者弧腥，而dubbo具有明顯的服務提供者（provider）和服務發(fā)現(xiàn)者（consumer）
8.高可用Eureka服務注冊中心：只需要建立兩個Eureka服務，把兩個注冊中的地址相互配置潮太，都配置到對方地址即可管搪。
9.服務發(fā)現(xiàn)注冊機制：
image.png
* 服務注冊：服務提供者在啟動時會通過發(fā)送REST請求的方式將自己注冊到Eureka服務器上，同時帶上了自身服務的一些元素信息铡买，Eureka收到這個REST請求后更鲁，將元數(shù)據(jù)信息存儲在一個雙層結構map中，其中第一層的key是服務名寻狂，第二層的key是具體服務實例名岁经。
* 服務同步：如上圖所示朋沮，這里的兩個服務提供者分別注冊到兩個不同的注冊中心上蛇券，也就是說他們的信息分別被兩個服務注冊中心維護，此時由于服務注冊中心也相互注冊服務的關系樊拓，當服務提供者發(fā)送注冊請求到一個服務注冊中心的時候纠亚，他會將該請求轉發(fā)給集群中的其他注冊中心，從而實現(xiàn)注冊中心之間服務同步過程筋夏。通過服務同步蒂胞，兩個服務提供者的服務信息通過兩臺服務注冊中心的任何一臺獲取到。（通過HTTP的方式進行數(shù)據(jù)同步）
* 服務續(xù)約：服務注冊完成后条篷，服務提供者會維護一個心跳骗随，來持續(xù)告訴注冊中心蛤织，該服務還活著，以防止注冊中心“剔除該服務”
* 獲取服務：當我們啟動消費者的時候鸿染，它會發(fā)送一個REST請求給注冊中心指蚜，獲取上面的所有服務清單，并且為了性能考慮涨椒。返回給客戶端的清單緩存默認每隔30s更新一次摊鸡。
* 服務調用：消費者獲得清單后，通過服務名可以獲得具體提供服務的實例名和該實例的元數(shù)據(jù)信息蚕冬。因為有這些服務實例的詳細信息免猾，客戶端可以根據(jù)自己的需求，決定調用哪個服務實例囤热。在ribbon中會默認采用輪詢的方式進行服務調用猎提，從而實現(xiàn)負載均衡機制。
* 服務下線：在系統(tǒng)運行中必然會出現(xiàn)關閉或者重啟某個實例的情況旁蔼，在關閉服務期間忧侧，我們自然不希望調用到已經(jīng)下線的服務，所以在客戶端程序中牌芋，當服務正常關閉操作時蚓炬，它會觸發(fā)一個服務下線的REST請求給注冊中心，通知其下線躺屁，當然注冊中心收到該請求后肯夏，把其他服務列表狀態(tài)改為下線，并把事件傳播給集群其他節(jié)點犀暑。當出現(xiàn)非正常下線（如內(nèi)存溢出驯击，斷電等）時，注冊中心可能并沒有收到正常的下線通知請求耐亏，這種情況徊都，Eureka內(nèi)部會有個定時任務，每隔一段時間檢查超時的清單進行清除操作广辰。（服務下線不是Eureka server掛了暇矫，而是服務提供者下線）
