微服務簡介

第一章、微服務簡介

名詞解釋：

1）表示層：用於直接和用戶交互，也稱交互層，一般指網頁、UI等。

2）業務邏輯層：用戶輸入的信息通過業務邏輯層的處理展示給用戶，即後端代碼的實現部分。

3）數據訪問層：用於操做數據庫，對數據庫進行讀寫操做。

4）單體框架：在一臺服務器部署全部資源，包括應用程序、數據庫、文件資源。（適用於小型應用的初期階段，訪問量較小）

5）熔斷機制：高併發狀況下線程阻塞，線程資源消耗殆盡，致使服務不可用。因爲服務的相互依賴，致使整個系統不可用，爲防止相似事情產生，使用熔斷機制。設置閥值、自我修復機制。

6）CAP理論：C（Consistency 數據一致性）A（Availability 服務可用性）P（Partition-tolerance 分區容錯）不可能設計出知足三點的系統，已被證明。單體框架：CA系統，微服務：AP系統；

7）分佈式事務：分階段實現：第一階段：將事務交給事務處理器TC，TC向全部參與事務的節點發送事務操做的準備，全部參與操做的節點進行執行，將Undo和Redo信息寫進日誌；第二階段：收集全部操做的結果，若都成功就提交，不然回滾。若出現異常致使整個事務阻塞，下降數據庫性能。

一、產生緣由

​ 隨着愈來愈多的用戶參與，業務場景愈來愈複雜，傳統的單體架構很難知足互聯網技術的發展，主要體如今兩方面：1）隨着業務複雜度的提升，代碼的可維護性、拓展性和可讀性下降；2）維護系統的成本、修改系統的成本在提升。

二、微服務簡介

​ 將單一程序開發成一個微服務，這些服務可使用不一樣的編程語言以及數據存儲技術，每個微服務運行在本身的進程中，使用輕量級機制通訊，並經過徹底自動化部署機制來獨立部署。

1）按業務劃分紅獨立運行的程序，即服務單元（高度組件化的模塊，服務之間沒有任何耦合，有良好的擴展性和複用性，單個微服務內部高度耦合）；

2）程序之間經過HTTP協議相互通訊（數據格式：JSON、XML、Protobuf；Protobuf比JSON更輕量，JSON比XML更輕量，Protobuf序列化的數據爲二進制，可讀性差）；

3）自動化部署（Docker容器，Jenkins自動化部署工具）；

4）可使用不一樣的編程語言和存儲技術（C、C++、Java；關係型數據庫MySQL，非關係型數據庫MonGDB、Redis）；

5）服務集中化管理（Eureka註冊與發現服務；Zookeeper、Consul等服務集中管理管理框架）；

6）微服務是一個分佈式系統（集羣部署的，不少計算機相互協做共同構成）。

三、微服務的優點

1）將複雜的問題簡單化，實現小的業務，易於維護和更改；

2）極強的橫向擴展能力：隨着業務增長用戶量增多能夠繼續細化；

3）微服務的單元是獨立部署的，修改單個的功能對其餘服務沒有影響；

4）分佈式提升了系統的負載能力。

四、微服務的不足

1）服務的劃分：微服務具體要劃分紅多小的服務單元難以具體定義；

2）服務的部署：對每一個微服務進行治理、監控和管理，在配置過程當中考慮啓動順序和啓動時機；

3）分佈式事務：基於CAP理論，對數據一致性的處理，多采用兩階段/三階段處理；

4）微服務的複雜度：構建、通訊機制、測試；

五、微服務和SOA的關係

SOA是面向服務的框架，微服務是將服務組件化；

微服務是SOA的一種實現，比ESB（企業服務總線）實現的SOA更加輕便、敏捷和簡單。

六、微服務的設計原則

軟件設計應該漸進式發展，不該該一開始就設計成微服務框架，小的系統能夠先設計成LAMP單體構架，在企業發展的過程當中能夠轉換成微服務的框架。

增長效率的方法：數據庫讀寫分離、加緩存、加負載均衡等。

讀了方誌鵬老師的《深刻理解Spring Cloud與微服務構建》一書有感，這裏只是簡單的作了下總結以供本身後續學習。對於本記錄若發現錯誤還請指出，如有疑問，也歡迎前來交流，qq:1164266197 Docen。