微服務基礎概念

1.什麼是微服務？

微服務是用於構建應用程序的架構風格，一個大的系統可由一個或者多個微服務組成，微服務架構可將應用拆分紅多個核心功能，每一個功能都被稱爲一項服務，能夠單獨構建和部署，這意味着各項服務在工做和出現故障的時候不會相互影響。

2. 大型電商平臺的微服務功能圖

 

總結：  微服務架構是把一個大的系統按照不一樣的業務單元分解成多個職責單一的小系統，並利用簡單的方法使多個小系統相互協做，組合成一個大系統，各個小的系統是獨立部署的，它們之間是鬆耦合的。

3.爲何要用微服務？

1、單體架構擴展性差、維護成本高、不可靠

 互動：什麼是單體架構？

 

在單體架構下修改代碼，須要把整個代碼從新編譯，從新部署，這個時間週期會很長；

單體架構下的全部代碼模塊都耦合在一塊兒，代碼量大，維護困難，想要更新一個模塊的代碼，也可能會影響其餘模塊，不能很好的定製化代碼。

全部模塊都用同一個數據庫，存儲方式比較單一。

二、微服務中能夠有java編寫、有Python編寫的，他們都是靠restful架構風格統一成一個系統的，因此微服務自己與具體技術無關、擴展性強

4.微服務特性

1）靈活部署、獨立擴展

傳統的單體架構是以整個系統爲單位進行部署，而微服務則是以每個獨立組件（例如訂單服務，商品服務）爲單位進行部署。

 

2）資源的有效隔離

每個微服務擁有獨立的數據源，假如微服務A想要讀寫微服務B的數據庫，只能調用微服務B對外暴露的接口來完成。這樣有效避免了服務之間爭用數據庫和緩存資源所帶來的問題。另外微服務各模塊部署在k8s中，能夠進行CPU、內存等資源的限制和隔離。

 

 

3）高度可擴展性

隨着某些服務模塊的不斷擴展，能夠跨多個服務器和基礎架構進行部署，充分知足業務需求。

 

4）易於部署

相對於傳統的單體式應用，基於微服務的應用更加模塊化且小巧，且易於部署。

 

5）服務組件化

在微服務架構中，須要咱們對服務進行組件化分解，服務是一種進程外的組件，它經過HTTP等通訊協議進行協做，而不是像傳統組件那樣鑲入式的方式協同工做，每個服務都獨立開發、部署、能夠有效避免一個服務的修改引發整個系統的從新部署。

6）去中心化治理

在整個微服務架構，經過採用輕量級的契約定義接口，使得咱們對服務自己的具體技術平臺再也不那麼敏感，這樣整個微服務架構系統中的各個組件就能針對不一樣的業務特色選擇不一樣的技術平臺。

 

7）容錯設計

在微服務架構中，快速檢測出故障源並儘量地自動恢復服務是必須被設計考慮的，一般咱們都但願在每一個服務中實現監控和日誌記錄。好比對服務狀態、斷路器狀態、吞吐量、網絡延遲等關鍵數據進行可視化展現。

 

8）技術棧不受限

在微服務架構中，能夠結合項目業務及團隊的特色，合理地選擇技術棧。

 

9）局部修改容易部署

單體應用只要有修改，就得從新部署整個應用，微服務解決了這樣的問題。

 

10）易於開發和維護

一個微服務只會關注一個特定的業務功能，因此它業務清晰，代碼量較少。

 

5.什麼樣的項目適合使用微服務？

在複雜度比較低的項目中，單體架構就能夠知足需求，並且部署效率也會比較高，在複雜度比較高的項目中，單體架構就不能知足了，須要進行微服務化。

微服務能夠按照業務功能自己的獨立性來劃分，若是系統提供的業務是很是底層的，如：操做系統內核、存儲系統、網絡系統、數據庫系統等，這類系統都偏底層，功能和功能之間有着緊密的配合關係，若是強制拆分爲較小的服務單元，會讓集成工做量急劇上升，而且這種人爲的切割沒法帶來業務上的真正的隔離，因此沒法作到獨立部署和運行，也就不適合作成微服務了。

那到底什麼樣的項目適合微服務呢？

1. 業務併發量大，項目複雜，訪問流量高，爲了未來更好的擴展，隨時對代碼更新維護，可使用微服務

2. 代碼依賴程度高，想要解耦合，交給多個開發團隊維護

3. 業務初期，服務器數量少，可使用微服務，能有效節省資源。

4. 從思想上： 對將來有清晰的認識，對技術更新要保持着一種自信，超前思惟，知道這個東西在未來確定會發展起來。

這就告訴了咱們一個道理，在學習技術的時候，適合本身的纔是最好的，比方說不少人說咱們公司單體架構用的也挺好的啊，爲何還要用微服務，其實他們再用單體可能適合他們業務需求，可是咱們公司可能業務規模大，項目複雜，我就想要用微服務，或者咱們在將來上有更大的遠見，那我也會選擇用微服務，不要說看別人用，我也用，而是我用是符合咱們實際需求的，一切脫離實際業務的微服務都是耍流氓。

6. 使用微服務須要考慮的問題

6.1統一的配置管理中心

服務拆分之後，服務的數量很是多，若是全部的配置都以配置文件的方式放在應用本地的話，很是難以管理，能夠想象當有幾百上千個進程中有一個配置出現了問題，是很難將它找出來的，於是須要有統一的配置中心，來管理全部的配置，進行統一的配置下發。

