深入理解Spring Cloud與微服務構建【一】 - 1.3 微服務的不足

bawn 發布于2019-08-15 18:15 / 3340人閱讀

摘要：微服務的復雜度框架知識服務于服務通信服務與服務之間相互依賴。服務的部署可選用。指服務的可用性。微服務系統通常是一個系統，即同時滿足了可用性和分區容錯。兩階段提交，將事務分成兩部分能夠大大提高分布式事務成功的概率。

主要體現在如下方面。

微服務的復雜度（框架知識、服務于服務通信、服務與服務之間相互依賴）。

分布式事務（重點）。

服務的劃分（業務場景劃分邊界，最好無耦合，都能多帶帶運行和替換）。

服務的部署（可選用Docker、DevOps）。

多帶帶說下分布式事務，其余就不多做解釋

1.3.1 分布式事物

微服務架構所設計的系統是分布式系統。分布式系統有一個著名的 CAP 理論，即同時滿足“一致性”“可用性”和“分區容錯”是一件不可能的事。

Consistency：指數據的強一致性。如果寫入某個數據成功，之后讀取，讀到的都是新寫入的數據：如果寫入失敗，之后讀取的都不是寫入失敗的數據。

Availability：指服務的可用性。

Partition-tolerance：指分區容錯。

在分布式系統中，P 是基本要求，而單體服務是 CA 系統。微服務系統通常是一個 AP系統，即同時滿足了可用性和分區容錯。這就有了一個難題：在分布式系統中如何保證數據的一致性？這就是大家經常討論的分布式事務。

在微服務系統中，每個服務都是獨立的進程單元，每個服務都有自己的數據庫。通常情況下，只有關系型數據庫在特定的數據引擎下才支持事務，而大多數非關系型數據庫是不支持事務的，例如 MongDB 是不支持事務的，而 Redis是支持事務的。在微服務架構中，分布式事務一直都是一個難以解決的問題，業界給出的解決辦法通常是兩階段提交。

網上購物在日常生活中是一個非常普通的場最，假設我在淘寶上購買了一部手機，需要從我的賬戶中扣除 1000 元錢，同時手機的庫存數量需要減 1。當然需要在賣方的賬戶中加 1000 元錢，為了使案例簡單化，暫時不用考慮。
如果這是一個單體應用，并且使用支持事務的 MySQL 數據庫 ClnnoDB 數據庫引擎才支持事務），我們可能這樣寫代碼：

@Transactional  
public void update () throws RuntimeException( 
    updateAccountTable (); 11更新賬戶表 
    updateGoodsTable (); 11更新商品表 
}

如果是微服務架構，賬戶是一個服務，而商品是一個服務，這時不能用數據庫自帶的事務，因為這兩個數據表不在一個數據庫中。因此常常用到兩階段提交，兩階段提交的過程

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

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

兩階段提交，將事務分成兩部分能夠大大提高分布式事務成功的概率。如果在第一階段都成功了，而執行第二階段的某一個節點失敗，仍然導致數據的不準確，這時一般需要人工去處理，這就是當初在第一步記錄日志的原因。另外，如果分布式事務涉及的節點很多，某一個節點的網絡出現異常會導致整個事務處于阻塞狀態，大大降低數據庫的性能。所以一般情況下，盡量少用分布式事務。

云服務器 GPU云服務器 saas與微服務云服務器與微服務 Spring Cloud 深入理解系列

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/69710.html

深入理解Spring Cloud與微服務構建【一】 - 1.1體架構及其存在的不足

摘要：單體架構簡介經典的層模型，即表示層業務邏輯層和數據訪問層。口數據訪問層用于操作數據庫，用戶在表示層會產生大量的數據，通過數據訪問層對數據庫進行讀寫操作。 1.1.1 單體架構簡介經典的 3 層模型，即表示層、業務邏輯層和數據訪問層。口表示層：用于直接和用戶交互，也稱為交互層，通常是網頁、 UI 等。口業務邏輯層：即業務邏輯處理層，例如用戶輸入的信息要經過業務邏輯層的處理...

My_Oh_My 2019-08-15 18:02 評論0 收藏0
深入理解Spring Cloud與微服務構建【一】 - 1.4 微服務的設計原則與Spring Cl

摘要：微服務的設計原則軟件設計每一個版本都在變化，所以軟件設計應該是漸進式發展。在微服務設計時，一定要考慮清楚這三個難題，從而選擇合適的框架。目前比較流行的微服務框架有社區的公司的等。微服務應該具備的功能。微服務的設計原則軟件設計每一個版本都在變化，所以軟件設計應該是漸進式發展。軟件從一開始就不應該被設計成微服務架構，微服務架構固然有優勢，但是它需要更多的資源，包括服務器資源、技術人員...

ningwang 2019-08-15 18:15 評論0 收藏0
深入理解Spring Cloud與微服務構建【二】 - 2.2 Spring Cloud

摘要：負載均衡組件是一個負載均衡組件，它通常和配合使用。和配合，很容易做到負載均衡，將請求根據負載均衡策略分配到不同的服務實例中。和配合，在消費服務時能夠做到負載均衡。在默認的情況下，和相結合，能夠做到負載均衡智能路由。 2.2.1 簡介 Spring Cloud 是基于 Spring Boot 的。 Spring Boot 是由 Pivotal 團隊提供的全新 Web 框架，它主要的特點...

Rocko 2019-08-16 12:30 評論0 收藏0
深入理解Spring Cloud與微服務構建【二】 - 2.1 微服務應該具備的功能

摘要：口服務的負載均衡。服務的注冊與發現接口管理服務注冊是指向服務注冊中心注冊一個服務實例，服務提供者將自己的服務信息如服務名地址等告知服務注冊中心。服務注冊中心會提供服務的健康檢查方案，檢查被注冊的服務是否可用。服務降級的功能。微服務具有以下的特點。口按照業務來劃分服務，單個服務代碼量小，業務單一，易于維護。口每個微服務都有自己獨立的基礎組件，例如數據庫、緩存等，且運行在獨立...

starsfun 2019-08-15 18:15 評論0 收藏0
深入理解Spring Cloud與微服務構建【一】 - 1.2微服務

摘要：熔斷機制為了防止雪崩效應事件的發生，分布式系統采用了熔斷機制。為了解決這一難題，微服務架構引入了熔斷機制。由于微服務系統是分布式系統，服務與服務之間沒有任何的禍合。 1.2.1 什么是微服務按業務劃分為一個獨立運行的程序，即服務單元。服務之間通過 HTTP 協議相互通信。自動化部署。可以用不同的編程語言。可以用不同的存儲技術。服務集中化管理。微服務是一個分布式系統。 ...

AlexTuan 2019-08-15 18:02 評論0 收藏0