資訊專欄INFORMATION COLUMN
摘要：口服務的負載均衡。服務的注冊與發現接口管理服務注冊是指向服務注冊中心注冊一個服務實例，服務提供者將自己的服務信息如服務名地址等告知服務注冊中心。服務注冊中心會提供服務的健康檢查方案，檢查被注冊的服務是否可用。服務降級的功能。
微服務具有以下的特點。
口 按照業務來劃分服務，單個服務代碼量小，業務單一，易于維護。 口 每個微服務都有自己獨立的基礎組件，例如數據庫、 緩存等，且運行在獨立的進程中。 口 微服務之間的通信是通過 HTTP 協議或者消息組件，且具有容錯能力。 口 微服務有一套服務治理的解決方案，服務之間不相合，可以隨時加入和剔除服務。 口 單個微服務能夠集群化部署，并且有負載均衡的能力。 口 整個微服務系統應該有一個完整的安全機制，包括用戶驗證、權限驗證、資源保護等。 口 整個微服務系統有鏈路追蹤的能力。 口 有一套完整的實時日志系統。
微服務的功能主要 體現在以下兒個方面。
口 服務的注冊和發現。 口 服務的負載均衡。 口 服務的容錯。 口 服務網關。 口 服務配置的統一管理。 口 鏈路追蹤。 口 實時日志。2.1.1 服務的注冊與發現（接口管理）
服務注冊是指向服務注冊中心注冊一個服務實例，服務提供者將自己的服務信息（如服務 名、 IP 地址等〉告知服務注冊中心。服務發現是指當服務消費者需要消費另外一個服務時， 服務注冊中心能夠告知服務消費者它所要消費服務的實例信息（如服務名、 IP 地址等〉。通常 情況下， 一個服務既是服務提供者，也是服務消費者。服務消費者一般使用 HTTP 協議或者消息組件這種輕盤級的通信機制來進行服務消費。
服務注冊中心會提供服務的健康檢查方案，檢查被注冊的服務是否可用。通常一個服 務實例注冊后，會定時向服務注冊中心提供 “心跳”，以表明自己還處于可用的狀態。當一個服務實例停止向服務注冊中心提供心跳一 段時間后，服務注冊中心會認為該服務實例不可用，會將該服務實例從服務注冊列表中刪除。如果這個被刪除掉的服務實例過一段時間 后繼續向注冊中心提供心跳，那么服務注冊中心會將該服務實例重新加入服務注冊中心的列表中。另外，微服務的服務注冊組件都會提供服 務的健康狀況查看的 UI 界面，開發人員或者運維人員只需要登錄相關的界面就可以知道服務 的健康狀態。
2.1 .2 服務的負載均衡（分發請求）在微服務架構 ，服務之間的相互調用一般是通過 HTTP 通信協議來實現的。網絡往往具有不可靠性，為了保證服務的高可用（High Availability），服務單元往往是集群化部署。將服務提供者進行集群化部署， 那么服務消費者該調用哪個服務提供者的實例呢？這就涉及到 了服務的負載均衡。
所有的服務都向服務注冊中心注冊，服務注冊中心持有每個服務的應用名和 IP 地址等信息，同時每個服務也會獲取所有服務注冊列表信息。
服務消費者集成負載均衡組件，該組件會向服務消費者獲取服務注冊列表信息，并每隔一段時間重新刷新獲取該列表。當服務消費者消費服務時，負載均衡組件獲取服務提供者所 有實例的注冊信息，并通過一定的負載均衡策略（開發者可以配置〉，選擇一個服務提供者的 實例，向該實例進行服務消費，這樣就實現了負載均衡。
服務注冊中心不但需要定時接收每個服務的心跳（用來檢查服務是否可用），而且每 個服務會定期獲取服務注冊列表的信息，當服務實例數量很多時，服務注冊中心承擔了 非常大的負載。由于服務注冊中心在微服務系統中起到了至關重要的作用，所以必須實 現高可用。 一般的做法是將服務注冊中心集群化，每個服務注冊中心的數據實時同步， 如圖 2-3 所示。
將資源進行隔離，如果某個服務里的某個 API 接口出現了故障，只會隔離該 API 接 口。不會影響到其他 API 接口。被隔離的 API 接口會執行快速失敗的邏輯，不會等待，請求不會阻塞。如果不進行這種隔離， 請求會一直處于阻塞狀態， 直到超時。若 有大量的請求同時涌入，都處于阻塞的狀態，服務器的線程資源， 迅速被消耗完。
服務降級的功能。當服務處于正常的狀態時，大量的請求在短時間內同時涌入，超過了服務的處理能力，這時熔斷器會被打開，將服務降級，以免服務器因負載過高而出 現故障。
自我修復能力。當因某個微小的故障，例如網絡服務商的問題，導致網絡在短時間內 不可用， 熔斷器被打開。如果不能自我監控、自我檢測和自我修復， 那么需要開發人 員手動地去關閉熔斷器，無疑會增加開發人員的工作量。
Netflix 的 Hystrix 熔斷器開源組件功能非常強大，不僅有烙斷器的功能，還有熔斷器的狀態 監測，并提供界面友好的 UI， 開發人員或者運維人員通過 UI 界面能夠直觀地看到熔斷器的狀 態和各種性能指標。
其余就不做多余講解了，有興趣的同學可以看看前面的文章。
微服務系統通過將資源以 API 接口的形式暴露給外界來提供服務。在微服務系統中， API 接口資源通常是由服務網關（也稱 API 網關〉統一暴露，內部服務不直接對外提供 API 資源 的暴露。 這樣做的好處是將內部服務隱藏起來，外界還以為是一個服務在提供服務，在一定程 度上保護了微服務系統的安全。 API 網關通常有請求轉發的作用， 另外它可能需要負責一定的 安全驗證，例如判斷某個請求是否合法，該請求對某一個資源是否具有操作權限等。通常情況 ，網關層以集群的形式存在。在服務網關層之前，有可能需要加上負載均衡層，通常為 Nginx 雙機熱備，通過一定的路由策略， 將請求轉發到網關層。到達網關層后，經過一系列的用戶身 份驗證、權限判斷， 最終轉發到具體的服務。具體的服務經過一系列的邏輯運算和數據操作， 最終將結果返回給用戶 ，此時的架構如圖 2-6 所示。
網關層具有很重要的意義， 具體體現在以下方面。
網關將所有服務的 API 接口資源統一聚合，對外統一暴露，外界系統調用的 API 接口都是網關對外暴露的 API 接口。外界系統不需要知道微服務架構中各服務相互調用的復雜性，微服務系統也保護了其內部微服務單元的 API接口，防止被外界直接調用以及服務的敏感信息對外暴露。
網關可以做一些用戶身份認證、權限認證，防止非法請求操作 API 接口，對內部服務起到保護作用。再前面講過就不再多做描述，有興趣學習的同學可以到前面再看下。
網關可以實現監控功能，實時日志輸出，對請求進行記錄。
網關可以用來做流量監控，在高流量的情況下，對服務進行降級。
實現這些功能，需要做高可用，否則網關很可能成為架構中的瓶頸。 最常用的 網關組件有 Zuul、 Nginx 等。
2.1 .5 服務配置的統一管理在微服務架構中，需要有統一管理配置文件的組件， 例如 Spring Cloud 的 Spring Cloud Config 組件、阿里的 Diamond、百度的 Disconf、攜程的 Apollo 等。 這些配置組件所實現的功 能大體相同，｛旦又有些差別，下面以 Spring Cloud Config 為例來闡述服務配置的統一管理。
首先， Config Server（配置服務〉讀取配置文件倉庫的配置信息，其中配置文件倉庫可以存放在配置服務的本地倉庫，也可以放在遠程的 Git 倉庫（例如GitHub、 Coding 等〉。
配置服務啟動后，讀取配置文件信息，讀取完成的配置信息存放在配置服務的內存中。
當啟動服務 A、B 時，由于服務 A、B 指定了向配置服務讀取配置信息，服務 A、B 向配置服務讀取配置信息。
當服務的配置信息需要修改且修改完成后，向配置服務發送 Post 請求進行刷新，這 時服務 A、B 會向配置服務重寫讀取配置文件。
對于集群化的服務， 可以通過使用消息總線來刷新多個服務實例。如果服務數量較多，對配置 中心需要考慮集群化部署，從而使配置中心高可用，做分布式集群。
2.1.6 服務鏈路追蹤在微服務系統中 ， 一個來自用戶 的請求先達到前端 A C如前端界面），然后通過遠程調用，達到 系統的中間件 B、 c （如負載均衡、網關等），最后達到后端服 務 D、 E。后端經過一系列的業務邏輯計算，最后將數據返回給 用戶。對于這樣一個請求， 經歷了這么多服務， 怎么樣將它的 請求過程的數據記錄下來呢？這就需要用到服務鏈路追蹤。
目前，常見的鏈路追蹤組件有 Google 的 Dapper、 Twitter 的 Zipkin，以及阿里的 Eagleeye （鷹眼）等，都是非常優秀的鏈路追蹤開源組件。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/69708.html
摘要：微服務的設計原則軟件設計每一個版本都在變化，所以軟件設計應該是漸進式發展。在微服務設計時，一定要考慮清楚這三個難題，從而選擇合適的框架。目前比較流行的微服務框架有社區的公司的等。微服務應該具備的功能。 微服務的設計原則 軟件設計每一個版本都在變化，所以軟件設計應該是漸進式發展。 軟件從一開始就不應該被設計成微服務架構，微服務架構固然有優勢，但是它需要更多的資源，包括服務器資源、技術人員...
摘要：負載均衡組件是一個負載均衡組件，它通常和配合使用。和配合，很容易做到負載均衡，將請求根據負載均衡策略分配到不同的服務實例中。和配合，在消費服務時能夠做到負載均衡。在默認的情況下，和相結合，能夠做到負載均衡智能路由。 2.2.1 簡介 Spring Cloud 是基于 Spring Boot 的。 Spring Boot 是由 Pivotal 團隊提供的全新 Web 框架， 它主要的特點...
摘要：微服務的復雜度框架知識服務于服務通信服務與服務之間相互依賴。服務的部署可選用。指服務的可用性。微服務系統通常是一個系統，即同時滿足了可用性和分區容錯。兩階段提交，將事務分成兩部分能夠大大提高分布式事務成功的概率。 主要體現在如下方面。 微服務的復雜度（框架知識、服務于服務通信、服務與服務之間相互依賴）。 分布式事務（重點）。 服務的劃分（業務場景劃分邊界，最好無耦合，都能單獨運行和替...
摘要：單體架構簡介經典的層模型，即表示層業務邏輯層和數據訪問層。口數據訪問層用于操作數據庫，用戶在表示層會產生大量的數據，通過數據訪問層對數據庫進行讀寫操作。 1.1.1 單體架構簡介 經典的 3 層模型，即表示層、業務邏輯層和數據訪問層。 口 表示層： 用于直接和用戶交互，也稱為交互層，通常是網頁、 UI 等。 口 業務邏輯層：即業務邏輯處理層，例如用戶輸入的信息要經過業務邏輯層的處理...
摘要：熔斷機制為了防止雪崩效應事件的發生，分布式系統采用了熔斷機制。為了解決這一難題，微服務架構引入了熔斷機制。由于微服務系統是分布式系統，服務與服務之間沒有任何的禍合。 1.2.1 什么是微服務 按業務劃分為一個獨立運行的程序，即服務單元。 服務之間通過 HTTP 協議相互通信。 自動化部署。 可以用不同的編程語言。 可以用不同的存儲技術。 服務集中化管理。 微服務是一個分布式系統。 ...
閱讀 1531·2021-09-22 15:35
閱讀 2011·2021-09-14 18:04
閱讀 883·2019-08-30 15:55
閱讀 2454·2019-08-30 15:53
閱讀 2684·2019-08-30 12:45
閱讀 1205·2019-08-29 17:01
閱讀 2583·2019-08-29 15:30
閱讀 3520·2019-08-29 15:09