在微服務中，配置每每分爲幾類，一類是幾乎不變的配置，這種配置能夠直接打在容器鏡像裏面，第二類是啓動時就會肯定的配置，這種配置每每經過環境變量，在容器啓動的時候傳進去，第三類就是統一的配置，須要經過配置中心進行下發，例如在大促的狀況下，有些功能須要降級，哪些功能能夠降級，哪些功能不能降級，均可以在配置文件中統一配置。

6.2 全鏈路監控

1）系統和應用的監控

 

監控系統和服務的健康狀態和性能瓶頸，當系統出現異常的時候，監控系統能夠配合告警系統，及時地發現，通知，干預，從而保障系統的順利運行。

 

2）調用關係的監控

對代碼調用關係進行監控

 

6.3 日誌收集

業務層面、代碼層面、系統層面

7. 常見的微服務框架

第一代微服務框架

SpringCloud

SpringCloud爲開發者提供了快速構建分佈式系統的通用模型的工具（包括配置管理、服務發現註冊、熔斷器、斷路器、智能路由、微代理、控制總線、一次性令牌、全局鎖、領導選舉、分佈式會話、集羣狀態、負載均衡、數據監控等）

 

第二代微服務框架

dubbo

dubbo是一個阿里巴巴開源出來的一個分佈式服務框架，致力於提供高性能和透明化的RPC遠程服務調用方案，以及SOA服務治理方案

 

第三代微服務框架

1.ServiceMesh（服務網格）、k8s

istio是開源的ServiceMesh（服務網格），ServiceMesh翻譯成中文就是服務網格

 

8. 對不一樣的微服務框架進行對比分析

8.1 框架背景對比

8.1.1 SpringCloud

來源於SpringSource ，具備Spring社區的強大背景支持，還有 Netflix強大的後盾與技術輸出。Netflix做爲一家成功實踐微服務架構的互聯網公司，在幾年前就把幾乎整個微服務框架開源貢獻給了社區，這些框架開源的整套微服務架構套件是SpringCloud的核心。

 

Eureka: 服務註冊發現框架；

Zuul: 服務網關；

Karyon: 服務端框架；

Ribbon: 客戶端框架；

Hystrix: 服務容錯組件；

Archaius: 服務配置組件；

Servo: Metrics組件；

Blitz4j: 日誌組件。

Pinpoint：全鏈路監控組件

8.1.2 Dubbo

是一個分佈式服務框架，是國內互聯網公司開源作的比較不錯的阿里開放的微服務化治理框架，致力於提供高性能和透明化的RPC遠程服務調用方案，以及SOA服務治理方案。 其核心部分包含（官網）:

遠程通信: 提供對多種基於長鏈接的NIO框架抽象封裝，包括多種線程模型，序列化，以及「請求-響應」模式的信息交換方式；  

集羣容錯: 提供基於接口方法的透明遠程過程調用，包括多協議支持，以及軟負載均衡，失敗容錯，地址路由，動態配置等集羣支持；

自動發現: 基於註冊中心目錄服務，使服務消費方能動態的查找服務提供方，使地址透明，使服務提供方能夠平滑增長或減小機器。

 

Dubbo也是採用全Spring配置方式，透明化接入應用，對應用沒有任何API侵入，只需用 Spring加載Dubbo的配置便可，Dubbo 基於Spring的Schema擴展進行加載。固然也支持官方不推薦的 API 調用方式。

 

8.1.3 k8s、 Istio

做爲用於微服務服務聚合層管理的新銳項目，是 Google、IBM、Lyft（海外共享出行公司、Uber勁敵） 首個共同聯合開源的項目，提供了統一的鏈接，安全，管理和監控微服務的方案。

目前是針對 Kubernetes 環境的，社區宣稱在將來幾個月內會爲虛擬機和 Cloud Foundry 等其餘環境增長支持。 Istio 將流量管理添加到微服務中，併爲增值功能（如安全性，監控，路由，鏈接管理和策略）創造了基礎。

HTTP、gRPC 和 TCP 網絡流量的自動負載均衡；  

提供了豐富的路由規則，實現細粒度的網絡流量行爲控制；

流量加密、服務間認證，以及強身份聲明；

全範圍（Fleet-wide）的策略執行；

深度遙測和報告。

 

8.2 開源社區活躍度對比

開源社區狀況：現現在企業在採用雲計算首選開源，而選擇一個開源框架，社區的活躍度將做爲重要參考選項。

查看下在Github上的更新時間

SpringCloud ：Spring Cloud · GitHub → 全部項目均更新於『1 小時』內。

Dubbo ：Dubbo · GitHub → 核心項目最近更新於『一個月乃至數月』前。

istio：istio · GitHub → 全部項目均更新於『30 分鐘』內。

可見，項目在社區活躍度上，Istio > SpringCloud > Dubbo，結合穩定性來看，對於使用 Java 開發業務較多的企業，SpringCloud是相對更優的選擇，對於更多企業來講，與語言幾乎無綁定的Istio也是能夠好好期待一下其在社區的發展。

總結：結合項目背景、提供功能、社區更新活躍度，SpringCloud是目前階段發展最先的微服務框架方案，Istio 做爲Kubernetes 的優先支持來說，也是一個值得關注的方案，並且發展潛力巨大，相信不久的未來90%+的k8s用戶都會使用istio。目前對比來看，dubbo則顯得稍遜下來。