微服務的那些事

2021-09-22 18:30:53 字數 2947 閱讀 1865

服務提供者如何發布乙個服務,服務消費者如何引用這個服務。具體來說,就是這個服務的介面名是什麼?呼叫這個服務需要傳遞哪些引數?介面的返回值是什麼型別?以及一些其他介面描述資訊

最常見的服務發布和引用的方式有三種:

restful api (一般對外)

xml配置 (對內)

idl檔案(跨語言,thrift, grpc)

在微服務架構下,主要有三種角色:服務提供者(rpc server)、服務消費者(rpc client)和服務註冊中心(registry)。

rpc server提供服務,在啟動時,根據服務發布檔案server.xml中的配置的資訊,向registry註冊自身服務,並向registry定期傳送心跳匯報存活狀態。

rpc client呼叫服務,在啟動時,根據服務引用檔案client.xml中配置的資訊,向registry訂閱服務,把registry返回的服務節點列表快取在本地記憶體中,並與rpc sever建立連線。

當rpc server節點發生變更時,registry會同步變更,rpc client感知後會重新整理本地記憶體中快取的服務節點列表。

rpc client從本地快取的服務節點列表中,基於負載均衡演算法選擇一台rpc sever發起呼叫。

註冊中心實現方式

註冊中心的實現主要涉及幾個問題:註冊中心需要提供哪些介面,該如何部署;如何儲存服務資訊;如何監控服務提供者節點的存活;如果服務提供者節點有變化如何通知服務消費者,以及如何控制註冊中心的訪問許可權。

註冊中心必須提供以下最基本的api

除此之外,為了便於管理,註冊中心還必須提供一些後台管理的api,例如:

在進行服務化拆分之後,服務提供者和服務消費者執行在兩台不同物理機上的不同程序內,它們之間的呼叫相比於本地方法呼叫,可稱之為遠端方法呼叫,簡稱rpc。

想要完成遠端呼叫,你需要解決四個問題:

客戶端和服務端如何建立網路連線

客戶端和服務端之間基於tcp協議建立網路連線最常用的途徑有兩種

http通訊

socket通訊

服務端如何處理請求

同步阻塞方式 (適用於連線數比較小的業務場景)

同步非阻塞方式 (用於連線數比較多並且請求消耗比較輕的業務場景,比如聊天伺服器)

非同步非阻塞方式 (用於連線數比較多而且請求消耗比較重的業務場景)

資料傳輸採用什麼協議

最常用的有http協議,它是一種開放的協議,各大**的伺服器和瀏覽器之間的資料傳輸大都採用了這種協議。還有一些定製的私有協議,比如阿里巴巴開源的dubbo協議等。

資料該如何序列化和反序列化

常用的序列化方式分為兩類:

監控物件

監控指標

監控維度

監控系統的步驟

1.資料採集

通常有兩種資料收集方式:

2. 資料傳輸

資料傳輸最常用的方式有兩種:

3. 資料處理

資料處理是對收集來的原始資料進行聚合並儲存。資料聚合通常有兩個維度:

4. 資料展示

資料展示是把處理後的資料以dashboard的方式展示給使用者。資料展示有多種方式,比如曲線圖、餅狀圖、格仔圖展示等。

在微服務架構下,由於進行了服務拆分,一次請求涉及到多個服務呼叫,如果請求失敗,就很難定位是在哪個環節出錯,所以我們需要服務呼叫鏈的追蹤。

服務追蹤的作用

服務追蹤系統原理

它的核心理念就是呼叫鏈:通過乙個全域性唯一的id將分布在各個服務節點上的同一次請求串聯起來,從而還原原有的呼叫關係,可以追蹤系統問題、分析呼叫資料並統計各種系統指標。

服務追蹤系統可以分為三層

一次服務呼叫,服務提供者、註冊中心、網路這三者都可能會有問題,此時服務消費者應該如何處理才能確保呼叫成功呢?這就是服務治理要解決的問題。

常用的服務治理手段

節點管理

服務呼叫失敗一般是由兩類原因引起的,一類是服務提供者自身出現問題,如伺服器宕機、程序意外退出等;一類是網路問題,如服務提供者、註冊中心、服務消費者這三者任意兩者之間的網路出現問題。

無論是服務提供者自身出現問題還是網路發生問題,都有兩種節點管理手段。

註冊中心主動摘除機制

這種機制要求服務提供者定時的主動向註冊中心匯報心跳,註冊中心根據服務提供者節點最近一次匯報心跳的時間與上一次匯報心跳時間做比較,如果超出一定時間,就認為服務提供者出現問題,繼而把節點從服務列表中摘除,並把最近的可用服務節點列表推送給服務消費者。

服務消費者摘除機制

雖然註冊中心主動摘除機制可以解決服務提供者節點異常的問題,但如果是因為註冊中心與服務提供者之間的網路出現異常,最壞的情況是註冊中心會把服務節點全部摘除,導致服務消費者沒有可用的服務節點呼叫,但其實這時候服務提供者本身是正常的。所以,將存活探測機制用在服務消費者這一端更合理,如果服務消費者呼叫服務提供者節點失敗,就將這個節點從記憶體中儲存的可用服務提供者節點列表中移除。

負載均衡

常用的負載均衡演算法主要包括以下幾種。

服務路由

對於服務消費者而言,在記憶體中的可用服務節點列表中選擇哪個節點不僅由負載均衡演算法決定,還由路由規則確定。所謂的路由規則,就是通過一定的規則如條件表示式或者正規表示式來限定服務節點的選擇範圍。

為什麼要制定路由規則呢?主要有兩個原因。

服務容錯

服務呼叫並不總是一定成功的,對於服務呼叫失敗的情況,需要有手段自動恢復,來保證呼叫成功。

服務容錯常用的手段主要有以下幾種。

failback:失敗通知。就是服務消費者呼叫失敗或者超時後,不再重試,而是根據失敗的詳細資訊,來決定後續的執行策略。

failcache:失敗快取。就是服務消費者呼叫失敗或者超時後,不立即發起重試,而是隔一段時間後再次嘗試發起呼叫。

failfast:快速失敗。就是服務消費者呼叫一次失敗後,不再重試。

一般情況下對於冪等的呼叫,可以選擇failover或者failcache,非冪等的呼叫可以選擇failback或者failfast。

微服務那些事 筆記

這本書是2017年的,有些舊,畢竟springcloud更新速度還是挺快的,不過基礎的東西變化不太大。讀後感 這本書語言風趣,用來入門還是可以的。這本書的側重點不在於技術,而是在於工作經驗,難得的好書。這本書一共11章,216頁,算是很精簡了,介紹肯定不全面,也不會太深入,但是對於想快速了解spri...

拒絕服務的那些事

1 拒絕服務攻擊,這個是什麼?ddos 攻擊,即拒絕服務攻擊,黑客主要利用各種方式耗盡主機資源 阻塞主機網路,直接導致目標機器和網路響應緩慢甚至是完全無法正常工作,對目標主機的正常應用帶來很大的影響。2 拒絕服務攻擊,長啥樣?一般目標主機在ddos攻擊下,大量非業務流量湧向目標主機,有如下常見特徵 ...

微服務架構二三事 總論

以前工作中基於dubbo的soa架構用得比較多,現在微服務概念的興起,尤其是spring boot spring cloud的興起使我產生了研究一下微服務架構的興趣 與soa 對比,總體上感覺微服務其實就是soa的乙個特別版,它更強調rest風格 http json 更強調業務的細分和介面單一職責,...