1、微服務簡述#
微服務，是一個小型的服務，也是一種設計理念，將一個大型繁雜的系統拆分為多個小型的服務，進行獨立部署，這些服務在獨立進程中運行，通過特定的協議進行通信
? 優點：
- 輕量化：一個服務不再像一個系統一個繁雜，更加小巧，功能相對單一
- 低耦合：不同的服務模塊之間的依賴性降低，可以更加專注于一個功能的開發
- 靈活性高：可以進行獨立的部署，也可以支持不同開發語言之間進行服務的調用
? 缺點：
- 運維成本高：微服務架構項目往往是由多個微服務構成，隨著服務的增多，項目出現異常時不易查詢根源
- 重復性高：微服務的工具類不能夠被其他服務調用，所以每個微服務都需要進行重復添加該類，導致重復
- 接口調整成本高：一個被多個服務調用的服務一旦更改了接口，那么其他的接口也要做相應的修改，這一修改造成的成本會明顯提高
1.1 常見的微服務框架#
- SpringCloud：SpringBoot基礎上構建的微服務框架，通用組件較多，通信方式基于HTTP的rest方式
- Dubbo：阿里巴巴的服務框架，使用RPC通信
? 在服務通信性能上RPC更強，但是Rest更為靈活
1.2 微服務經?？紤]的問題#
- 網關：提供統一的服務入口
- 服務間調用
- 服務發現：負載均衡時發現可用服務，下線不可用
- 容錯：服務調用失敗的處理方式
- 熔斷：在特定場景下關閉服務的調用，防止錯誤的擴散
- 限流和降級：請求數量過載，進行請求拒絕（限流）或者返回一個預先設置的返回值（降級）
2、SpringCloud簡述#
? SpringCloud是基于SpringBoot實現的微服務框架，為開發人員提供了很多快速構建分布式系統中常見模式的工具，包括配置管理、服務發現、斷路器、智能路由、微代理，控制總線等。
2.1 常用的一些組件#
- Netflix-Eureka：服務注冊與發現
- Netflix-Ribbon：負載均衡，分發請求到不同的服務器，緩解服務器壓力
- Netflix-Hystrix：服務保護與熔斷機制
- Netflix-Zuul：服務網關
- Feign：服務間通訊
- Config：配置中心
2.2 特點#
? Spring Cloud專注于為典型的用例提供良好的開箱即用體驗，并為其他用例提供擴展性機制。
- Distributed/versioned configuration——分布式/版本化配置
- Service registration and discovery——服務注冊和發現
- Routing——路由
- Service-to-service calls——服務到服務呼叫
- Load balancing——負載平衡
- Circuit Breakers——斷路器
- Global locks——全局鎖
- Leadership election and cluster state——主節點投選與聚集狀態
- Distributed messaging——分布式消息傳遞
2.3 與SpringBoot的區別#
- SpringBoot是基于Spring的快速配置腳手架，而SpringCloud是基于SpringBoot的云應用開發工具
- SpringBoot專注于開發單個微服務，SpringCloud關注全局的微服務協調治理框架，用于整合管理SpringBoot開發的一個個微服務
- SpringBoot可以離開SpringCloud獨立開發使用，而SpringCloud離不開SpringBoot
參考地址：
- Spring Cloud中文網-官方文檔中文版：https://www.springcloud.cc
- Spring Cloud中文API文檔：https://www.springcloud.cc/spring-cloud-dalston.html
- Spring Cloud中國社區：http://springcloud.cn/
3、Eureka 服務注冊和發現#
? Eureka是Netflix開發的基于Rest的服務發現框架，SpringCloud基于此進行二次封裝，實現服務的管理。
? 創建一個Eureka服務：
https://www.cnblogs.com/william-m/p/15991511.html
如果沒有Eureka，如何進行服務之間的調用?
? 使用Rest進行調用，先將RestTemplate注冊到Bean，然后：
@RestController
public class MyController {
private static final String REST_URL_PREFIX="http://localhost:8082";
@Autowired
private RestTemplate restTemplate;
@GetMApping("user/getAll")
public User getById(@RequestParam Long id){
return restTemplate.getForObject(REST_URL_PREFIX+"/user/getAll/"+id,User.class);
}
}
3.1 三個角色#
- 注冊中心
- Eureka Server，可以讓其他服務將相關信息注冊進去，然后讓相關服務發現這些服務并來調用
- 服務提供者
- Eureka Client，將自身注冊進Server中，提供自身的主機，端口，運行狀況指示器URL，主頁和其他詳細信息讓其他服務去發現，一般都是完成某些具體業務的服務
- 服務消費者
- Eureka Client，將自身注冊進Server中，發現服務提供者并調用其相關接口，一般僅提供接口供外部調用，然后調用服務提供者的接口完成具體的業務
3.2 AP原則#
C - consistency 強一致性
A - availability 可用性
P - partition tolerance 分區容錯性
? Eureka遵循的是AP原則，Eureka各個節點都是平等的，部分服務節點的下線不會影響正常服務的調用，只要該服務還剩下一個節點在線就可以進行正常的服務訪問，即保證了服務可用，但是并不能保證查詢到的信息是最新的。Zookeeper的CP原則與之不同，Zookeeper會有一個master節點來保證一致性，一旦master節點掛掉，剩余的節點會重新選舉一個leader，而選擇的過程需要時間，這期間會使得該服務癱瘓，所以需要滿足高可用的話該情況是不能夠容忍的。
4、Ribbon 負載均衡#
? Spring Cloud Ribbon是一個基于HTTP和TCP的客戶端負載均衡工具，基于Netflix Ribbon實現，通過輪詢、隨機等算法選擇一個可用服務。
? 目的：將用戶的請求平攤的分配到多個服務上，實現高可用
4.1 客戶端負載均衡與服務器端負載均衡的區別#
? 最大區別：服務清單所存儲的位置
- 服務器端負載均衡
? 客戶端先發送請求到負載均衡服務器，然后由負載均衡服務器通過負載均衡算法，在眾多可用的服務器之中選擇一個來處理請求。
- 客戶端負載均衡
? 客戶端自己維護一個可用服務器地址列表，在發送請求前先通過負載均衡算法選擇一個將用來處理本次請求的服務器，然后再直接將請求發送至該服務器。
4.2 服務調用#
? 邏輯時序：RestTemplate發起請求 → 負載均衡器攔截器攔截 → LoadBalanceClient獲取ILoadBalance → 獲取服務列表 → 根據負載均衡器選擇一個server → 發起請求 → 記錄調用信息
4.3 負載均衡算法重寫#
public class MyBalanceRule extends AbstractLoadBalancerRule {
// 繼承AbstractLoadBalancerRule并重寫choose算法
@Override
public Server choose(Object key) {
return choose(getLoadBalancer(), key);
}
public Server choose(ILoadBalancer lb, Object key) {
if (lb == null) {
return null;
}
Server server = null;
while (server == null) {
if (Thread.interrupted()) {
return null;
}
List<Server> upList = lb.getReachableServers(); // 獲取活著的服務
List<Server> allList = lb.getAllServers(); // 獲取所有服務
int serverCount = allList.size();
if (serverCount == 0) {
return null;
}
// =============================================
// 自定義負載均衡算法
// server = ......
//===============================================
if (server == null) {
Thread.yield();
continue;
}
if (server.isAlive()) {
return (server);
}
server = null;
Thread.yield();
}
return server;
}
}
// 添加配置類，指定負載均衡算法
@Configuration
public class MyRuleConfig {
@Bean
public IRule myRule(){
return new MyBalanceRule();
}
}
5、Feign負載均衡#
? Feign是聲明式的 web service 客戶端，SpringCloud對Feign進行了封裝，可以與Ribbon和Eureka使用以支持負載均衡，只需要創建一個接口并添加@FeignClient("服務名")注解即可。
5.1 Feign和Ribbon的區別#
- Application注解
- Ribbon使用@RibbonClient
- Feign使用@EnableFeignClients
- 服務的指定
- Ribbon在@RibbonClient注解上聲明
- Feign在接口中使用@FeignClient聲明
- 服務的調用
? Ribbon基于HTTP和TCP客戶端的負載均衡器可以自己構建HTTP請求，使用RestTemplate發送服務
? Feign基于Ribbon進行改進，采用接口的方式，將需要調用的服務的方法定義成抽象方法
5.2 Feign的使用#
Consumer應用
啟動類
@EnableFeignClients
@EnableDiscoveryClient
@SpringBootApplication
public class ConsumerApplication {
public static void main(String[] args) {
SpringApplication.run(ChannelApplication.class, args);
}
}
為了調用Product應用服務的接口類
@FeignClient(value = "Product")
public interface ProductService {
@RequestMapping(value = "/user/selectById", method = RequestMethod.GET)
User selectById(@RequestParam(value = "id") Long id);
}
Product應用
controller
@RequestMapping("/user")
@RestController
public class ProductController {
@RequestMapping(value = "selectById", method = RequestMethod.GET)
User selectById(@RequestParam(value = "id") Long id){
return "";
}
}
6 、Hystrix 熔斷#
? Hystrix是一個服務容錯與保護的組件，用于服務降級、服務熔斷、服務限流等等，能夠保證在其中一個服務出現問題的時候，不會出現級聯故障，防止雪崩，提高分布式服務的健壯性。
服務雪崩：微服務之間進行調用的時候，服務F同時被多個服務A、B、C、D調用，此時服務F發生故障（響應時間過長或者不可用等），對于服務ABCD的調用會占用越來越多的系統資源，引起系統整體的崩潰。
也就是說一個微服務的失敗會引發整個系統的崩潰，像雪崩一樣。
6.1 服務降級#
? 將某些服務停掉會i這不進行業務處理，釋放資源來維持主要服務的功能。
6.1.1 使用場景：
- 服務器壓力劇增，為了保證核心業務的正常運行，對于一些不重要的服務進行有策略地不處理或者簡單處理，保證不會和核心業務搶占資源
- 某些服務不可用時，為了避免長時間的等待造成服務的卡頓雪崩，調用該服務時執行備用的降級邏輯，返回友好的提示，保障主題業務不受故障影響
6.1.2 降級方式
- 接口拒絕服務：頁面可以訪問，進行增刪改時提示服務器繁忙
- 頁面拒絕服務：頁面提示繁忙他，跳轉到其他靜態頁面
- 延遲持久化：涉及增刪改時提示稍后查看結構，不立即處理，將數據添加到異步隊列，服務器空閑時處理
- 隨機拒絕服務：隨機拒絕用戶的訪問，用戶體驗差，較少采用
6.2 服務熔斷#
? 應對服務雪崩的一種保險措施，是微服務的鏈路保護機制，是服務降級的一種特殊處理方式。
? 為了應對某個服務故障的情況，保證系統的整體可用性，熔斷器會切斷對該服務的請求，返回一個比較友好的錯誤響應，直到服務恢復正常
6.2.1 三種狀態
? 熔斷機制的三種狀態：
- 熔斷關閉狀態：業務正常訪問時，熔斷器關閉，服務可以正常調用
- 熔斷開啟狀態：服務調用出錯率達到閾值，開啟熔斷，對該服務的所有請求將會被切斷，執行降級方法
- 半熔斷狀態：服務開啟一段時間后進入半熔斷狀態，嘗試恢復服務的調用，允許部分請求的調用并同時進行監控，如果成功率達到預期，則關閉熔斷器，恢復服務的正常調用，否則開啟熔斷。
6.2.2 實現步驟
- 當服務出現故障使得服務的調用失敗率達到一個閾值，熔斷器開啟
- 在熔斷器開啟時，對該服務的調用會轉向設置的fallback降級方法，防止雪崩
- 當熔斷器開啟達到一定的時間，進入半熔斷狀態，允許部分請求的調用，同時監控其成功率
- 如果該服務的調用成功率達到預期，關閉熔斷器，恢復原有服務的調用邏輯，否則繼續開啟熔斷，重復234
示例：
// 在getUserById方法出現故障時執行getUserFallBack方法
@HystrixCommand(fallbackMethod = "getUserFallBack")
@GetMapping(value="getUserNameById")
public String getUserById(Long id){
return UserService.selectById(id);
}
public String getUserFallBack(){
return "請稍后再試";
}
6.3 熔斷、降級、限流處理服務#
熔斷：直接切斷服務的調用
降級：犧牲非核心業務保證核心服務的正常
限流：服務訪問量達到閾值后拒絕多余的調用
7、Zuul網關#
? Zuul是一個微服務網關。網關：是一個網絡系統的前置入口。也就是說要想訪問一個有網關的網絡系統請求相應的服務，需要先進入網關，然后路由到相應的服務。
? 通常是組成一個系統的微服務很多、或者有權限要求時需要用到網關。
7.1 網關的作用#
- 統一入口
- 為全部的服務提供一個統一的入口，將內外隔離，保障了服務的安全性
- （如：多個微服務組成的系統擁有一個統一的請求入口）
- 鑒權校驗
- 識別每一個請求的權限，拒絕不符合要求的請求
- （如：校驗用戶的請求權限）
- 動態路由
- 動態地將請求路由到不同的后端集群中
- 減少耦合
- 減少客戶端和服務端的耦合程度，使得服務可以獨立發展，通過網關層來映射
7.2 過濾器#
? Zuul提供一個過濾器，父類為ZuulFilter，用來過濾代理請求，提供額外的功能邏輯（這點類似于AOP），包括前置過濾、路由后過濾、后置過濾、異常過濾。
? ZuulFilter包含的抽象方法：filterType、filterOrder、shouldFilter、run
- filterType
- 返回一個字符串，代表過濾器的類型
- pre：前置過濾，在請求路由之前執行，如：身份認證、日志記錄等
- router：在路由執行后，服務調用前被調用
- error：處理請求發生錯誤時調用
- post：請求到達服務之后執行，如：添加響應頭，記錄響應日志
?
- filterOrder
- 過濾器的執行順序，數值越小，優先級越高
- shouldFilter
- 是否執行該過濾器，true，false
- run
- 執行相關業務邏輯
8、Config配置中心#
? 當微服務眾多的時候，想要管理各個服務的配置時過于繁雜，SpringCloud Config則可以用來對每個微服務的配置進行集中的管理。可以實現權限管控、灰度發布、版本管理、格式檢驗、安全配置等。
灰度發布：在進行產品研發時，新版本的發布可能存在一定的風險，那么讓一部分用戶繼續使用A特性，并且提供B特性讓部分用戶使用，如果B特性口碑良好，產品穩定，就可以逐漸進行用戶的遷移?；叶劝l布保證發生問題可以及時解決。就像是打游戲有個測試版本，如果測試用戶對該版本滿意，則可以繼續發布到正式，用戶不滿意就能及時補救，反正沒有發布到正式。
作用：
- 集中管理配置文件
- 在服務運行期間實現動態的配置刷新
- 實現屬性值的加密解密
- 可以實現基于GIT進行版本管理
特點：
- 中心化管理
- 不限語言
- 靈活的版本控制
文章來自
https://www.cnblogs.com/william-m/p/16153557.html
