sprng cloud怎么安全下線微服務節點

本篇內容主要講解“sprng cloud怎么安全下線微服務節點”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“sprng cloud怎么安全下線微服務節點”吧!

spring cloud 在國內應該興起于2015年，當時業界還面臨著是doubbo還是spring cloud 的爭論。實踐是檢驗真理的唯一標準，目前doubbo應該只能生活在遺留項目之中。

spring cloud是什么已經高頻面試題。本文不準備回答這么高大上的問題，只簡單探討一下spring cloud業務節點下線的問題。

節點非安全下線可能導致的問題
一般來說在生產環境不會無理由的offline一個節點，其場景通常中異常宕機，部署發布，本次主要從灰度發布這個場景來理解非安全下線的隱患。其主要特征是數據不一致及業務中斷。

下線服務手段及優缺點
可手段

優點    缺點
kill    快，Shutdown hook    除了快都是缺點
/shutdown    和方式一類似    和方式一類似
/service-registry/down（推薦）    標記eureka狀態down    只能控制服務發現流量
/pause    標記eureka狀態down    
開啟helthcheck后沖突

只能控制eureka流量

delete

/eureka/apps/{application.name}/

心里安慰    Eureka客戶續約后狀態變更為up
DiscoveryManager.getInstance().

shutdownComponent();

支持手寫下線接口    
shutdown之后如果想start就比較困難

只能控制服務發現流量

PUT /eureka/v2/apps/appID/instanceID/status?value=OUT_OF_SERVICE（推薦）    強制下線    
可修改為up恢復狀態

只能控制服務發現流量

一個正常的下線流程建議是1.修改eureka狀態，但服務仍可運行。2.監控節點流量。3.物理下線。這個寫一個自動化工具或者人工確認完成。

流量入口多樣化挑戰

以user-serivce為例，一般服務的流量入口為外部流量負載均衡nginx，內部流量eureka以及來自于消息驅動的kafka/rabbit之類。

上述控制eureka的手段僅能解決loan-service等內部流量的問題，假如將eureka狀態修改為out_of_service此時消息隊列仍然會進行消費，監控流量可能會漏掉對消息隊列的監控，從而導致物理下線期間消費消息線程被kill，如果消息消費確認機制不恰當產生消息丟失。

消息隊列pause
以kafka為例進行消息pause

@Autowired
    private KafkaListenerEndpointRegistry kafkaListenerEndpointRegistry;
    
    public void pause() {
        kafkaListenerEndpointRegistry.getListenerContainers().forEach(c->c.pause());
    }
    
    public void start() {
        kafkaListenerEndpointRegistry.getListenerContainers().forEach(c->{
            if(c.isRunning()) {
                c.start();
            }else {
                c.resume();
            }
        });
    }

到此，相信大家對“sprng cloud怎么安全下線微服務節點”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！