作者：不洗碗工作室 - Marklux
版權歸作者所有，轉載請註明出處
前言
本文主要是針對以下幾個問題的筆記：
- 服務端的架構是如何一步步演變的？
- 什麼是分散式服務框架？它用於解決什麼問題？
- 什麼是微服務架構？主要應用於何種場景？
服務架構的演變
隨著網際網路的逐漸發展和壯大，服務端的架構也在不斷變得更龐大、更復雜。
大概的演變過程分為以下幾個階段：
-
單一應用架構
服務端解決所有問題，從資料儲存到MVC。應用規模較小的時候可以採用這種架構，絕大多數學生時代的課設或是小型web專案都是這種結構。
一臺伺服器，一個開發框架，一個資料庫便構成了一個完整的應用。
這一階段主要的效能瓶頸是ORM，因為整體應用通常是對資料庫CURD操作的一個封裝，所以效能最終取決於資料庫以及應用框架與資料庫之間的連線部分。
-
垂直應用架構
當應用規模增大時，單一服務支撐整個應用就顯得有些力不從心了，此時需要對服務進行拆解。
最常見的拆解是前後端分離，此時服務端專注於提供介面，可以將服務進一步拆解成幾個不相關的部分獨立垂直部署，而前端提供一個統一的入口。
這一階段的主要效能瓶頸是MVC，換句話說，頁面的組織和開發將會是整個專案中最耗時的一部分（在沒有複雜業務的前提下）。
-
分散式服務架構
當垂直應用越來越多時，就不可避免的產生交叉，此時的做法是將核心業務抽離出來，作為獨立的服務中心部署。
而一個應用依賴的服務數量可能已經是一個非常龐大的數字，必須要對所有這些服務進行必要的監控、調整以及整合。
這一階段主要的效能瓶頸便是分散式服務框架(RPC)。
-
流動計算架構
服務越來越多，容量的評估，小服務資源的浪費等問題便愈發嚴重，此時需增加一個排程中心基於訪問壓力實時管理叢集容量，提高叢集利用率。
這一階段的主要效能瓶頸是資源排程和治理中心(SOA)。
上面的演變流程可以參考下圖：
分散式服務框架的關注點
從個人理解的角度出發，針對大型應用程式設計的時候，設計的思路不再是面向伺服器的一條龍式程式設計，而是面向服務的程式設計，這是一個重要的思維模式的轉換。
開發人員的關注點也隨之發生變化，在分散式服務框架中，我們需要關注的問題有以下幾個：
-
服務之間如何通訊？
其實從分散式的架構中不難看出，服務之間的通訊其實是分散式框架的一個重點。要實現服務之間的通訊，現在業內主要使用以下幾種方案：
- （同步）高效能RPC，比如dubbo本身其實就是一個RPC框架，重點在於實現對於外部服務過程的透明呼叫
- （同步）RESTful API，比起RPC可能效能略低，但是規範、可複用性強
- （非同步）使用訊息佇列
值得注意的是，因為服務之間的通訊變多，通訊的管理工作也會成為一個重點。
-
客戶端如何訪問到服務？
當服務被拆分，部署到叢集，客戶端便再也無法通過固定的地址來訪問到服務。此外，服務真正部署的節點還會隨時發生變動：刪除、增加或是故障，都需要客戶端能夠實時感知，為了實現這個效果，需要提供下面兩個實現：
- API Gateway: 外界Client訪問的一個統一入口，內部通過負載均衡等手段將客戶端定向到真正的服務提供節點。
- 服務發現: 當新的服務接入、舊的服務刪除，或者是已有的服務擴充套件叢集時，業務都需要感知這些變動，這時候需要一個集中的節點註冊/管理機制，比如
ZooKeeper或者etcd。
-
服務出現故障時怎麼辦？
由於整個應用變成了分散式的服務，那麼任何一個服務出現故障，都可能導致整個應用崩潰，同時由於服務數量的增加，錯誤的定位也更加困難，因此需要一個良好的監控機制。
用於保證服務可用性的解決手段（我瞭解的） 主要如下：
- 應用健康檢查機制：通過心跳包等手段監控服務大盤的穩定性，做到故障的快速定位
- 熔斷、限流、降級：當部分服務出現故障時，為了將損失最小化的一套應對流程，具體的實現可以參考
Hytrix
-
資料如何共享？
這也是分散式系統一個非常頭疼的問題，由於服務的分散和資料量的增加，整個應用的資料將會被分散到很多不同的儲存節點上，這導致資料的同步變得很艱難。
主要體現為以下兩點：
-
服務分散了，但是某些資料是集中共用的，比如使用者的賬號資訊，這時候需要一個集中的資料中心來管理，這方面可以參考SSO和OAuth的使用。
-
資料量太大，需要進行分庫、分表，這時候如果有事務需要同時對物理隔離的資料進行操作，就需要考慮資料一致性如何保證。
根據著名的
CAP定律，在分散式系統中無法同時保證高可用性和強一致性。因此大多數場景下會妥協強一致性，而採用最終一致性，這部分的討論可以移步此處瞭解更多。 -
總結
我們把分散式架構下的需要解決的問題梳理整理一下，就可以明白一個分散式服務框架需要提供哪些功能：
- API Gateway（服務入口）
- 服務間呼叫（RPC,RESTful）
- 服務發現（Zookeeper）
- 服務容錯（Hytrix）
- 服務部署和治理（Docker,服務網格）
- 資料呼叫（資料中心、最終一致性）
用下面這個圖可以更直觀的瞭解整體的結構（原圖是描述微服務的，但對分散式服務同樣有效）
當然要寫好一套分散式的服務，不只是使用一個分散式框架就可以解決的，還需要對服務進行合理的拆分，編寫出適合分散式結構的程式碼，以及後期的治理、維護。
另外微服務、分散式服務等概念帶來的意義在於給服務端開發者帶來對技術架構的一個全新意識，而不是抽象的概念、定式的模板。具體落地使用什麼樣的解決方案，還是要針對業務場景來進行調整的。