資訊專欄INFORMATION COLUMN
摘要：熔斷機制為了防止雪崩效應事件的發生，分布式系統采用了熔斷機制。為了解決這一難題，微服務架構引入了熔斷機制。由于微服務系統是分布式系統，服務與服務之間沒有任何的禍合。
1.2.1 什么是微服務
按業務劃分為一個獨立運行的程序，即服務單元。
服務之間通過 HTTP 協議相互通信。
自動化部署。
可以用不同的編程語言。
可以用不同的存儲技術。
服務集中化管理。
微服務是一個分布式系統。 根據這些特點，下面來進一步闡述微服務。
微服務單元按業務來劃分
微服務的“微”到底需要定義到什么樣的程度，這是一個非常難以界定的概念，可以從以 下 3 個方面來界定：
一是根據代碼量來定義，根據代碼的多少來判斷程序的大小：
二是根據開 發時間的長短來判斷：
三是根據業務的大小來劃分。
微服務通過 HTTP 來互相通信
按照業務劃分的微服務單元獨立部署， 并運行在各自的進程中。微服務單元之間的通信方 式一般傾向于使用 HTTP 這種簡單的通信機制，更多的時候是使用RESTful API的。這種接受 請求、處理業務邏輯、返回數據的 HTTP 模式非常高效，并且這種通信機制與平臺和語言無關。 例如用 Java 寫的服務可以消費用 Go 語言寫的服務，用 Go寫的服務又可以消費用 Ruby 寫的服務。 不同的服務采用不同的語言去實現，不同的平臺去部署，它們之間 使用 HTTP 進行通訊。
服務與服務之間也可以通過輕量級的消息總線來通 信，例如 RabbitMQ、 Kafaka 等。通過發送消息或者訂閱 消息來達到服務與服務之間通信的目的。
服務與服務通信的數據格式， 一般為 JSON、 XML, 這兩種數據格式與語言、平臺、通信協議無關。一般來 說， JSON 格式的數據比 XML 輕量，井且可讀性也比 X1在L 要好。另外一種就是用 Protobuf進行數據序列化，經過序列化的數據為二進制數據，它比 JSON 更輕量。 用 Protobuf序列化的數據為二進制數據，可讀性非常差， 需要反序列化才能夠讀懂。由于用 Protobuf序列化的數據更為輕量，所以 Protobuf在通信協議 和數據存儲上十分受歡迎。
服務與服務之間通過 HTTP 或者消息總線的方式進行通信，這種方式存在弊端，其通信機 制是不可靠的，雖然成功率很高，但還是會有失敗的時候。
微服務的數據庫獨立
在單體架構中，所有的業務都共用一個數據庫。隨著業務量的增加，數據庫的表的數量越 來越多，難以管理和維護，并且數據量的增加會導致查詢速度越來越慢。例如， 一個應用有這 樣幾個業務：用戶的信息、用戶的賬戶、用戶的購物車、數據報表服務等。
微服務的一個特點就是按業務劃分服務，服務與服務之間無稠合，就連數據庫也是獨立的。 一個典型的微服務的架構就是每個微服務都有自己獨立的數據庫，數據庫之間沒有任何聯系。 這樣做的好處在于，隨著業務的不斷擴張，服務與服務不需要提供數據庫集成，而是提供 API 接口相互調用：還有一個好處是數據庫獨立，單業務的數據盆少，易于維護，數據庫性能有著 明顯的優勢，數據庫的遷移也很方便。
微服務的自動化部署
在微服務架構中，系統會被拆分為若干個微服務， 每個微服務又是一個獨立的應用程序。 單體架構的應用程序只需要部署一次，而微服務架構有多少個服務就需要部署多少次。隨著服 務數量的增加，如果微服務按照單體架構的部署方式，部署的難度會呈指數增加。業務的粒度 劃分得越細，微服務的數量就越多，這時需要更穩定的部署機制。隨著技術的發展，尤其是 Docker 容器技術的推進，以及自動化部署工具（例如開源組件 Jenkins）的出現，自動化部署 變得越來越簡單。
服務集中化管理
微服務系統是按業務單元來劃分服務的，服務數量越多， 管理起來就越復雜，因此微服務 必須使用集中化管理。目前流行的微服務框架中，例如 Spring Cloud 采用 Eureka 來注冊服務 和發現服務，另外， Zookeeper、 Consul 等都是非常優秀的服務集中化管理框架。
分布式架構
分布式系統是集群部署的，由很多計算機相互協作共同構成，它能夠處理海量的用戶請求。
微服務架構是分布式架構， 分布式系統比單體系統更加復雜，主要體現在服務的獨立性和服 務相互調用的可靠性，以及分布式事務、全局鎖、 全局 Id 等， 而單體系統不需要考慮這些復雜性。
分布式系統的應用都是集群化部署， 會給數據一致性帶來困難。
分布式系統中的服 務通信依賴于網絡， 網絡不好，必然會對分布式系統帶來很大的影響。
在分布式系統中，服務 之間相互依賴，如果一個服務出現了故障或者是網絡延遲，在高并發的情況下，會導致線程阻 塞，在很短的時間內該服務的線程資源會消耗殆盡，最終使得該服務不可用 。由于服務的相互 依賴，可能會導致整個系統的不可用，這就是“雪崩效應”。為了防止此類事件的發生，分布式 系統必然要采取相應的措施，例如“熔斷機制”。
熔斷機制
為了防止“雪崩效應”事件的發生，分布 式系統采用了熔斷機制。在用 Spring Cloud 構 建的微服務系統中，采用了熔斷器（即 Hystrix 組件的 Circuit Breaker）去做熔斷。 例如在微服務系統中，有 a、 b、 c、 d、 e、 f、 g、 h 等多個服務，用戶的請求通過網關后， 再到具體的服務，服務之間相互依賴，例如服 務 b 依賴于服務 f， 一個對外暴露的 API 接口 需要服務 b 和服務 f相互協作才能完成。
如果此時服務 b 出現故障或者網絡延遲， 在高并發的情況下，服務 b 會出現大量的線程阻塞，有可能在很短的時間內線程資源就被消耗完了，導致服務 b 的不可用。如果服務 b 為較底層的服務，會影響到其他服務，導致其他服務會一直等待服務 b 的處理。 如果服務 b 遲遲不 處理，大量的網絡請求不僅僅堆積在服務 b，而且會堆積到依賴于服務 b 的其他服務。而因服 務 b 出現故障影響的服務，也會影響到依賴于因服務 b 出現故障影響的服務的其他服務，從而 由 b 開始，影響到整個系統，導致整個系統的不可用。這是一件非常可怕的事，因為服務器運 營商的不可靠，必然會導致服務的不可靠，而網絡服務商的不可靠性，也會導致服務的不可靠。 在高并發的場景下，稍微有點不可靠，由于故障的傳播性，會導致大量的服務不可用，甚至導 致整個系統崩潰。
為了解決這一難題，微服務架構引入了熔斷機制。當服務 b 出現故障，請求失敗次數超過 設定的閥值之后，服務 b 就會開啟熔斷器，之后服務 b 不進行任何的業務邏輯操作，執行快速 失敗，直接返回請求失敗的信息。其他依賴于 b 的服務就不會因為得不到響應而線程阻塞，這時除了服務 b 和依賴于服務 b 的部分功能不可用外， 其他功能正常。
熔斷器還有另外一個機制，自我修復的 機制。當服務 b 熔斷后，經過一段時間，半打 開熔斷器。半打開的熔斷器會檢查一部分請求 是否正常，其他請求執行快邊失敗，檢查的請求如果響應成功，則可以判定服務 b 正常了， 就會關閉服務 b 的熔斷器；如果服務 b 還不正 常，則繼續打開熔斷器。 這種自我熔斷機制和 自我修復機制在微服務架構中有精重要的意義， 一方面，它使程序更加健壯，另一方面， 為開發和運維減少很多不必要的工作。
熔斷組件往往會提供一系列的監控，例如服務可用與否、熔斷器是否被打開、目前 的吞吐量、網絡延遲狀態的監控等，從而很容易讓開發人員和運維人員實時地了解服務的狀況。
1.將一個復雜的業務分解成若干小的業務，每個業務拆分成一個服務，服務的邊界明 確，將復雜的問題簡單化。服務按照業務拆分， 編碼也是按照業務來拆分，代碼的可讀性和可 擴展性增加。新人加入團隊，不需要了解所有的業務代碼，只需要了解他所接管的服務的代碼，新人學習時間成本減少。
2.由于微服務系統是分布式系統，服務與服務之間沒有任何的禍合。 隨著業務的增加， 可以根據業務再拆分服務， 具有極強的橫向擴展能力。隨著應用的用戶量的增加，井發量增加， 可以將微服務集群化部署，從而增加系統的負載能力。簡而言之，微服務系統的微服務單元具 有很強的橫向擴展能力。
3.服務與服務之問通過 HTTP 網絡通信協議來通信，單個微服務內部高度禍合，服務與 服務之間完全獨立，無調合。這使得微服務可以采用任何的開發語言和技術來實現。開發人員 不再被強迫使用公司以前的技術或者已經過時的技術，而是可以 自由選擇最適合業務場景的或 者最適合自己的開發語言和技術，提高開發效率、降低開發成本。
4.如果是一個單體的應用，由于業務的復雜性、代碼的禍合性，以及可能存在的歷史問 題。在重寫一個單體應用時，要求重寫的應用的人員了解所有的業務，所以重寫單體應用是非 常困難的，并且重寫風險也較高。如果是微服務系統，由于微服務系統是按照業務的進行拆分 的，并且有堅實的服務邊界，所以重寫某個服務就相當于重寫某一個業務的代碼，非常簡單。
5.微服務的每個服務單元都是獨立部署的，即獨立運行在某個進程里。微服務的修改和 部署對其他服務沒有影響。試想，假設一個應用只有一個簡單的修改，如果是單體架構，需要 測試和部署整個應用；而如果采用微服務架構，只需要測試并部署被修改的那個服務，這就大 大減少了測試和部署的時間。
6.微服務在 CAP 理論中采用的是 AP 架構，即具有高可用和分區容錯的特點。高可用 主要體現在系統 7 x 24 小時不間斷的服務，它要求系統有大量的服務器集群，從而提高了系 統的負載能力。另外，分區容錯也使得系統更加健壯。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/69584.html
摘要：微服務的設計原則軟件設計每一個版本都在變化，所以軟件設計應該是漸進式發展。在微服務設計時，一定要考慮清楚這三個難題，從而選擇合適的框架。目前比較流行的微服務框架有社區的公司的等。微服務應該具備的功能。 微服務的設計原則 軟件設計每一個版本都在變化，所以軟件設計應該是漸進式發展。 軟件從一開始就不應該被設計成微服務架構，微服務架構固然有優勢，但是它需要更多的資源，包括服務器資源、技術人員...
摘要：負載均衡組件是一個負載均衡組件，它通常和配合使用。和配合，很容易做到負載均衡，將請求根據負載均衡策略分配到不同的服務實例中。和配合，在消費服務時能夠做到負載均衡。在默認的情況下，和相結合，能夠做到負載均衡智能路由。 2.2.1 簡介 Spring Cloud 是基于 Spring Boot 的。 Spring Boot 是由 Pivotal 團隊提供的全新 Web 框架， 它主要的特點...
摘要：微服務的復雜度框架知識服務于服務通信服務與服務之間相互依賴。服務的部署可選用。指服務的可用性。微服務系統通常是一個系統，即同時滿足了可用性和分區容錯。兩階段提交，將事務分成兩部分能夠大大提高分布式事務成功的概率。 主要體現在如下方面。 微服務的復雜度（框架知識、服務于服務通信、服務與服務之間相互依賴）。 分布式事務（重點）。 服務的劃分（業務場景劃分邊界，最好無耦合，都能單獨運行和替...
摘要：單體架構簡介經典的層模型，即表示層業務邏輯層和數據訪問層。口數據訪問層用于操作數據庫，用戶在表示層會產生大量的數據，通過數據訪問層對數據庫進行讀寫操作。 1.1.1 單體架構簡介 經典的 3 層模型，即表示層、業務邏輯層和數據訪問層。 口 表示層： 用于直接和用戶交互，也稱為交互層，通常是網頁、 UI 等。 口 業務邏輯層：即業務邏輯處理層，例如用戶輸入的信息要經過業務邏輯層的處理...
摘要：口服務的負載均衡。服務的注冊與發現接口管理服務注冊是指向服務注冊中心注冊一個服務實例，服務提供者將自己的服務信息如服務名地址等告知服務注冊中心。服務注冊中心會提供服務的健康檢查方案，檢查被注冊的服務是否可用。服務降級的功能。 微服務具有以下的特點。 口 按照業務來劃分服務，單個服務代碼量小，業務單一，易于維護。 口 每個微服務都有自己獨立的基礎組件，例如數據庫、 緩存等，且運行在獨立...
閱讀 1818·2021-11-18 13:21
閱讀 1953·2021-10-18 13:30
閱讀 1539·2021-10-12 10:13
閱讀 906·2021-10-09 09:43
閱讀 5413·2021-09-22 15:13
閱讀 3583·2021-08-11 10:22
閱讀 936·2019-08-30 13:46
閱讀 3520·2019-08-30 13:21
