什麼是微服務

什麼是微服務
簡而言之 : 微服務架構風格這種開發方法,是以開發一組小型服務的方式來開發一個獨立的應用系統的.其中每個小型服務都運行在自己的進行中,並經常採用HTTP資源API
這樣輕量的機制來相互通信.這些服務圍繞業務功能進行構建,並能通過全自動的部署機制來進行獨立部署.這些微服務可以使用不同的語言來編寫,並且可以使用不同的數據
存儲技術.對這些微服務我們僅做最低限度的集中管理.
微服務具備的特性
1. 每個微服務可獨立運行在自己的進程里;
2. 一系列獨立運行的微服務共同構建起了整個系統;
3. 每個服務為獨立的業務開發,一個微服務一般完成某個特定的功能,比如 : 訂單管理,用戶管理等.
4. 微服務之間通過一些輕量的通信機制進行通信,例如通過REST API或者RPC的方式進行調用.
5. 全自動部署機制.
微服務優點
1. 易於開發和維護;
一個微服務只關註一個特定的業務功能,所以它的業務清晰,代碼量較少.開發和維護單個微服務相對是比較簡單的.而整個應用是由著若幹個微服務構建而成的.所以
整個應用也會維持在可控狀態.
2. 啟動較快;
單個微服務代碼量較少,所以啟動會比較快.
3. 局部修改容易部署;
單體應用只要修改,就得重新部署整個應用,微服務解決了這樣的問題.一般來說,對某個微服務進行修改,只需要 重新部署這個服務即可.
4. 技術棧不受限;
在微服務中,我們可以結合項目業務及團隊的特點,合理的選擇技術棧.例如某些服務可使用 關係型資料庫MySQL;某些微服務有圖形計算的需求,我們可以使用Neo4j;甚至可以
根據需要,部分微服務使用java開發,部分微服務使用NodeJS進行開發.
5. DevOps
微服務帶來的挑戰
1. 運維要求較高;
更多的服務意味著更多的運維投入.在單體架構中,只需要保證一個應用的正常運行;而在微服務中,需要保證幾十甚至幾百個服務的正常運行與協作,這給項目的運維帶來了很大挑戰.
2. 分散式的複雜性;
使用微服務構建的是分散式系統.對於一個分散式系統,系統容錯,網路延遲,分散式事務等都給我們帶來了很大的挑戰.
3. 介面調整成本高;
微服務之間通過介面進行通信.如果修改某一個微服務的API,可能所有使用了該介面的微服務都需要做調整.
4. 重覆勞動.
很多服務可能會使用到相同的功能,而這個功能並沒有達到分解為一個微服務的程度,這個時候,可能各個服務都會開發這一功能,從而導致代碼重覆.
微服務設計原則
1. 單一職責原則;
2. 服務自治原則;
3. 輕量級通信原則;
4. 介面明確原則.

雪崩效驗:
當一臺伺服器請求發送到另一臺伺服器,另一臺伺服器由於宕機無法響應,這樣請求的伺服器會一直發送請求,會堆積大量的線程和進程,當堆積到一定程度以後系統資源被
消耗殆盡,這樣這台伺服器也就宕機了,如果其他伺服器訪問這台伺服器也會以此類推的出現無法響應,導致請求伺服器等待響應,無法獲取結果,這樣一臺伺服器接著一臺伺服器
宕機,形成雪崩效驗.

微服務容錯處理方案 :
1. 為請求設置超時
通過網路請求其他服務時，都必須設置超時。正常情況下，一個遠程調用一般在幾十毫秒內就能得到響應了。如果依賴的服務不可用，或者網路有問題，響應時間將會變得很長（幾十秒）。
通常情況下，一次遠程調用對應著一個線程/進程。如果響應太慢，這個線程/進程就得不到釋放。而線程/進程又對應著系統資源，如果得不到釋放的線程/進程越積越多，服務資源就會被耗盡，從而導致服務不可用。
因此，必須為每個請求設置超時，讓資源儘快地得到釋放。
 
