springboot去中心化

『壹』 90 SpringCloud 解決分布式事務--lcn解決分布式事務

1，分布式事務產生的背景。
分情況而定
1， 在單體的項目中，多個不同的業務邏輯都是在同一個數據源中實現事務管理，是不存在分布式事務的問題，因為同一個數據源的情況都是採用事務管理器，相當於每個事務管理器對應一個數據源。
[圖片上傳失敗...(image-810669-1618491127348)]
2，在單體的項目中，有多個不同的數據源，每個數據源都有自己獨立的事務管理器，互不影響，那麼這時候也會存在多數據源事務管理： 解決方案 jta+Atomikos
[圖片上傳失敗...(image-7df061-1618491220423)]
3，在分布式/微服務架構中，每個服務都有自己的本地事務，每個服務本地事務互不影響，那麼這時候也會存在分布式事務的問題。
事務的定義：
對我們的業務邏輯可以實現提交或者回滾，保證數據的一致性的情況。
所以要麼提交，要麼回滾
原子性a 要麼提交 要麼回滾
一致性c
隔離性i 多個事務在一起執行的時候，互不影響；
持久性d 事務一旦提交或者回滾後，不會在對該結果有任何影響

2，傳統分布式事務解決方案
3，2PC/3PC協議使用場景。
4，LCN為什麼不更新了？那些思想值得學習、
5，分布式事務解決方案有哪些？
6，強一致性/最終一致性區別。
7，LCn深度源碼解讀。

1 CAP定律和BASE理論

1.1 CAP定律#

這個定理的內容是指的是在一個分布式系統中、Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區容錯性），三者不可得兼。

（一）一致性（C）

在分布式系統中的所有數據備份，在同一時刻是否同樣的值。（等同於所有節點訪問同一份最新的數據副本）

（二）可用性（A）

在集群中一部分節點故障後，集群整體是否還能響應客戶端的讀寫請求。（對數據更新具備高可用性）

（三）分區容錯性（P） 形成腦裂問題

以實際效果而言，分區相當於對通信的時限要求。系統如果不能在時限內達成數據一致性，就意味著發生了分區的情況，必須就當前操作在C和A之間做出選擇。

https://ke..com/item/%E5%AE%B9%E9%94%99%E7%8E%87/9967698?fr=aladdin

（四）總結一下

以上可以知道分區容錯性（P）主要代表網路波動產生的錯誤，這是不可避免的，且這個三個模式不可兼得，所以目前就只有兩種模式：CP和AP模式。

其中CP表示遵循一致性原則，但不能保證高可用性，其中zookeeper作為注冊中心就是採用CP模式，因為zookeeper有過半節點不可以的話整個zookeeper將不可用。

AP表示遵循於可用性原則，例如Eureka作為注冊中心用的是AP模式，因為其為去中心化，採用你中有我我中有你的相互注冊方式，只要集群中有一個節點可以使用，整個eureka服務就是可用的，但可能會出現短暫的數據不一致問題。

AP保證可用性：但是不能保證每個副本數據數據一致性；

CP保證數據一致性：如果有過半的zk節點宕機的情況下，不能保證可用性，但是必須保證每個副本節點之間數據一致性， 比如ZK；

BASE是Basically Available（基本可用）、Soft state（軟狀態）和 Eventually consistent（最終一致性）三個短語的縮寫。BASE理論是對CAP中一致性和可用性權衡的結果，其來源於對大規模互聯網系統分布式實踐的總結， 是基於CAP定理逐步演化而來的。BASE理論的核心思想是：即使無法做到強一致性，但每個應用都可以根據自身業務特點，採用適當的方式來使系統達到最終一致性。

（一）基本可用

基本可用是指分布式系統在出現不可預知故障的時候，允許損失部分可用性，注意，這絕不等價於系統不可用。

