微服務設計（一）---微服務架構基礎

一、系統架構的演變 1、技術架構發展歷史時間軸 ①單機垂直拆分：應用間進行瞭解耦，系統容錯提高了，也解決了獨立應用發佈的問題，存在單機計算能力瓶頸。 ②集群化負載均衡可有效解決單機情況下併發量不足瓶頸。 ③服務改造架構雖然系統經過了垂直拆分，但是拆分之後發現有重覆的功能，比如，用戶註冊、發郵件等等 ...

一、系統架構的演變

1、技術架構發展歷史時間軸

　①單機垂直拆分：應用間進行瞭解耦，系統容錯提高了，也解決了獨立應用發佈的問題，存在單機計算能力瓶頸。

②集群化負載均衡可有效解決單機情況下併發量不足瓶頸。

　③服務改造架構

雖然系統經過了垂直拆分，但是拆分之後發現有重覆的功能，比如，用戶註冊、發郵件等等，一旦項目大了，集群部署多了，這些重覆的功能無疑會造成資源浪費，所以會把重覆功能抽取出來，名字叫"XX服務（Service）"。為瞭解決服務跟服務如何相互調用，需要一個程式之間的通信協議，所以就有了遠程過程調用（RPC），作用就是讓服務之間的程式調用變得像本地調用一樣的簡單。

優點：在垂直架構的基礎上解決了業務重用的問題。

　④服務治理

　　隨著業務的增大，基礎服務越來越多，調用網的關係由最初的幾個增加到幾十上百，造成了調用鏈路錯綜複雜，需要對服務進行治理。服務治理要求：當服務節點數幾十上百的時候，需要對服務有動態的感知，引入了註冊中心。當服務鏈路調用很長的時候如何實現鏈路的監控。單個服務的異常，如何能避免整條鏈路的異常（雪崩），需要考慮熔斷、降級、限流。服務高可用：負載均衡。典型框架比如有：Dubbo，預設採用的是Zookeeper作為註冊中心。

⑤微服務時代

　微服務是在2012年提出的概念，微服務的希望的重點是一個服務只負責一個獨立的功能。拆分原則，任何一個需求不會因為發佈或者維護而影響到不相關的服務，一切可以做到獨立部署運維。比如傳統的“用戶中心”服務，對於微服務來說，需要根據業務再次拆分，可能需要拆分成“買家服務”、“賣家服務”、“商家服務”等。典型代表：Spring Cloud，相對於傳統分散式架構，SpringCloud使用的是 HTTP作為RPC遠程調用，配合上註冊中心Eureka和API網關Zuul，可以做到細分內部服務的同時又可以對外暴露統一的介面，讓外部對系統內部架構無感，此外Spring Cloud的config組件還可以把配置統一管理。

Spring Cloud微服務架構存在的不足： Spring Cloud屬於侵入式框架，在項目中需要添加spring cloud maven 依賴，加上spring cloud組件註解，寫配置，打成jar的時候還必須要把非業務的代碼也要融合在一起。微服務中的服務支持不同語言開發，也需要維護不同語言和非業務代碼的成本；業務代碼開發者應該把更多的精力投入到業務熟悉度上，而不應該是非業務上，Spring Cloud雖然能解決微服務領域的很多問題，但是學習成本還是較大的。互聯網公司產品的版本升級是非常頻繁的，為了維護各個版本的相容性、許可權、流量等，因為Spring Cloud是“代碼侵入式的框架”，這時候版本的升級就註定要讓非業務代碼一起，一旦出現問題，再加上多語言之間的調用，工程師會非常痛苦。我們已經感覺到了，服務拆分的越細，只是感覺上輕量級解耦了，但是維護成本卻越高了。

⑥服務網格新時期（Service Mesh）

Service Mesh主要解決的問題就希望開發人員對於業務的聚焦，服務發現、服務註冊、負載均衡等對於開發人員透明，可以更加專註業務邏輯的實現。如果將為微服務提供通信服務的這部分邏輯從應用程式進程中抽取出來，作為一個單獨的進程進行部署，並將其作為服務間的通信代理，可以得到如下圖所示的架構：