2. 使用斷路器
試想一下，如果家庭里沒有斷路器，電流過載了（例如功率過大、短路等），電路不斷開，電路就會升溫，甚至是燒斷電路、起火。有了斷路器之後，當電流過載時，會自動切斷電路（跳閘），從而保護了整條電路與家庭的安全。當電流過載的問題被解決後，只要將關閉斷路器，電路就又可以工作了。
同樣的道理，當依賴的服務有大量超時時，再讓新的請求去訪問已經沒有太大意義，只會無謂的消耗現有資源。譬如我們設置了超時時間為1秒，如果短時間內有大量的請求（譬如50個）在1秒內都得不到響應，就往往意味著異常。此時就沒有必要讓更多的請求去訪問這個依賴了，我們應該使用斷路器避免資源浪費。
斷路器可以實現快速失敗，如果它在一段時間內偵測到許多類似的錯誤（譬如超時），就會強迫其以後的多個調用快速失敗，不再請求所依賴的服務，從而防止應用程式不斷地嘗試執行可能會失敗的操作，這樣應用程式可以繼續執行而不用等待修正錯誤，或者浪費CPU時間去等待長時間的超時。斷路器也可以使應用程式能夠診斷錯誤是否已經修正，如果已經修正，應用程式會再次嘗試調用操作。
斷路器模式就像是那些容易導致錯誤的操作的一種代理。這種代理能夠記錄最近調用發生錯誤的次數，然後決定使用允許操作繼續，或者立即返回錯誤。
Spirng Clound為開發人員提供了快速構建分散式系統中的一些通用模式,是基於SpringBoot的一整套實現微服務的框架.他提供了微服務開發所需的配置管理 ,服務發現,短路器,
智能路由,微代理,控制匯流排,全局鎖,決策競選,分散式會話和集群狀態管理等組件.
子項目:
Spring Cloud Config就是我們通常意義上的配置中心.Spring Cloud Config把應用原本放在本地文件的配置抽取出來放在中心伺服器,本質是配置信息從本地遷移到雲端.
從而能夠提供更好的管理,發佈能力.
Spring Cloud Config分服務端和客戶端,服務端負責將git(svn)中存儲的配置文件發佈成REST介面,客戶端可以從服務端REST介面獲取配置.但客戶端並不能主動感知到配置
的變化,從而主動去獲取新的配置,這需要每個客戶端通過POST方法觸發各自的/refresh.

Spring Cloud Eurka提供在分散式環境下的服務發現,服務註冊的功能.
Spring Clound Netflix,該項目是Spring Cloud的子項目之一,主要內容是對Netflix公司一系列開源產品的包裝,它為Spring Boot應用提供了自配置的Netflix OSS整合.
通過一些簡單的註解,開發者就可以快速的在應用中配置一下常用模塊並構建龐大的分散式系統.它主要提供的模塊包括 : 服務發現 (Eureka), 斷路器(Hystrix), 智能路由(Zuul)
,客戶端負載均衡(Ribbon)等.
Netflix Eureka : 雲端負載均衡,一個基於REST的服務,用於定位服務,以實現雲端的負載均衡和中間層伺服器的故障轉移.
Netflix Hystrix : 容錯管理工具,旨在通過控制服務和第三方庫的節點,從而對延遲和故障提供更強大的容錯能力.
Netflix Zuul : 邊緣服務工具,是提供動態路由,監控,彈性,安全等邊緣服務.
Netflix Archaius : 配置管理API,包含一系列配置管理API,提供動態類型化屬性,線程安全配置操作,輪詢框架,回調機制等功能.

Spring cloud Hystrix熔斷器
斷路器(Cricuit Breaker)是一種能夠在遠程服務不可用時自動熔斷(打卡開關),併在遠程服務恢復時自動恢復(閉合開關)的設施.
斷路器(Cricuit Breaker)是一種能夠在遠程服務不可用時自動熔斷(打開開關),併在遠程服務恢復時自動恢復(閉合開關)的設施,Spring Cloud通過Netflix組件
的Hystrix組件提供斷路器,資源隔離與自我修複功能.
Spring Cloud Zuul 服務網關
Spring Cloud Bus : 事件,消息匯流排,用於在集群(例如,配置變化事件)中傳播狀態變化,可與Spring Cloud Config聯合實現熱部署;
Spring Cloud for Cloud Foundry : 通過Oauth2協議幫到服務到CloudFoundry,CloudFoundry是VMware推出的開源PaaS平臺.
Spring Cloud Sleuth : 日誌收集工具包,馮總了Dapper,Zipkin和HTrace操作.
Spring Cloud Data Flow : 大數據操作工具,通過命令行方式操作數據流.
Spring Cloud Security : 安全工具包,為你的應用程式添加安全控制,主要是指OAuth2.
Spring Cloud Consul : 封裝了Consul操作,consul是一個服務發現與配置工具,與Docker容器可以無縫集成.
Spring Cloud Zookeeper : 操作Zookeeper的工具包,用於使用zookeeper方式的服務註冊和發現.
Spring Cloud Stream : 數據流操作開發包,封裝了與Redis,Rabbit,Kafka等發送接收消息.
Spring Cloud CLI : 基於SpringBoot CLI,可以讓你命令行方式快速建立雲組件.
Spring Cloud特點 :
1 : 約定優於配置;
2 : 開箱既用,快速啟動;
3 : 適用於各種環境
4 : 輕量級組件;
5 : 組件支持豐富,功能齊全.
6 : 選型中立.