學習、跳槽漲薪？請關注

隨著業務的不斷發展, 用戶體量的快速擴張. 從單體/垂直架構轉移到分布式/微服務架構是自然而然的選擇.

01 分布式理論

分布式理論是分布式系統的基礎, 在任何情況下分布式系統都要滿足網絡分區容錯性, 因此分布式系統都是在可用性和一致性方面做平衡.

02 CAP理論

CAP理論指的是在一個分布式系統中,一致性、 可用性、分區容錯性、在任何情況下只能滿足其中兩個,三個不能同時滿足.

三個特性含義如下:

• Consistency(一致性) 指數據在多個副本之間能夠保持一致的特性(嚴格的一致性)。
• Availability(可用性) 指系統提供的服務必須一直處于可用的狀態，每次請求都能獲取到非錯的響應(不保證獲取的數據為最新數據)。
• Partition tolerance(分區容錯性) 分布式系統在遇到任何網絡分區故障的時候，仍然能夠對外提供滿足一致性和可用性的服務，除非整個網絡環- 境都發生了故障。

CAP原理告訴我們，C,A,P三個方面同時只能滿足兩個，不可能同時滿足。然而對于分布式系統而言，分區容錯性[P]是基本要求,系統根據自身方面的要求需要對可用性和一致性做取舍.

對于網站服務來說, 可用性可能價值更高, 所以一般網站都會選擇作為可用性放棄一致性. 而對于數據庫系統, 數據一致性是重中之重, 所以數據庫系統追求的是一致性放棄的是可用性.

03 BASE理論

BASE的核心思想是：

既然無法做到強一致性，然而每個應用都可以根據自身的業務特點，采用適當的方式來使系統達到最終一致性。

BASE理論的三個要點為:

• 基本可用(Basically Available)當系統出現故障時,損失部分功能的前提下保障系統基本功能的可用性，相比較正常的系統而言, 可能是響應時間的增大, 亦或者是功能的降級, 如電商系統大促秒殺期間為保障系統穩定導致部分服務接口降級.
• 軟狀態(Soft State)軟狀態指的是：允許系統中的數據存在中間狀態，并認為該狀態不影響系統的整體可用性，即允許系統在多個不同節點的數據副本存在數據延時。相對于原的性的強一致硬狀態而言，我們稱之為軟狀態。
• 最終一致性(Eventually Consistent)軟狀態不可能一直是軟狀態，必須有個時間期限。在期限過后，應當保證所有副本保持數據一致性，從而達到數據的最終一致性。這個時間期限取決于網絡延時、系統負載、數據復制方案設計等等因素。

04 微服務的優勢

• 降低復雜度將原來偶合在一起的復雜業務拆分為單個服務，規避了原本復雜度無止境的積累。每一個微服務專注于單一功能，并通過定義良好的接口清晰表述服務邊界。每個服務開發者只專注服務本身，通過使用緩存、DAL等各種技術手段來提升系統的性能，而對于消費方來說完全透明。
• 可獨立部署由于微服務具備獨立的運行進程，所以每個微服務可以獨立部署。當業務迭代時只需要發布相關服務的迭代即可，降低了測試的工作量同時也降低了服務發布的風險。
• 容錯在微服務架構下，當某一組件發生故障時，故障會被隔離在單個服務中。通過限流、熔斷等方式降低錯誤導致的危害，保障核心業務正常運行。
• 擴展單塊架構應用也可以實現橫向擴展，就是將整個應用完整的復制到不同的節點。當應用的不同組件在擴展需求上存在差異時，微服務架構便體現出其靈活性，因為每個服務可以根據實際需求獨立進行擴展。

05 微服務的設計要點