當服務大量部署時，隨著服務部署的Sidecar代理之間的連接形成了一個如下圖所示的網格，該網格成為了微服務的通訊基礎設施層，承載了微服務之間的所有流量，被稱之為Service Mesh（服務網格）。

服務網格中有數量眾多的Sidecar代理，如果對每個代理分別進行設置，工作量將非常巨大。為了更方便地對服務網格中的代理進行統一集中控制，在服務網格上增加了控制面組件。

服務網格用來描述組成這些應用程式的微服務網路以及它們之間的交互。隨著服務網格的規模和複雜性不斷的增長，它將會變得越來越難以理解和管理。它的需求包括服務發現、負載均衡、故障恢復、度量和監控等。服務網格通常還有更複雜的運維需求，比如 A/B 測試、金絲雀發佈、速率限制、訪問控制和端到端認證。

Istio

2017年5月24日，Google, IBM 和 Lyft 共同發佈 Istio 的第一個公開版本(0.1)。Istio為一款開源的為微服務提供服務間連接、管理以及安全保障的平臺軟體，支持運行在Kubernetes、Mesos等容器管理工具，但不限於Kubernetes、Mesos，其底層依賴於Envoy。Istio提供一種簡單的方法實現服務間的負載均衡、服務間認證、監控等功能，而且無需應用層代碼調整。其控制平面由Pilot、Citadel 和 Galley組成，數據平面由Envoy實現，通常情況下，數據平面代理Envoy以sidecar模式部署，使得所有服務間的網路通信均由Envoy實現，而Istio的控制平面則負責服務間流量管理、安全通信策略等功能。

istio架構

實際上Istio 就是 Service Mesh 架構的一種實現，服務之間的通信（比如這裡的 Service A 訪問 Service B）會通過代理（預設是 Envoy）來進行。而且中間的網路協議支持 HTTP/1.1，HTTP/2，gRPC 或者 TCP，可以說覆蓋了主流的通信協議。代理這一層，稱之為數據平面。控制平面做了進一步的細分，分成了 Pilot、Citadel 和 Galley，它們的各自功能如下：Pilot：為 Envoy 提供了服務發現，流量管理和智能路由（AB 測試、金絲雀發佈等），以及錯誤處理（超時、重試、熔斷）功能。Citadel：為服務之間提供認證和證書管理，可以讓服務自動升級成 TLS協議。Galley：Galley 是 Istio 的配置驗證、提取、處理和分發組件。它負責將其餘的 Istio 組件與從底層平臺（例如 Kubernetes）獲取用戶配置的細節隔離開來。數據平面會和控制平面通信，一方面可以獲取需要的服務之間的信息，另一方面也可以彙報服務調用的 Metrics 數據。

為什麼使用 Istio？

通過負載均衡、服務間的身份驗證、監控等方法，Istio 可以輕鬆地創建一個已經部署了服務的網路，而服務的代碼只需很少更改甚至無需更改。通過在整個環境中部署一個特殊的 sidecar 代理為服務添加 Istio 的支持，而代理會攔截微服務之間的所有網路通信，然後使用其控制平面的功能來配置和管理Istio，這包括：為 HTTP、gRPC、WebSocket 和 TCP 流量自動負載均衡。通過豐富的路由規則、重試、故障轉移和故障註入對流量行為進行細粒度控制。可插拔的策略層和配置 API，支持訪問控制、速率限制和配額。集群內（包括集群的入口和出口）所有流量的自動化度量、日誌記錄和追蹤。在具有強大的基於身份驗證和授權的集群中實現安全的服務間通信。Istio 為可擴展性而設計，可以滿足不同的部署需求。

二、架構特點分析

1 單體應用架構（ALL IN ONE）

單體應用架構應用大部分都是一個WAR包或者JAR包，包含前端頁面，後端三層架構（web層，service層，dao層），即將所有的功能模塊打包到一起並放在一個web容器中（如tomcat）運行。

優點：所有功能集成在一個項目工程中，項目架構簡單，前期開發成本低，要快速增加新功能或部署發佈都比較簡單，小型項目的首選，項目初期是一種比較好的方案。

