微服務基礎知識

1 系統架構的演變

1.1 概述

• 隨着互聯網的發展，網站應用的規模不斷擴大，常規的應用架構已無法應對，分布式服務架構以及微服務架構勢在必行，亟需一個治理系統確保架構有條不紊的演進。

1.2 單體應用架構

• web應用程序發展的早期，大部分web工程（包含前端頁面，web層代碼，service層代碼，dao層代碼）是將所有的功能模塊，打包到一起並放在一個web容器中運行。

• 比如搭建一個電商系統：客戶下訂單，商品展示，用戶管理。這種將所有功能度部署在一個web容器中運行的系統就叫做單體架構，目前也有人稱為單體地獄。
• 優點：
  • 1️⃣所有的功能集成在一個項目工程中。
  • 2️⃣項目架構簡單，前期開發成本低，周期短，小型項目的首選。
• 缺點：
  • 1️⃣全部功能集成在一個工程中，對於大型項目不易開發、擴展和維護。
  • 2️⃣系統性能只能通過擴展集群結點，成本高，有瓶頸。
  • 3️⃣技術棧受限。
  • 4️⃣代碼耦合度很高。
  • 5️⃣容錯性差，比如用戶管理出問題了，整個系統全部出問題，牽一發而動全身。

1.3 垂直應用架構

• 當訪問量逐漸增大，單一應用增加機器帶來的加速度越來越小，將應用拆成互補相干的幾個應用，以提高效率。

• 優點：
  • 1️⃣項目架構簡單，前期開發成本低，周期daunt，小型項目的首選。
  • 2️⃣通過垂直拆分，原來的單體項目不至於無線擴大。
  • 3️⃣不同的項目可采用不同的技術。
  • 4️⃣針對不同的子工程優化。
  • 5️⃣解決高並發問題。
  • 6️⃣方便水平擴展，容錯性好（相對於單體架構來說的，比如上圖中的商品管理出問題了，對CMS系統和后台管理系統來說沒影響）。
• 缺點：
  • 1️⃣全部功能集成在一個工程中，對於大型項目不易開發、擴展和維護。
  • 2️⃣系統性能擴展只能通過擴展集群結點，成本高，有瓶頸。
  • 3️⃣系統間相互獨立，會產生session共享問題（可以使用Redis Cluster、SpringSession等技術解決）。
  • 4️⃣重復的開發工作（比如上圖中的用戶管理功能在電商系統和后台管理系統中都有）。

1.4 分布式SOA架構

1.4.1 什么是SOA？

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

1.4.2 SOA架構

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

• 優點：
  • 1️⃣抽取公共的功能為服務，提高開發效率。
  • 2️⃣對不同的服務進行集群化部署解決系統壓力。
  • 3️⃣基於ESB或Dubbo減少系統耦合。
• 缺點：
  • 1️⃣抽取服務的粒度較大。
  • 2️⃣服務提供方和調用方接口耦合度較高。

1.5 微服務架構

• 優點：
  • 1️⃣通過服務的原子化拆分，以及微服務的獨立打包、部署和升級，小團隊的交付周期將會縮短，運維成本也將大幅度下降。
  • 2️⃣微服務遵循單一原則。微服務之間采用RESTful等輕量級協議傳輸。
• 缺點：
  • 1️⃣微服務過多，服務治理成本高，不利於系統維護。
  • 2️⃣分布式系統開發的技術成本高（容錯、分布式事務等）。

1.6 SOA和微服務的關系

• SOA：面向服務的架構，是一種設計方法，其中包含多個服務，服務和服務之間通過相互依賴最終提供一系列的功能。一個服務通常以獨立的形式存在於操作系統的進程之中。各個服務之間通過網絡調用。
• 微服務架構：其實和SOA架構類似，微服務是SOA架構上的升華，微服務架構強調的一個重點是"業務需要徹底的組件化和服務化"，原有的單個業務系統會拆分為多個可以獨立開發、設計、運行的小應用。這些小應用之間通過服務完成交互和集成。