比如：響應時間上的損失。正常情況下，一個在線搜索引擎需要在0.5秒之內返回給用戶相應的查詢結果，但由於出現故障，查詢結果的響應時間增加了1~2秒。

系統功能上的損失：正常情況下，在一個電子商務網站上進行購物的時候，消費者幾乎能夠順利完成每一筆訂單，但是在一些節日大促購物高峰的時候，由於消費者的購物行為激增，為了保護購物系統的穩定性，部分消費者可能會被引導到一個降級頁面。

（二）軟狀態

軟狀態指允許系統中的數據存在中間狀態，並認為該中間狀態的存在不會影響系統的整體可用性， 即允許系統在不同節點的數據副本之間進行數據同步的過程存在延時 。

（三）最終一致性

最終一致性強調的是所有的數據副本，在經過一段時間的同步之後，最終都能夠達到一個一致的狀態。因此，最終一致性的本質是需要系統保證最終數據能夠達到一致，而不需要實時保證系統數據的強一致性。

目前主流分布式解決框架：
1，單體項目多數據源，可以jta+Atomikos
2,基於RabbitMQ的形式解決，最終一致性的思想。
3，基於RocketMQ解決分布式事務，採用事務消息。
4，LCn採用lcn模式，假關閉連接
5,Alibaba的Seata

6，跨語言的方式實現解決分布式事務問題，類似於支付寶回調。
倆階段提交協議基本概念：
2階段提交協議可以理解為2pc，也就是分為參與者和協調者，協調者會通過2次階段實現數據最終一致性。
2pc和3pc的區別就是解決參與者超時的問題和多加了一層詢問，保證數據的傳輸可靠性。

http://www.txlcn.org/zh-cn/ LCN並不生產事務，LCN只是本地事務的協調工

現在官網已經不維護呢，可以參考：GitEE

https://gitee.com/wangliang1991/tx-lcn?_from=gitee_search

默認密碼為：codingapi
lcn基本實現處理：
1，發起方與參與方都與我們的lcn管理器一直保持長連接；
2，發起方在調用介面前，先向lcn管理器中申請一個全局的事務分組id.
3,發起方調用介面的時候在請求頭中傳遞事務分組id
,4參與方獲取到請求頭中有事務分組的id的，則當前業務邏輯執行完實現假關閉，不會提交或者回滾事務『
5，發起方調用完介面後，如果出現異常的情況下，在通知給事務回滾事務，這時候事務協調則告訴參與方回滾當前的事務。
lcn解決分布式事務的原理：
角色劃分：
1，全局事務協調者（組長）；
2，發起方--調用介面者
3，參與方--被別人調用介面。
訂單（發起方）調用派單（參與方）
1.發起方和參與方都會與我們的全局事務協調者保持長連接；

SpringBoot整合lcn5.0

Maven依賴

相關配置

參與方獲取全局id
1.SpringTracingApplier
攔截器 獲取feign客戶端請求頭中的參數全局事務分組id，緩存到threadlocal中。

『貳』 如何快速搭建一個微服務架構

什麼是微服務？

微服務(Microservices Architecture)是一種架構風格，一個大型復雜軟體應用由一個或多個微服務組成。系統中的各個微服務可被獨立部署，各個微服務之間是松耦合的。每個微服務僅關注於完成一件任務並很好地完成該任務。在所有情況下，每個任務代表著一個小的業務能力。

微服務的概念源於2014年3月Martin Fowler所寫的文章「Microservices」 martinfowler.com/articles/mi…

單體架構(Monolithic Architecture )

企業級的應用一般都會面臨各種各樣的業務需求，而常見的方式是把大量功能堆積到同一個單體架構中去。比如：常見的ERP、CRM等系統都以單體架構的方式運行，同時由於提供了大量的業務功能，隨著功能的升級，整個研發、發布、定位問題，擴展，升級這樣一個「怪物」系統會變得越來越困難。

