微服務概念學習筆記

        Martin Flower曾經說過，微服務的架構風格，就是将單一程式開發成一個微服務，每個微服務運作在自己的程序中，并使用輕量級機制通信，通常是HTTP RESTFUL API。這些服務圍繞業務能力來劃分建構的，并通過完全自動化部署機制獨立部署。這些服務可以使用不同的程式設計語言，以及不同的存儲技術，以保證最低限度的集中式管理。

特點：

1. 按業務劃分為一個獨立運作的程式，即服務單元。
2. 服務之間通過HTTP協定互相通信。
3. 自動化部署。
4. 可以用不同的程式設計語言。
5. 可以用不同的存儲技術。
6. 服務集中化管理。
7. 微服務是一個分布式系統。

闡述：

1. 微服務單元按業務來劃分：這些微服務單元是高度元件化的子產品，提供了穩定的邊界，服務與服務之間沒有任何的耦合，有非常好的擴充性和複用性。
2. 微服務通過HTTP來互相通信。
3. 微服務的資料庫獨立。一個典型的微服務架構就是每個微服務都有自己的資料庫，資料庫之間沒有任何的聯系。優點：單業務的資料量少，易于維護，資料庫性能有着明顯的優勢，資料庫的遷移也很友善。
4. 微服務的自動化部署，（DOCKER,Jenkins）
5. 分布式架構
6. 熔斷機制（Hystrix元件的Circuit Breaker）

優勢：

1. 将一個複雜的服務分解成若幹小的服務，每個業務拆分成一個服務，服務的邊界明确，将複雜問題簡單化。服務按照業務拆分，編碼也是按照業務拆分， 代碼的可讀性和可擴充性增加。新人加入團隊，不需要了解所有的業務代碼，隻需要了解她所接管的服務的代碼，降低學習時間成本。
2. 由于微服務系統是分布式系統，服務與服務之間沒有任何的耦合，随着業務的增加，可以根據業務再拆分業務，具有極強的橫向擴充能力。随着應用的使用者量的增加，并發量增加，可以将微服務叢集化部署， 增加系統的負載能力。
3. 服務與服務之間通過HTTP網絡通信協定來通信，單個微服務内部高度耦合，服務與服務之間完全獨立，無耦合。微服務可以采用任何的開發語言和開發技術來實作。
4. 由于微服務系統是按照業務進行拆分的，并且有堅實的服務邊界，是以重寫某個服務相當于重寫某個業務的代碼，相對于重寫單體應用來說，簡單不少。
5. 微服務的每一個服務單元都是獨立部署的，即獨立運作在某個程序裡。微服務的修改和部署對其他服務沒有影響。
6. 微服務在CAP（Consistency，Availability，Partition-tolerance）理論中采用的是AP架構，具有高可用和分區容錯的特點。

不足

1. 微服務的複雜度
2. 分布式事務（如何保持資料的一緻性？兩階段送出）
3. 服務的劃分（領域驅動設計DDD）
4. 服務的部署 

 兩階段送出：網購買手機，需要在個人賬戶中扣除2000元錢，在手機庫存中将手機庫存數量減1，當然需要在賣方賬戶中增加2000元錢。

        在微服務架構中，賬戶是一個服務，而商品是一個服務，這時不能用資料庫自帶的事務，因為這兩個資料表不在一個資料庫中，是以常常用到兩階段送出。

        第一階段，service-account發起一個分布式事務，交給事務協調器TC處理，事務協調器TC向所有參與事務的節點發送處理事務操作的準備操作，所有的參與節點執行準備操作，将Undo和Redo資訊寫進日志，并向事務管理器傳回準備操作是否成功。

        第二階段，事務管理器收集所有所有節點的準備操作是否成功，如果都成功，則通知所有節點執行送出操作，如果有一個失敗，則執行復原操作。

1.微服務應該具備的特點

• 按業務來劃分，單個服務代碼量小，業務單一，易于維護。
• 每個微服務都有自己獨立的元件，例如資料庫，緩存等，且運作在獨立程序中。
• 微服務之間的通信通過HTTP協定或者消息元件，且具有容錯能力。
• 微服務有一套服務治理的解決方案，服務之間不耦合，可以随時加入或者剔除服務。
• 單個微服務能夠叢集化部署，并且具有負載均衡的能力。
• 整個微服務應該有一個完整的安全機制，包括使用者驗證，資源驗證，權限保護等。
• 整個微服務系統有鍊路追蹤的能力。
• 有一套完整的實時日志系統。

2.微服務主要功能介紹：

