第一章微服務架構演進

1.1、單體架構

架構說明：

? 全部功能集中在一個專案內（All in one），

架構優點：

? 架構簡單，前期開發成本低、開發周期短，適合小型專案，

架構缺點：

? 全部功能集成在一個工程中，對于大型專案不易開發、擴展和維護，

? 技術堆疊受限，只能使用一種語言開發，

? 系統性能擴展只能通過擴展集群節點，成本高，

1.2、垂直架構

架構說明：

? 按照業務進行切割，形成小的單體專案，

架構優點：

? 技術堆疊可擴展（不同的系統可以用不同的編程語言撰寫），

架構缺點：

? 功能集中在一個專案中，不利于開發、擴展、維護，

? 系統擴張只能通過集群的方式，

? 專案之間功能冗余、資料冗余、耦合性強，

1.3、SOA架構

架構說明：

? SOA全稱為Service-Oriented Architecture，即面向服務的架構，它可以根據需求通過網路對松散耦合的粗粒度應用組件(服務)進行分布式部署、組合和使用，一個服務通常以獨立的形式存在于作業系統行程中，站在功能的角度，把業務邏輯抽象成可復用的服務，通過服務的編排實作業務的快速再生，目的：把原先固有的業務功能轉變為通用的業務服務，實作業務邏輯的快速復用，

? 將重復功能或模塊抽取成組件的形式，對外提供服務，在專案與服務之間使用ESB（企業服務總線）的形式作為通信的橋梁，

架構優點：

? 重復功能或模塊抽取為服務，提高開發效率，

? 可重用性高，

? 可維護性高，

架構缺點：

? 各系統之間業務不同，很難確認功能或模塊是重復的，

? 抽取服務的粒度大，

? 系統和服務之間耦合度高，

1.4、微服務架構

架構說明：

? 微服務就是將一個單體架構的應用按業務劃分為一個個的獨立運行的程式即服務，它們之間通過 HTTP 協議進行通信，也可以采用訊息佇列來通信，例如 RabbitMQ，Kafaka 等，可以采用不同的編程語言，使用不同的存盤技術，自動化部署（如 Jenkins）減少人為控制，降低出錯概率，服務數量越多，管理起來越復雜，因此采用集中化管理，例如 Eureka，Zookeeper 等都是比較常見的服務集中化管理框架，

? 微服務是一種架構風格，一個大型的復雜軟體應用，由一個或多個微服務組成，系統中的各個微服務可被獨立部署，各個微服務之間是松耦合的，每個微服務僅關注于完成一件任務并很好的完成該任務，

架構優點：

? 服務拆分粒度更細，有利于提高開發效率，

? 可以針對不同服務制定對應的優化方案，

? 適用于互聯網時代，產品迭代周期更短，

架構缺點：

? 粒度太細導致服務太多，維護成本高，

? 分布式系統開發的技術成本高，對團隊的挑戰大，

第二章微服務設計原則

2.1、CAP 定理原則

CAP 原則又稱 CAP 定理，指的是在一個分布式系統中必須具有以下其中兩個特性：

Consistency （一致性）
Availability （可用性）
Partition tolerance（磁區容錯性）

CAP 由 Eric Brewer 在 2000 年 PODC 會議上提出，該猜想在提出兩年后被證明成立，成為我們熟知的 CAP 定理，CAP 三者不可兼得，

特性	定理
Consistency	也叫做資料原子性，系統在執行某項操作后仍然處于一致的狀態，在分布式系統中，更新操作執行成功后所有的用戶都應該讀到最新的值，這樣的系統被認為是具有強一致性的，等同于所有節點訪問同一份最新的資料副本，
Availability	每一個操作總是能夠在一定的時間內回傳結果，這里需要注意的是"一定時間內"和"回傳結果"，一定時間內指的是，在可以容忍的范圍內回傳結果，結果可以是成功或者是失敗，
Partition tolerance	在網路磁區的情況下，被分隔的節點仍能正常對外提供服務(分布式集群，資料被分布存盤在不同的服務器上，無論什么情況，服務器都能正常被訪問)，

CAP 三個特性只能滿足其中兩個，那么取舍的策略就共有三種：