這種架構模式就是把應用整體打包部署，具體的樣式依賴本身應用採用的語言，如果採用java語言，自然你會打包成war包，部署在Tomcat或者Jetty這樣的應用伺服器上，如果你使用spring boot還可以打包成jar包部署。其他還有Rails和Node.js應用以目錄層次的形式打包

上圖：單體架構

大部分企業通過SOA來解決上述問題，SOA的思路是把應用中相近的功能聚合到一起，以服務的形式提供出去。因此基於SOA架構的應用可以理解為一批服務的組合。SOA帶來的問題是，引入了大量的服務、消息格式定義和規范。

多數情況下，SOA的服務直接相互獨立，但是部署在同一個運行環境中（類似於一個Tomcat實例下，運行了很多web應用）。和單體架構類似，隨著業務功能的增多SOA的服務會變得越來越復雜，本質上看沒有因為使用SOA而變的更好。圖1，是一個包含多種服務的在線零售網站，所有的服務部署在一個運行環境中，是一個典型的單體架構。

單體架構的應用一般有以下特點：

微服務架構（Microservices Architecture）

微服務架構的核心思想是，一個應用是由多個小的、相互獨立的、微服務組成，這些服務運行在自己的進程中，開發和發布都沒有依賴。不同服務通過一些輕量級交互機制來通信，例如 RPC、HTTP 等，服務可獨立擴展伸縮，每個服務定義了明確的邊界，不同的服務甚至可以採用不同的編程語言來實現，由獨立的團隊來維護。簡單的來說，一個系統的不同模塊轉變成不同的服務！而且服務可以使用不同的技術加以實現！

上圖：微服務架構

微服務設計

那我們在微服務中應該怎樣設計呢。以下是微服務的設計指南：

微服務消息

在單體架構中，不同功能之間通信通過方法調用，或者跨語言通信。SOA降低了這種語言直接的耦合度，採用基於SOAP協議的web服務。這種web服務的功能和消息體定義都十分復雜，微服務需要更輕量的機制。

同步消息 REST

同步消息就是客戶端需要保持等待，直到伺服器返回應答。REST是微服務中默認的同步消息方式，它提供了基於HTTP協議和資源API風格的簡單消息格式，多數微服務都採用這種方式（每個功能代表了一個資源和對應的操作）

非同步消息 – AMQP, STOMP, MQTT

非同步消息就是客戶端不需要一直等待服務應答，有應到後會得到通知。某些微服務需要用到非同步消息，一般採用AMQP, STOMP, MQTT 這三種通訊協議

消息格式 – JSON, XML, Thrift, ProtoBuf, Avro

消息格式是微服務中另外一個很重要的因素。SOA的web服務一般採用文本消息，基於復雜的消息格式（SOAP）和消息定義（xsd）。微服務採用簡單的文本協議JSON和XML，基於HTTP的資源API風格。如果需要二進制，通過用到Thrift, ProtoBuf, Avro。

服務約定 – 定義介面 – Swagger, RAML, Thrift IDL

如果把功能實現為服務，並發布，需要定義一套約定。單體架構中，SOA採用WSDL，WSDL過於復雜並且和SOAP緊耦合，不適合微服務。

REST設計的微服務，通常採用Swagger和RAML定義約定。

對於不是基於REST設計的微服務，比如Thrift，通常採用IDL（Interface Definition Languages），比如Thrift IDL。

微服務集成 (服務間通信)

大部分微服務基於RPC、HTTP、JSON這樣的標准協議，集成不同標准和格式變的不再重要。另外一個選擇是採用輕量級的消息匯流排或者網關，有路由功能，沒有復雜的業務邏輯。下面就介紹幾種常見的架構方式。

點對點方式

點對點方式中，服務之間直接用。每個微服務都開放REST API，並且調用其它微服務的介面。

上圖：通過點對點方式通信