2.1 服務的注冊與發現： 為了能夠友善檢視每個微服務執行個體的健康狀态，該系統需要服務注冊中心來統一管理微服務執行個體。服務注冊是指向服務注冊中心注冊一個服務執行個體。服務提供者将自己的服務資訊（服務名，ip位址等）告知服務注冊中心。服務發現是指當服務消費者需要消費另外一個服務時，服務注冊中心能夠告知服務消費者它所要消費服務的執行個體資訊（服務名，ip位址等）。通況下，一個服務既是服務提供者，又是服務消費者，一般使用HTTP協定或是輕量級元件來完成服務消費。

 2.2 服務的負載均衡

        由于服務之間一般都是通過HTTP協定完成互相調用，但是網絡往往具有不可靠性，為了保證服務的高可用（High Availability），服務單元往往叢集化部署。可是如果将的服務提供者進行叢集化部署，那麼服務消費者該調用哪個服務提供者的執行個體呢？這個時候就用到了負載均衡。

        服務的負載均衡的流行做法：所有服務都向服務注冊中心注冊，服務的注冊中心持有每個服務的應用名和ip位址等相關資訊，同時每個服務也會擷取所有服務注冊清單資訊。服務消費者內建負載均衡元件，該元件會向服務消費者擷取服務注冊清單資訊，并每隔一段時間重新重新整理擷取該清單，當服務消費者消費服務時，負載均衡元件擷取服務消費者所有執行個體的注冊資訊，并通過一定的負載均衡政策（由開發者配置），選擇一個服務提供者的執行個體，向該執行個體進行服務消費，這樣就實作了負載均衡。

        服務注冊中心不但需要定時接收每個服務的心跳（檢測服務是否可用），而且每個服務會定期擷取服務注冊清單資訊，當服務執行個體很多時，服務注冊中心承載了非常大的負載，由于服務注冊中心在微服務系統中起到了至關重要的作用，是以必須實作高可用。一般的做法是将服務注冊中心叢集化，每個服務注冊中心資料實時同步。

 2.3 服務的容錯

        微服務落地到實際項目中，服務的數量往往非常多，服務之間的互相依賴性也是錯綜複雜的，一個網絡請求通常要調用多個服務才能完成。如果一個服務不可用，例如網絡延遲或故障，會影響到依賴于這個不可用的服務的其他服務。如下所示，一個微服務系統有許多服務，當服務F因為某些原因導緻了服務的不可用，來自于使用者的網絡請求需要調用服務F，由于服務F無響應，使用者的請求處于阻塞狀态，在高并發的場景下，短時間會導緻伺服器看的線程資源消耗殆盡，另外依賴于服務F的其他服務，也會等待服務F的響應，處于阻塞狀态，導緻這些服務的線程資源消耗殆盡，進而導緻他們不可用，以及依賴于他們的服務不可用，最後導緻整個系統處于癱瘓狀态，也就是雪崩效應。

        為了解決分布式系統的雪崩效應，分布式系統引進了熔斷器機制。熔斷器（Circuit Breaker）

其作用是當電路中出現故障時立即切斷電路，起到保護電路的作用。當一個服務處理使用者失敗請求的次數在一定時間内小于設定的閥值時，熔斷器處于關閉狀态，服務正常，當服務處理使用者請求失敗次數超過設定的閥值時，打開熔斷器，這時所有請求會執行快速失敗，不執行業務邏輯。當熔斷器處于打開狀态時，一段時間會處于半打開狀态，并執行一定數量的請求，剩餘的請求會執行快速失敗，若執行的請求失敗了，會繼續打開熔斷器，若執行成功，會關閉熔斷器。

熔斷器（Netflix的Hystrix）的意義：

• 将資源進行隔離，如果某個服務裡的某個api接口發生了故障，隻會隔離該api接口，不會影響到其他api接口，被隔離的api接口會執行快速失敗的邏輯，不會等待，請求不會阻塞。如果不進行隔離，請求會一直處于阻塞狀态，直到逾時。如果有大量請求同時湧入，都處于阻塞的狀态，伺服器的線程資源會被迅速消耗完。
• 服務降級。當服務處于正常狀态時，大量請求短時間内同時湧入，超過了服務的處理能力，這時熔斷器會被打開，将服務降級，以免伺服器因負載過高而出現故障。
• 自我修複能力。當因某個微小的故障，例如網絡服務商的問題，導緻網絡在短時間内不可用，熔斷器被打開，如果不能自我監控，自我檢測和自我修複，那麼需要開發人員手動的關閉熔斷器，顯然會增加開發人員的工作量。

 2.4 服務的網關

        微服務系統通過将以API接口的形式暴露給外界來提供服務。在微服務系統中，API接口資源通常采用服務網關（也稱API網關）同一暴露，内部服務不直接提供API資源的暴露。API網關有一定的請求轉發的作用，另外他可能需要負責一定的安全驗證，例如判斷某個請求是否合法，該請求對某一資源是否有操作權限等。通況下，網關以叢集方式存在。在服務網關層之前，有可能需要加上負載均衡層，通常為Nginx雙機熱備，通過一定的路由政策，将請求轉發到網關層。到達網關層後，經過一系列的使用者身份驗證，權限判斷，最終轉發到具體的任務，具體的任務經過一系列的邏輯運算和資料操作，最終将結果傳回給使用者。

網關層的意義：

• 網關将所有服務的api接口資源同一聚合，對外同一暴露，外界系統調用的API接口都是網關對外暴露的API接口。
• 網關可以做一些使用者身份認證，權限認證，防止非法請求操作API接口，對内部服務起到保護作用。
• 網關可以實作監控功能，實時日志輸出，對請求進行記錄。
• 網關可以用來做流量監控， 在高流量情況下，對服務進行降級。
• API接口從内部服務中分離出來，友善做測試。

 2.5 服務配置的統一管理

        在實際開發過程中，每個服務都有大量的配置檔案。

•  首先，Config Server(配置服務)讀取配置檔案倉庫的配置資訊，其中配置檔案倉庫可以存放在配置服務的本地倉庫，也可以放在遠端的Git倉庫。
• 配置服務啟動之後，讀取檔案的配置資訊，讀取完成的配置資訊存放在配置服務的記憶體中。
• 當啟動服務A,B時，由于服務A、B指定了向配置服務讀取配置資訊，服務A、B向配置服務讀取配置資訊。
• 當服務配置資訊需要修改且修改完成後，向配置服務發送POST請求進行重新整理，這時服務A,B會向配置服務重寫讀取配置檔案。

• 

2.6 服務的鍊路追蹤

 總結：微服務的設計是漸進式的，是随着業務的發展而發展的。