缺點：對於大型項目不易擴展。系統性能受限，系統性能擴展只能通過擴展集群節點的方式，成本高，技術棧受限，有瓶頸。

2 垂直應用架構

隨著用戶量越來越多，系統的壓力也隨之增長。當併發訪問量提高到一定程度，單一應用通過增加機器提高性能的方式瓶頸越來越明顯，在系統不能支撐當前的用戶量後，需要將項目按照不同的業務來做拆分，拆分為多個子系統，系統之間通過Webservice或者HTTP介面來進行交互，系統不再那麼臃腫了。當其中某一個模塊使用的頻率比較高，就對這個模塊進行擴展，即多部署幾個節點。再加一個Nginx用於負載均衡，剛開始還沒什麼大問題，當子系統越來越多的時候，每個子系統前面都要加一層負載，對運維人員來說工作量就增加了，因為要維護的也增多了。

優點：通過垂直拆分，可在一定程度上突破原來單體應用的併發訪問瓶頸，不同的子項目可採用不同的技術，技術棧相對豐富。

缺點：①隨著用戶量的增加及系統性能的提升，需要拆分的子項目越來越多，運維成本大幅度提升。

　　　②按照業務拆分的子系統，各個子系統之間存在重合的服務，如用戶註冊、郵件發送等，重覆的功能會造成資源浪費，需要進一步抽取公共功能作為獨立服務。

3 分散式SOA架構

3.1 SOA

　　SOA 全稱為 Service-Oriented Architecture，即面向服務的架構。它可以根據需求通過網路對鬆散耦合的粗粒度應用組件(服務)進行分散式部署、組合和使用。一個服務通常以獨立的形式存在於操作系統進程中。站在功能的角度，把業務邏輯抽象成可復用、可組裝的服務，通過服務的編排實現業務的快速再生，目的是把原先固有的業務功能轉變為通用的業務服務，實現業務邏輯的快速復用。即SOA 有如下幾個特點：分散式、可重用、擴展靈活、松耦合。

　　當垂直應用越來越多，應用之間交互不可避免，將核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心，使前端應用能更快速的響應多變的市場需求

優點：抽取公共的功能為服務,提高開發效率對不同的服務進行集群化部署解決系統壓力基於ESB/DUBBO減少系統耦合。

缺點：抽取服務的粒度較大服務提供方與調用方介面耦合度較高。

3.2 微服務架構

優點：通過服務的原子化拆分，以及微服務的獨立打包、部署和升級，小團隊的交付周期將縮短，運維成本也將大幅度下降微服務遵循單一原則。微服務之間採用Restful等輕量協議傳輸。

缺點：微服務過多，服務治理成本高，不利於系統維護。分散式系統開發的技術成本高（容錯、分散式事務等）。

3.3 SOA與微服務的關係

　　SOA（ Service Oriented Architecture ）“面向服務的架構”：是一種設計方法，其中包含多個服務，服務之間通過相互依賴最終提供一系列的功能。一個服務通常以獨立的形式存在與操作系統進程中。各個服務之間通過網路調用。

　　微服務架構：其實和 SOA 架構類似,微服務是在 SOA 上做的升華，微服務架構強調的一個重點是“業務需要徹底的組件化和服務化”，原有的單個業務系統會拆分為多個可以獨立開發、設計、運行的小應用。這些小應用之間通過服務完成交互和集成。

4 分散式核心知識

1）分散式中的遠程調用

在微服務架構中，通常存在多個服務之間的遠程調用的需求。遠程調用通常包含兩個部分：序列化和通信協議。常見的序列化協議包括json、xml、hession、protobuf、thrift、text、bytes等，目前主流的遠程調用技術有基於HTTP的RESTful介面以及基於TCP的RPC協議。

（1）RESTful介面 REST，即Representational State Transfer的縮寫，如果一個架構符合REST原則，就稱它為RESTful架構。

　　資源（Resources）

　　所謂"資源"，就是網路上的一個實體，或者說是網路上的一個具體信息。它可以是一段文本、一張圖片、一首歌曲、一種服務，總之就是一個具體的實在。你可以用一個URI（統一資源定位符）指向它，每種資源對應一個特定的URI。要獲取這個資源，訪問它的URI就可以，因此URI就成了每一個資源的地址或獨一無二的識別符。REST的名稱"表現層狀態轉化"中，省略了主語。

