1.微服務的誕生：

• 越來越多的使用者參與
• 業務場景越來越複雜
• 傳統的單體架構已經很難滿足網際網路技術的的發展要求
• 程式碼的可維護性，擴充套件性和可讀性在降低
• 維護系統的成本，修改系統的成本在提高。

微服務：是著名的OO（面向物件Object oriented）專家Martin fowler提出的。

傳統的單體應用：

表示層，業務邏輯層，資料訪問層都放在一個工程中，最終經過編譯，打包，部署在一臺伺服器上。

隨著業務的擴充套件，大多數公司會將應用進行叢集部署，並增加負載均衡伺服器。還需要增加叢集部署的快取伺服器和檔案伺服器，並將資料庫讀寫分離，以應對使用者量的增加而帶來的高併發訪問量。用負載均衡伺服器分發高併發的網路請求，使用者的訪問被分派到不同的應用伺服器，應用伺服器的負載均衡不再成為瓶頸，使用者量增加時，新增應用伺服器即可。通過新增快取伺服器來緩解資料庫的 資料以及資料庫讀取資料的壓力。

• 單體應用，大量的業務必然會有大量的程式碼，程式碼的可讀性和可維護性依然很差
• 面對海量的使用者，資料庫將會成為瓶頸，解決方案將使用分散式資料庫，也就是嫁給你資料庫進行分庫分表。
• 持續交付能力差，業務越複雜，程式碼越多，修改程式碼和新增程式碼所需的時間越長。

2.如何理解微服務：

• 按業務劃分為一個獨立執行的程式，即服務單元。
• 服務之間通過HTTP協議相互通訊。
• 自動化部署
• 可以用不同的變成語言。
• 服務集中化管理
• 微服務是一個分散式系統。

按業務劃分的微服務單元獨立部署，執行在獨立的程序中。這些微服務單元是高度元件化的模組，並提供了穩定的模組邊界，服務與服務之間沒有任何 耦合，有非常好的擴充套件性和複用性。

微服務通過HTTP來互相通訊：

按照業務劃分的微服務單元獨立部署，並執行在各自的程序中。微服務單元之間的通訊方式一般傾向HTTP通訊。更多的時候是使用restful api。這種接受請求，處理業務邏輯，返回資料的HTTP模式非常高效，並且這種通訊機制與平臺和語言無關。

服務與服務之間也可以通過輕量級的訊息匯流排來通訊。例如：rabbitMq ,kafaka等。通過傳送訊息或者訂閱訊息來達到服務與服務之間通訊的目的。

服務與服務通訊的資料格式，一般為JSON, XML 。這兩種資料格式與語言，平臺，通訊協議無關。一般來說，JSON格式比XML輕量，並且可讀性也比XML要好。另外一種就是用protobuf進行資料序列化，經過序列化的資料為二進位制資料，它比JSON更輕量。用protobuf序列化的資料為二進位制，可能性非常差，必須進行反序列化才能夠讀懂。由於protobuf序列化的資料更輕量，所以用protobuf 在通訊協議和資料儲存上十分受歡迎。

服務與服務之間通過HTTP或者訊息匯流排的方式進行通訊，這種方式存在弊端，其通訊機制是不可靠的，雖然成功率很高，但還是會失敗的。

3.微服務的資料庫獨立：

在單體架構中，所有 的業務都共用一個數據庫。業務量的增加，表的數量增加，資料量的增加會導致查詢速度越來越慢。

微服務的一個特點就是按照業務劃分服務，服務與服務之間無耦合，就是資料庫也是獨立的。一個典型的微服務架構就是每一個微服務都有自己獨立的資料庫，資料庫之間沒有任何聯絡。

好處：

• 隨著業務的不斷擴張，服務與服務不需要提供資料庫整合，而是提供API介面相互呼叫；
• 資料庫獨立，單業務的資料量少，易於維護，資料庫效能有著明顯的優勢，資料庫的遷移也很方便。

資料庫的儲存方式不僅僅侷限於關係型資料庫，非關係型資料庫的應用也非常廣泛，mongDB,redis它們有著良好的讀寫效能。

4.微服務的自動化部署：

微服務架構中，系統會被拆分成若干個微服務，每一個微服務又是一個獨立的應用程式。單體架構的應用程式只需要部署一次，而微服務架構有多少個服務就需要部署多少次。業務粒度劃分的越細，微服務的資料就越多，這時就需要更穩定的部署機制。Docker，jenkins 都是比較不錯的。

自動化部署可以提高部署的效率，減少人為的控制，部署過程中出現的錯誤的概率降低，部署過程的每一步自動化，提高軟體的質量。

5.服務集中化管理：

微服務系統是按業務單元劃分服務 的，服務數量越多，管理起來越 複雜，因此微服務必須使用集中化管理。目前流行的微服務框架中，例如spring cloud 採用eureka 來註冊服務和發現服務。另外，zookeeper，consul 等都是非常優秀的服務集中化管理框架。