CA without P：如果不要求P（不允許磁區），則C（強一致性）和A（可用性）是可以保證的，但放棄 P 的同時也就意味著放棄了系統的擴展性，也就是分布式節點受限，沒辦法部署子節點，這是違背分布式系統設計的初衷的，
CP without A：如果不要求A（可用），相當于每個請求都需要在服務器之間保持強一致，而P（磁區）會導致同步時間無限延長（也就是等待資料同步完才能正常訪問服務），一旦發生網路故障或者訊息丟失等情況，就要犧牲用戶的體驗，等待所有資料全部一致了之后再讓用戶訪問系統，設計成 CP 的系統其實不少，最典型的就是分布式資料庫，如 Redis、HBase 等，對于這些分布式資料庫來說，資料的一致性是最基本的要求，因為如果連這個標準都達不到，那么直接采用關系型資料庫就好，沒必要再浪費資源來部署分布式資料庫，
AP without C：要高可用并允許磁區，則需放棄一致性，一旦磁區發生，節點之間可能會失去聯系，為了高可用，每個節點只能用本地資料提供服務，而這樣會導致全域資料的不一致性，典型的應用就如某米的搶購手機場景，可能前幾秒你瀏覽商品的時候頁面提示是有庫存的，當你選擇完商品準備下單的時候，系統提示你下單失敗，商品已售完，這其實就是先在 A（可用性）方面保證系統可以正常的服務，然后在資料的一致性方面做了些犧牲，雖然多少會影響一些用戶體驗，但也不至于造成用戶購物流程的嚴重阻塞，

2.2、AFK 拆分原則

? 業界對于可擴展的系統架構設計有一個樸素的理念，就是：通過加機器可以解決容量和可用性問題（如果一臺不行就兩臺，兩臺不行就多臺），

? 用個段子描述就是：世界上沒有什么事是一頓燒烤解決不了的，如果有，那就兩頓，

? 這一理念在“云計算”概念瘋狂流行的今天，得到了廣泛的認可，對于一個規模迅速增長的系統而言，容量和性能問題當然是首當其沖的，但是隨著時間的向前，系統規模的增長，除了面對性能與容量的問題外，還需要面對功能與模塊數量上增長帶來的系統復雜性問題，以及業務變化帶來的提供差異化服務問題，而許多系統在架構設計時并未充分考慮到這些問題，導致系統的重構成為常態，從而影響業務交付能力，還浪費人力財力，對此《The Art of Scalability》一書提出了一個更加系統的可擴展模型—AKF 可擴展立方，這個立方體中沿著三個坐標軸設定分別為 X，Y，Z，理論上按照這三個擴展模式，可以將一個單體系統，進行無限擴展，

X 軸：指的是水平復制，很好理解，就是講單體系統多運行幾個實體，成為集群加負載均衡的模式，
Y 軸：就是我們所說的微服務的拆分模式，就是基于不同的業務拆分，
Z 軸：是基于類似的資料磁區，比如一個互聯網打車應用突然火了，用戶量激增，集群模式撐不住了，那就按照用戶請求的地區進行資料磁區，北京、上海、四川等多建幾個集群，

場景說明：比如打車應用，一個集群撐不住時，分了多個集群，后來用戶激增還是不夠用，經過分析發現是乘客和車主訪問量很大，就將打車應用拆成了三個，分別為乘客服務、車主服務、支付服務，三個服務的業務特點各不相同，獨立維護，各自都可以再次按需擴展，

2.3、前后端分離原則

前后端技術分離，可以由各自的專家來對各自的領域進行優化，這樣前端的用戶體驗優化效果更好，
前后端分離模式下，前后端互動界面更清晰，就剩下了介面模型，后端的介面簡潔明了，更容易維護，
前端多渠道集成場景更容易實作，后端服務無需變更，采用統一的資料和模型，可以支持多個前端：例如：微信小程式、PC 前端、Android 前端、IOS 前端，

2.4、無狀態服務原則

? 對于無狀態服務，首先說一下什么是狀態：如果一個資料需要被多個服務共享，才能完成一筆交易，那么這個資料被稱為狀態，進而依賴這個“狀態”資料的服務被稱為有狀態服務，反之稱為無狀態服務，那么這個無狀態服務原則并不是說在微服務架構里就不允許存在狀態，表達的真實意思是要把有狀態的業務服務改變為無狀態的計算類服務，那么狀態資料也就相應的遷移到對應的“有狀態資料服務”中，場景說明：例如我們以前在本地記憶體中建立的資料快取、Session 快取，到現在的微服務架構中就應該把這些資料遷移到分布式快取中存盤，讓業務服務變成一個無狀態的計算節點，遷移后，就可以做到按需動態伸縮，微服務應用在運行時動態增刪節點，就不再需要考慮快取資料如何同步的問題，

2.5、Restful通信風格

? 基于**“無狀態服務原則”**，在這里我們直接推薦一個實踐優選的 Restful 通信風格，因為他有很多好處：

無狀態協議 HTTP，具備先天優勢，擴展能力很強，例如需要安全加密時，有現成的成熟方案 HTTPS 可用，
JSON 報文序列化，輕量簡單，人與機器均可讀，學習成本低，搜索引擎友好，
語言無關，各大熱門語言都提供成熟的 Restful API 框架，相對其他的一些 RPC 框架生態更完善，

第三章 Spring Cloud介紹