很明顯，在比較簡單的微服務應用場景下，這種方式還可行，隨著應用復雜度的提升，會變得越來越不可維護。這點有些類似SOA的ESB，盡量不採用點對點的集成方式。

API-網關方式

API網關方式的核心要點是，所有的客戶端和消費端都通過統一的網關接入微服務，在網關層處理所有的非業務功能個。通常，網關也是提供REST/HTTP的訪問API。服務端通過API-GW注冊和管理服務。

上圖：通過API-網關暴露微服務

所有的業務介面通過API網關暴露，是所有客戶端介面的唯一入口。微服務之間的通信也通過API網關。

採用網關方式有如下優勢：

目前，API網關方式應該是微服務架構中應用最廣泛的設計模式。

消息代理方式

微服務也可以集成在非同步的場景下，通過隊列和訂閱主題，實現消息的發布和訂閱。一個微服務可以是消息的發布者，把消息通過非同步的方式發送到隊列或者訂閱主題下。作為消費者的微服務可以從隊列或者主題共獲取消息。通過消息中間件把服務之間的直接調用解耦。

上圖：非同步通信方式

通常非同步的生產者/消費者模式，通過AMQP, STOMP, MQTT 等非同步消息通訊協議規范。

數據的去中心化

單體架構中，不同功能的服務模塊都把數據存儲在某個中心資料庫中。

每個微服務有自己私有的資料庫，其它微服務不能直接訪問。單體架構，用一個資料庫存儲所有數據

微服務方式，多個服務之間的設計相互獨立，數據也應該相互獨立（比如，某個微服務的資料庫結構定義方式改變，可能會中斷其它服務）。因此，每個微服務都應該有自己的資料庫。

每個微服務有自己私有的資料庫，其它微服務不能直接訪問。每個微服務有自己私有的資料庫，其它微服務不能直接訪問。

數據去中心話的核心要點：

數據的去中心化，進一步降低了微服務之間的耦合度，不同服務可以採用不同的資料庫技術（SQL、NoSQL等）。在復雜的業務場景下，如果包含多個微服務，通常在客戶端或者中間層（網關）處理。

微服務架構的優點：

微服務架構的缺點：

微服務的一些想法在實踐上是好的，但當整體實現時也會呈現出其復雜性。

關於微服務架構的取捨

『叄』 如何理解中心化與去中心化概念

在一個分布有眾多節點的系統中，每個節點都具有高度自治的特徵。節點之間彼此可以自由連接，形成新的連接單元。任何一個節點都可能成為階段性的中心，但不具備強制性的中心控制功能。節點與節點之間的影響，會通過網路而形成非線性因果關系。這種開放式、扁平化、平等性的系統現象或結構，我們稱之為去中心化。

對於去中心化，很多人都有誤解，甚至進入一個困局——去中心化就是不要中心。去中心化，不是不要中心，而是由節點來自由選擇中心、自由決定中心。簡單地說，中心化的意思，是中心決定節點。節點必須依賴中心，節點離開了中心就無法生存。在去中心化系統中，任何人都是一個節點，任何人也都可以成為一個中心。任何中心都不是永久的，而是階段性的，任何中心對節點都不具有強制性。

 

舉例說明

中心化：SOA ESB中心化服務架構；去中心化：Dubbo、Spring Cloud去中心化架構。

中心化：上課；去中心化：學術交流

中心化：看電影；去中心化：玩手機

其他看法

通俗地講，中心化就是一個或幾個認證的嘉賓在講話，所有其他人還能參與聽，類似於上課的模式。而去中心化就是每個人都可以講話，都可以選擇聽還是選擇講，就像自由討論模式。以前的門戶網站是中心化，今天的博客，社交媒體都是去中心化。

當然在今天沒有完全的中心化和去中心化，就像大家普遍認為淘寶京東是中心化平台，但它們的用戶也可以通過社交渠道去分享發掘流量，淘寶有自己的「社區」，京東也有自己的「發現」，這些都是去中心化的形態