功能	SOA	微服務
組件大小	大塊業務邏輯	單獨任務或小塊業務邏輯
耦合	通常松耦合	總是松耦合
公司架構	任何類型	小型，專注於功能交叉團隊
管理	着重中央管理	着重分散管理
目標	確保應用能夠交互操作	執行新功能、快速拓展開發團隊

2 分布式核心知識

2.1 分布式的遠程調用

• RESTful。
• RPC。

2.2 分布式中的CAP原理

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

• C（Consistency，一致性）：數據一致更新，所有數據的變化都是同步的。
• A（Availability，可用性）：在集群中一部分節點故障后，集群整體是否還能有影響客戶端的讀寫請求。
• P（Partition tolerance，分區容錯性）：某個節點的故障，並不影響整個系統的運行。

一個分布式系統里面，節點組成的網絡本來應該是連通的。然而可能因為一些故障，使得有些節點之間不連通了，整個網絡就分成了幾塊區域。數據就散布在了這些不連通的區域中。這就叫分區。

當你一個數據項只在一個節點中保存，那么分區出現后，和這個節點不連通的部分就訪問不到這個數據了。這時分區就是無法容忍的。

提高分區容忍性的辦法就是一個數據項復制到多個節點上，那么出現分區之后，這一數據項就可能分布到各個區里。容忍性就提高了。

然而，要把數據復制到多個節點，就會帶來一致性的問題，就是多個節點上面的數據可能是不一致的。要保證一致，每次寫操作就都要等待全部節點寫成功，而這等待又會帶來可用性的問題。

總的來說就是，數據存在的節點越多，分區容忍性越高，但要復制更新的數據就越多，一致性就越難保證。為了保證一致性，更新所有節點數據所需要的時間就越長，可用性就會降低。

作者：鄔江
鏈接：https://www.zhihu.com/question/54105974/answer/139037688
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。

選擇	說明
CA	放棄分區容錯性，加強一致性和可用性，其實就是傳統的關系型數據庫的選擇
AP	放棄一致性（強一致性），追求分區容錯性和可用性，這時很多分布式系統設計時的選擇，比如很多NoSQL數據庫就是如此
CP	放棄可用性，追求一致性和分區容錯性，基本不會選擇，網絡問題會直接讓整個系統不可用，比如zookeeper就是CP

• 需要明確一點的是，在一個分布式系統當中，分區容錯性和可用性是最基本的需求，所以在分布式系統中，我們的系統最應該關注的是AP，通過補償機制尋求數據的一致性。

3 常見微服務框架

3.1 SpringCloud

• SpringCloud是一系列框架的有序集合。它利用SpringBoot的開發便利性巧妙的簡化了分布式系統基礎設施的開發，如服務發現注冊、配置中心、消息中線、負載均衡、熔斷器、數據監控等，都可以用SpringBoot的開發風格做到一鍵啟動和部署。SpringCloud並沒有重復制造輪子，它只是將目前各家公司開發的比較成熟、經得起實際考研的服務框架組合起來，通過SpringBoot風格進行再封裝屏蔽掉了復雜的配置和實現原理，最終給開發者留出了一套簡單易懂、易部署和易維護的分布式系統開發工具包。

3.2 Apache的ServiceComb

• Apache ServiceCombo是業界第一個Apache微服務頂級項目，是一個開源微服務解決方案，致力於幫助企業、用戶和開發者將企業應用輕松微服務化上雲，並實現對微服務應用的高效運維管理。其提供一站式開源微服務解決方案，融合SDK框架級、零入侵ServerMesh場景並支持多種語言。

3.3 ZeroC ICE

• Zeroc ICE是Zeroc公司的傑作，繼承了CORBA的血統，是新一代的面向對象的分布式系統中間件。作為一種微服務架構，它基於RPC框架發展而來，具有良好的性能和分布式能力。