? Spring Cloud 是一個服務治理平臺，提供了一些服務框架，包含了：服務注冊與發現、配置中心、訊息中心、負載均衡、資料監控等等，

? Spring Cloud 是一個微服務框架，相比 Dubbo 等 RPC 框架，Spring Cloud 提供了全套的分布式系統解決方案，

? Spring Cloud 對微服務基礎框架 Netflix 的多個開源組件進行了封裝，同時又實作了和云端平臺以及 Spring Boot 框架的集成，

? Spring Cloud 是一個基于 Spring Boot 實作的云應用開發工具，它為開發中的配置管理、服務發現、斷路器、智能路由、微代理、控制總線、全域鎖、決策競選、分布式會話和集群狀態管理等操作提供了一種簡單的開發方式，

? Spring Cloud 為開發者提供了快速構建分布式系統的工具，開發者可以快速的啟動服務或構建應用、同時能夠快速和云平臺資源進行對接，微服務是可以獨立部署、水平擴展、獨立訪問（或者有獨立的資料庫）的服務單元，Spring Cloud 就是這些微服務的大管家，采用了微服務這種架構之后，專案的數量會非常多，Spring Cloud 做為大管家需要管理好這些微服務，自然需要很多小弟（組件）來幫忙，

第四章 Spring Cloud組件介紹

4.1、第一代微服務

? Netflix是一家美國公司，在美國、加拿大提供互聯網隨選流媒體播放，定制DVD、藍光光碟在線出租業務，該公司成立于1997年，總部位于加利福尼亞州洛斯蓋圖，1999年開始訂閱服務，2009年，該公司可提供多達10萬部DVD電影，并有1千萬的訂戶，2007年2月25日，Netflix宣布已經售出第10億份DVD，HIS一份報告中表示，2011年Netflix網路電影銷量占據美國用戶在線電影總銷量的45%，針對多種 Netflix 組件提供的開發工具包，其中包括 Eureka、Hystrix、Ribbon、Zuul、Archaius 等，

官方地址：https://github.com/spring-cloud/spring-cloud-netflix

Netflix Eureka：一個基于 Rest 服務的服務治理組件，包括服務注冊中心、服務注冊與服務發現機制的實作，實作了云端負載均衡和中間層服務器的故障轉移，
Netflix Hystrix：容錯管理工具，實作斷路器模式，通過控制服務的節點，從而對延遲和故障提供更強大的容錯能力，
Netflix Ribbon：客戶端負載均衡的服務呼叫組件，
Netflix Feign：基于 Ribbon 和 Hystrix 的宣告式服務呼叫組件，
Netflix Zuul：微服務網關，提供動態路由，訪問過濾等服務，
Netflix Archaius：配置管理 API，包含一系列配置管理 API，提供動態型別化屬性、執行緒安全配置操作、輪詢框架、回呼機制等功能，

4.2、第二代微服務

? Spring Cloud Alibaba 致力于提供微服務開發的一站式解決方案，此專案包含開發分布式應用微服務的必需組件，方便開發者通過 Spring Cloud 編程模型輕松使用這些組件來開發分布式應用服務，依托 Spring Cloud Alibaba，只需要添加一些注解和少量配置，就可以將 Spring Cloud 應用接入阿里微服務解決方案，通過阿里中間件來迅速搭建分布式應用系統，

官方地址：https://github.com/alibaba/spring-cloud-alibaba

Sentinel：把流量作為切入點，從流量控制、熔斷降級、系統負載保護等多個維度保護服務的穩定性，
Nacos：一個更易于構建云原生應用的動態服務發現、配置管理和服務管理平臺，
RocketMQ：一款開源的分布式訊息系統，基于高可用分布式集群技術，提供低延時的、高可靠的訊息發布與訂閱服務，
Dubbo：Apache Dubbo? 是一款高性能 Java RPC 框架，
Seata：阿里巴巴開源產品，一個易于使用的高性能微服務分布式事務解決方案，
Alibaba Cloud OSS: 阿里云物件存盤服務（Object Storage Service，簡稱 OSS），是阿里云提供的海量、安全、低成本、高可靠的云存盤服務，您可以在任何應用、任何時間、任何地點存盤和訪問任意型別的資料，
Alibaba Cloud SchedulerX: 阿里中間件團隊開發的一款分布式任務調度產品，提供秒級、精準、高可靠、高可用的定時（基于 Cron 運算式）任務調度服務，
Alibaba Cloud SMS: 覆寫全球的短信服務，友好、高效、智能的互聯化通訊能力，幫助企業迅速搭建客戶觸達通道，

第五章 Spring Cloud版本介紹

5.1、版本歷史

采用倫敦的地鐵站名稱來作為版本號的命名，根據首字母排序，字母順序靠后的版本號越大，