• 服務的拆分和粒度服務通用的拆分原則是按業務線的垂直拆分和功能上的水平劃分. 至于服務拆分到的粒度則是仁者見仁智者見智, 粒度粗細取決的方面有很多,如業務團隊、部署運維、訪問流量及硬件資源的限制等.
• 服務接口去狀態化根據cap理論, 只要涉及狀態涉及到數據一致性問題, 在分布式環境下保證一致性就要以犧牲可用性為前提.因此狀態是影響服務水平擴展的根本原因, 一個無狀態的服務理論上可以隨意的遷移和擴展. 然而應用的狀態是不可避免的,比如用戶訂單、登錄狀態等等.我們的原則是將整個業務分成兩部分, 無狀態的服務和有狀態的存儲. 服務接口作為計算單元處理用戶的請求,根據用戶的訪問量按需水平擴展,而狀態部分則交給專門的數據存儲集群來處理,如Redis,數據庫等. 內存中不應該保存狀態信息.
• 重試及冪等性分布式的復雜性在于引入了網絡的復雜性, 網絡操作存在未知情況. 比如系統之間相互調用時網絡超時、丟包、網絡分區等等，導致未成功處理或者處理成功未成功接收到響應等情況. 此時常用的手段是重試機制. 重試要求操作具有冪等性.
• 數據庫擴展及分布式事務數據庫是常用保存狀態的地方,也是最容易出現瓶頸的地方. 根據cap理論, 傳統數據庫由于數據庫一致性要求很難進行水平擴展. 然而有了分布式數據庫可以使數據庫的性能可以隨著節點增加線性地增加。在微服務領域分布式事務是一個繞不開的話題, 在單體架構時期, 數據庫本地事務保證了數據的一致性. 在微服務架構中, 由于服務功能的拆分,原本的事務操作可能要跨多個服務, 此時為了保證數據的一致性引入了分布式事務.分布式事務的處理方式分兩種:強一致性和最終一致性(BASE).
• 數據緩存在高并發場景下緩存是非常重要的。有層次的使用緩存能有效減輕系統的壓力. 要有層次的使用多級緩存, 緩存數據盡量靠近用戶. 比如在web端有一層靜態數據緩存、通過cdn，將靜態數據放到距離客戶較近的地方下載，數據庫之上增加redis緩存,動態數據的靜態化等等.
• 服務注冊發現微服務架構服務之間有較強的依賴, 服務之間相互調用必須是動態靈活的. 當服務前移或增加實例時系統能夠動態發現.
  常用的發現機制有: 基于注冊中心的注冊發現機制和基于dns的動態解析機制.
• 統一配置中心一類是幾乎不變的配置，這種配置可以直接打在容器鏡像里面
  第二類是啟動時就會確定的配置，這種配置往往通過環境變量，在容器啟動的時候傳進去
  第三類就是統一的配置，需要通過配置中心進行下發
• 熔斷，限流，降級服務要有熔斷，限流，降級的能力，當一個服務調用另一個服務，出現超時的時候，應及時返回，而非阻塞在那個地方，從而影響其他用戶的交易，可以返回默認的托底數據。
• 全方位的監控當系統非常復雜的時候，要有統一的監控，主要有兩個方面，一個是是否健康，一個是性能瓶頸在哪里。

06 微服務框架

當前開源的微服務框架有Dubbo, Spring Cloud, Dubbox, Thrift, GRPC等;以Dubbo和Spring Cloud使用最廣,以下對兩個框架進行比較。

• DubboDubbo采用Zookeeper作為注冊中心，RPC作為服務調用方式，致力于提供高性能和透明化的RPC遠程服務調用方案。它與Spring無縫集成，基于服務提供方(服務端)與服務調用方(客戶端)角色構建簡單模型，其優點是使用方便、學習成本低。雖然Dubbo 支持短連接大數據量的服務提供模式，但絕大多數情況下都是使用長連接小數據量的模式提供服務使用的。所以，對于類似于電商等同步調用場景多并且能支撐搭建Dubbo 這套比較復雜環境的成本的產品而言，Dubbo 確實是一個可以考慮的選擇。但如果產品業務中由于后臺業務邏輯復雜、時間長而導致異步邏輯比較多的話，可能Dubbo 并不合適。
• Spring CloudSpring Cloud由眾多子項目組成，如Spring Cloud Config、Spring Cloud Netflix、Spring Cloud Consul 等，提供了搭建分布式系統及微服務常用的工具，如配置管理、服務發現、斷路器、智能路由、微代理、控制總線、一次性token、全局鎖、選主、分布式會話和集群狀態等，滿足了構建微服務所需的所有解決方案。比如使用Spring Cloud Config 可以實現統一配置中心，對配置進行統一管理；使用Spring Cloud Netflix 可以實現Netflix 組件的功能 - 服務發現(Eureka)、智能路由(Zuul)、客戶端負載均衡(Ribbon)。

Dubbo & Spring Cloud對比

• dubbo只實現服務治理的核心部分, 而配置管理、api網關、服務跟蹤等功能則需要自己實現. 而Spring Cloud子項目分別覆蓋了微服務架構的方方面面，提供了一整套開箱即用的工具包.
• Dubbo默認采用Dubbo協議，Dubbo協議工作在TCP層,同等條件下性能優于HTTP協議,Spring Clould采用HTTP協議, 性能略遜于Dubbo.
• Dubbo缺省協議采用單一長連接和NIO異步通訊，適合于小數據量大并發的服務調用.
• spring cloud使用Ribbon作為負載均衡的組件，Ribbon需要進行全局配置，個性化配置比較麻煩。Dubbo 可以使用路由策略，然后再進行負載均衡。
• Spring cloud 的 Hystix 提供了服務降級，服務熔斷，依賴隔離.Dubbo 提供了一整套 FailOver、FailFast、Failsafe、FailBack、Aviailable、Broadcast、Forking 策略.

總結

以上是生活随笔為你收集整理的php分布式微服务开发_分布式微服务架构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。