　　"表現層"其實指的是"資源"（Resources）的"表現層"。

　　表現層（Representation） "資源"是一種信息實體，它可以有多種外在表現形式。我們把"資源"具體呈現出來的形式，叫做它的"表現層"（Representation）。比如，文本可以用txt格式表現，也可以用HTML格式、XML格式、JSON格式表現，甚至可以採用二進位格式；圖片可以用JPG格式表現，也可以用PNG格式表現。URI只代表資源的實體，不代表它的形式。嚴格地說，有些網址最後的".html"尾碼名是不必要的，因為這個尾碼名錶示格式，屬於"表現層"範疇，而URI應該只代表"資源"的位置。

　　狀態轉化（State Transfer）訪問一個網站，就代表了客戶端和伺服器的一個互動過程。

　　在這個過程中，勢必涉及到數據和狀態的變化。互聯網通信協議HTTP協議，是一個無狀態協議。這意味著，所有的狀態都保存在伺服器端。因此，如果客戶端想要操作伺服器，必須通過某種手段，讓伺服器端發生"狀態轉化"（State Transfer）。客戶端用到的手段，只能是HTTP協議。具體來說，就是HTTP協議裡面，四個表示操作方式的動詞： GET、POST、PUT、DELETE。它們分別對應四種基本操作：GET用來獲取資源，POST用來新建資源（也可以用於更新資源），PUT用來更新資源，DELETE用來刪除資源。

　　綜合上面的解釋，我們總結一下什麼是RESTful架構：每一個URI代表一種資源；客戶端和伺服器之間，傳遞這種資源的某種表現層；客戶端通過四個HTTP動詞，對伺服器端資源進行操作，實現"表現層狀態轉化"。

（2）RPC協議

　　RPC（Remote Procedure Call ）一種進程間通信方式。允許像調用本地服務一樣調用遠程服務。RPC 框架的主要目標就是讓遠程服務調用更簡單、透明。RPC框架負責屏蔽底層的傳輸方式（TCP或者 UDP）、序列化方式（XML/JSON/二進位）和通信細節。開發人員在使用的時候只需要瞭解誰在什麼位置提供了什麼樣的遠程服務介面即可，並不需要關心底層通信細節和調用過程。

（3）區別與聯繫

1、HTTP相對更規範，更標準，更通用，無論哪種語言都支持http協議。如果你是對外開放API，例如開放平臺，外部的編程語言多種多樣，你無法拒絕對每種語言的支持，現在開源中間件，基本最先支持的幾個協議都包含RESTful。

2、 RPC 框架作為架構微服務化的基礎組件，它能大大降低架構微服務化的成本，提高調用方與服務提供方的研發效率，屏蔽跨進程調用函數（服務）的各類複雜細節。讓調用方感覺就像調用本地函數一樣調用遠端函數、讓服務提供方感覺就像實現一個本地函數一樣來實現服務。

2）分散式中的CAP原理

　　現如今，對於多數大型互聯網應用，分散式系統（distributed system）正變得越來越重要。分散式系統的最大難點，就是各個節點的狀態如何同步。CAP 定理是這方面的基本定理，也是理解分散式系統的起點。 CAP理論由 Eric Brewer 在ACM研討會上提出，而後CAP被奉為分散式領域的重要理論。分散式系統的 CAP理論，首先把分散式系統中的三個特性進行瞭如下歸納：

　　Consistency（一致性）：數據一致更新，所有數據的變化都是同步的。

　　Availability（可用性）：在集群中一部分節點故障後，集群整體是否還能響應客戶端的讀寫請求

　　Partition tolerance（分區容忍性）：某個節點的故障，並不影響整個系統的運行。

　　通過學習CAP理論，我們得知任何分散式系統只可同時滿足二點，沒法三者兼顧，既然一個分佈式系統無法同時滿足一致性、可用性、分區容錯性三個特點，所以我們就需要拋棄一樣：