注意：以下資料截至到2021-01-31號之前，

Angel
Brixton
Camden
Dalston
Edgware
Finchley
Greenwich
Hoxton
2020.0 (code name ilford)

5.2、版本說明

發布計劃：

標識	含義	說明
BUILD-XXX	開發版	開發團隊內部使用
M	里程碑版	MileStone，M1 表示第 1 個里程碑版本，一般同時標注 PRE，表示預覽版
RC	候選發布版	Release Candidate，正式發布版的前一個觀察期，不添加新功能，主要著重于除錯
SR	正式發布版	Service Release，SR1 表示第 1 個正式版本，一般同時標注 GA，表示穩定版本
GA	穩定版	經過全面測驗并可對外發行稱之為GA（General Availability）

各版本號：

例如：Spring Cloud Alibaba 2.1.0.RELEASE

2：主版本號，當功能模塊有較大更新或者整體架構發生變化時，主版本號會更新，
1：次版本號，次版本表示只是區域的一些變動，
0：修改版本號，一般是 bug 的修復或者是小的變動，
RELEASE：希臘字母版本號，標注當前版本的軟體處于哪個開發階段，

希臘字母：

Base：設計階段，只有相應的設計沒有具體的功能實作，
Alpha：軟體的初級版本，存在較多的 bug，
Bate：表示相對 Alpha 有了很大的進步，消除了嚴重的 bug，還存在一些潛在的 bug，
Gamma：是 Beta 版做過一些修改，成為正式發布的候選版本（Release Candidate），
Release：該版本表示最終版，

第六章 Spring Cloud版本要求

查看地址：https://start.spring.io/actuator/info

6.1、Spring Cloud

具體版本要求地址：https://docs.spring.io/spring-cloud/docs/Hoxton.SR9/reference/html/

注意：maven建議使用3.6.3，jdk應該保持1.8及以上，

6.2、Spring Cloud Alibaba

具體版本要求地址：https://github.com/alibaba/spring-cloud-alibaba/blob/master/README-zh.md

注意：maven建議使用3.6.3，jdk應該保持1.8及以上，

第七章 Spring Cloud開發準備

7.1、idea創建父工程

7.2、idea統一編碼集

7.3、idea注解的配置

7.4、idea排除的檔案

*.hprof;*.pyc;*.pyo;*.rbc;*.yarb;*~;.DS_Store;.git;.hg;.svn;CVS;__pycache__;_svn;vssver.scc;vssver2.scc;*.idea;*.iml;

7.5、idea熱部署設定

按下 CTRL+ALT+SHITF+/ 會彈出一個視窗，請點擊 Registry ，

注意：這一步設定完成以后，請重新啟動idea，為了讓這些配置生效，

7.6、修改 POM 內容

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>com.caochenlei</groupId>
  <artifactId>spring-cloud-study</artifactId>
  <version>2021</version>

  <properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <maven.compiler.source>1.8</maven.compiler.source>
    <maven.compiler.target>1.8</maven.compiler.target>
  </properties>

  <dependencyManagement>
    <dependencies>
      <!--spring boot 2.3.5.RELEASE-->
      <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-dependencies</artifactId>
        <version>2.3.5.RELEASE</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
      <!--spring cloud Hoxton.SR9-->
      <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-dependencies</artifactId>
        <version>Hoxton.SR9</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
    </dependencies>
  </dependencyManagement>

  <build>
    <plugins>
      <plugin>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-maven-plugin</artifactId>
        <configuration>
          <fork>true</fork>
          <addResources>true</addResources>
        </configuration>
      </plugin>
    </plugins>
  </build>

</project>

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/254526.html

標籤：其他

上一篇：都2021年了，還不會JetPack的Android開發以后連面試機會都沒有！

下一篇：面試阿里被質問：ConcurrentHashMap執行緒安全嗎

Spring Cloud 入門篇

第一章 微服務架構演進

1.1、單體架構

1.2、垂直架構

1.3、SOA架構

1.4、微服務架構

第二章 微服務設計原則

2.1、CAP 定理原則

2.2、AFK 拆分原則

2.3、前后端分離原則

2.4、無狀態服務原則

2.5、Restful通信風格

第三章 Spring Cloud介紹

第四章 Spring Cloud組件介紹

4.1、第一代微服務

4.2、第二代微服務

第五章 Spring Cloud版本介紹

5.1、版本歷史

5.2、版本說明

第六章 Spring Cloud版本要求

6.1、Spring Cloud

6.2、Spring Cloud Alibaba

第七章 Spring Cloud開發準備

7.1、idea創建父工程

7.2、idea統一編碼集

7.3、idea注解的配置

7.4、idea排除的檔案

7.5、idea熱部署設定

7.6、修改 POM 內容

第一章微服務架構演進

第二章微服務設計原則