1. 架構演進過程
   1. 純單機版架構
   2. Maven依賴分層單機版架構
   3. WebService服務呼叫分散式架構
      1. CXF框架/HttpClient
      2. RESTTemplate
      3. Dubbo+ZooKeeper
      4. Spring Boot+Spring Cloud

遠古時代：單一架構：整個專案只有一個工程。在Servlet容器上執行的時候，只有一個war包。

黑鐵時代：基於WebService實現方法的遠端調研，進而實現分散式架構

WebService本質就是實現所有“方法遠端呼叫”技術的總和。

方法呼叫形式：

一：本地呼叫：在同一個工程裡面直接呼叫某個物件的某個物件的某個方法。userService.doLogin(user);

二：遠端呼叫：呼叫方法時要經過網路，呼叫另一個工程的方法。

模組A要呼叫模組B，原來單一架構，工程之間通過工程jar呼叫，相互之間依賴，聚合，繼承，屬於本地呼叫；而我們通過網路，可以在java程式碼中發起一個請求，呼叫物件方法；原來web階段我們發現客戶端可以訪問瀏覽器了，而現在通過遠端呼叫發現客戶端專案之間也可以訪問

方法的遠端呼叫內外兩方面意義

對內：幫我們實現分散式架構

對外：讓我們能夠呼叫第三方介面

發簡訊

查物流

看天氣

支付

……

SOA：Service Oriented Architecture面向服務的架構，在專案的內部基於方法的遠端呼叫實現分散式架構，被呼叫的方法工程稱為服務端，呼叫用的方法工程稱為客戶端。

模組A：客戶端，模組B：服務端

模組B提供了服務。模組B提供服務是通過在一個介面中定義可以被呼叫的方法提供服務。

好處：隱藏實現細節，保證資料安全，資金安全，商業祕密安全；面向介面程式設計，只有我們介面不變，不管實現類如何變化，呼叫方都感覺不到，能夠實現解耦合，符合專案開發過程中的“高內聚，低耦合”原則。

你寫過介面嗎？

青銅時代：Dubbo+Zookeeper，實現專案總體的分散式架構

Dubbo:基於RPC(Remote Procedure Call遠端過程呼叫)的分散式架構環境下服務治理框架。

Zookeeper:專案中服務的註冊中心。專案中的各個provider模組將自己開發的服務的相關資訊註冊到Zookeeper，各個consumer（消費）模組根據Zookeeper中註冊的資訊呼叫provider（提供）.

白銀時代：SpringBoot+SpringCloud

SpringBoot：在進行Spring環境下開發是幫開發者簡化配置檔案，簡化第三方的技術檔案。

server:
  port: 10002
spring:
  application:
    name: ManagerProvider
  datasource:
    name: druid-source
    type: com.alibaba.druid.pool.DruidDataSource
    driver-class-name: org.gjt.mm.mysql.Driver
    url: jdbc:mysql://127.0.0.1:3306/atcrowdfunding180725?rewriteBatchedStatements=true&useUnicode=true&characterEncoding=utf8
    username: root
    password: root
    dbcp2:
      min-idle: 5
      initial-size: 5
      max-total: 5
      max-wait-millis: 200
mybatis:
  mapper-locations:
  - classpath:mappers/*Mapper.xml
eureka:
  client:
    service-url:
      defaultZone: http://localhost:10000/eureka

引入Eureka服務註冊中心

                <dependency>
			<groupId>org.springframework.cloud</groupId>
			<artifactId>spring-cloud-starter-eureka</artifactId>
		</dependency>
		@EnableEurekaClient

SpringCloud:實現微服務架構。提供了一整套一站式解決方案。

負載均衡，註冊中心，閘道器，熔斷機制，服務監控。。。。

SpringCloud:要求每個模組，每個元件都是使用SpringBoot開發的微服務工程，而使用SpringBoot時，不一定使用SpirngCloud.

Service Mesh服務網格：服務間通訊的基礎設施層。將它比作是應用程式或者說微服務間的 TCP/IP，負責服務之間的網路呼叫、限流、熔斷和監控。

分散式架構的好處：

有利於分工：直接把一個模組分配給某個小組或某個程式設計師

有利於實現非常龐大的專案模組結構：當我們的各個模組太多時使用package劃分元件無法接受。所有分散到不同工程裡。

模組化程度高，結構更清晰：有利於開發維護。

有利於提升效能：每個模組可以獨佔一個伺服器的硬體資源。

針對某個訪問壓力大的模組可以進行叢集化部署。

叢集：多臺伺服器上執行相同模組

叢集：多臺伺服器上執行相同模組

分散式：多臺伺服器上執行不同模組

中介軟體：

知識體系：

分散式事務

概念

保證分散式架構系統中，修改資料時，讓各個模組和各個中介軟體中儲存的資料保持一致。

※注意：沒辦法做到絕對。

情景舉例

在修改商品資料時，各個元件都需要修改，但是其中某一個操作可能失敗。此時需要回滾機制——但是，這樣的機制並不是天然存在的。

可以在修改操作的那寫個逆操作，但這樣有個問題，逆操作也有可能失敗。

補償性解決方案

簡單來說：失敗的操作再試一次。需要藉助訊息佇列實現效果。

如果第二次嘗試操作又失敗了，那麼寫入日誌的同時觸發報警系統，立即給運維人員或開發人員發簡訊，儘快解決。同時如果有必要藉助客服部門人工進行必要協調。

CAP定理

C：強一致性——在很高強度下保持資料一致

A：高可用性——在併發量很高情況下依然可用

P：分割槽容錯性——整個系統中某個元件故障時整個系統仍然可用而不是崩潰

P必須保證。C和A之間二選一。因為要做到強一致性，需要在必要的地方加資料鎖，必然會影響效能。

CP

AP