6.分散式架構：

分散式系統是叢集部署 的，由很多計算機相互協作共同構成，它能夠處理海量的使用者請求。分散式系統通過網路協議來通訊，所以分散式系統在空間上沒有任何限制，即分散式伺服器可以部署不同的機房和不同的地區。

微服務架構是分散式架構，分散式系統比單體系統更加複雜，主要體現在服務的獨立性和服務相互呼叫的可靠性，以及分散式事務，全域性鎖，全域性ID等，而單體系統不需要考慮這些複雜性。

分散式系統的應用都是叢集化部署，會給資料一致性帶來困難。分散式系統中的服務通訊依賴於網路。網路不好，會對分散式系統帶來很大的影響。在分散式系統中，服務之間相互依賴，如果一個服務出現了故障或者網路延遲，在高併發的情況下，會導致執行緒阻塞，在很短的時間內該服務的執行緒資源會消耗殆盡，最終使得該服務不可用。這就是“雪崩效應”。為了防止雪崩，分散式可以採用“熔斷機制”。

7.熔斷機制：

為了防止雪崩效應，分散式系統採用“熔斷機制”。在用spring cloud 構建的微服務系統中，採用了熔斷器（hystrix元件的circuit breaker）去做熔斷。

當別的服務都依賴某一個服務時，當該服務發生故障時，請求失敗次數超過設定的閥值之後，該服務就會開啟熔斷機制，該服務不再進行任何的業務邏輯操作，執行快速失敗，直接返回請求失敗的資訊。熔斷器還有另外一個機制：自我修復的機制。這種自我修復機制在微服務架構中有著重要的意義，一方面，它使程式更加健壯，另一方面，為開發和運維減少很多不必要的工作。

熔斷元件往往會提供一系列的監控，例如服務可用於否，熔斷器是否被開啟，目前的吞吐量，網路延遲狀態的監控等。從而很容易的讓開發人員和運維人員實時的瞭解服務的狀態。

8.微服務的優勢：

• 將一個複雜的業務分解成若干個小的業務，每一個業務拆分成一個服務，服務的邊界明確，將複雜的問題簡單化。服務按照業務拆分，編碼也是按照業務拆分，程式碼的可讀性和可擴充套件性增加。
• 由於微服務系統是分散式系統，服務與服務之間沒有任何的耦合。隨著業務的增加可以根據業務再拆分成服務，具有極強的橫向擴充套件能力。隨著使用者量的增加，併發量增加，可以將微服務叢集化部署，從而增加系統的負載能力。
• 服務與服務之間通過HTTP網路通訊協議來通訊，單個微服務內部高度耦合，服務與服務直接完全獨立，無耦合。這使得為父可以採用任何的開發語言和技術來實現。
• 單體應用，由於業務的複雜性，程式碼的耦合性，以及可能存在的歷史問題。再重寫一個單體應用時，開發人員要熟悉所有的業務。重寫的風險相當高。微服務是按照業務進行拆分的，並且有服務邊界，所以重寫某個服務相當於重寫某個業務的程式碼，就非常簡單。
• 微服務的每個服務單元都是獨立部署的，即獨立執行在某個程序裡。微服務的修改和部署對其他服務沒有影響。
• 微服務在CAP理論中採用的是AP架構，即具有高可用和分割槽容錯的特點。高可用主要體現在系統7×24小時不間斷的服務，它要求系統有大量的伺服器叢集，從而提高了系統的負載能力。另外，分割槽容錯也使得更加健壯。

9.微服務的不足：

• 微服務的複雜度
• 分散式事務
• 服務的劃分
• 服務的部署

10.分散式事務：

微服務架構所涉及的系統是分散式系統。分散式系統有一個著名的CAP理論，即同時滿足“一致性”，“可用性”，“分割槽容錯”時意見不可能的事情。設計時應該有所取捨。

• Consistency:資料的強一致性。如果寫入某個資料成功，之後讀取，讀到的都是新寫入 的資料；如果寫入失敗，之後讀取的都不是寫入失敗的資料。
• Availability:服務的可用性。
• Partition-tolerance:指分割槽容錯。

在分散式系統中，P是基本要求，而單體服務是CA系統。微服務系統通常是一個AP系統，即同時滿足了可用性和分割槽容錯。

解決事務問題：

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

第二階段，事務管理器收集所有節點的準備操作是否成功，如果都成功，同通知所有的節點執行提交操作；如果有一個失敗，則執行回滾操作。

兩階段提交，將事務分成兩部分能夠大大提高分散式事務的成功的概率。如果在第一階段都成功了，而執行第二階段的某一個節點失敗，仍然導致資料的不準確，這時一般需要人工去處理，這就是當初在第一步記錄日誌的原因。