一文看懂Java微服務架構，WEB2.0，垂直架構，分布式架構，微服務架構【云圖智聯】

Java微服務架構

目錄：

1. 了解開發環境&生成環境

2. WEB1.0 & WEB2.0

3. 垂直架構

4. 分布式架構

5. 微服務架構

1.了解開發環境&生產環境

1.1 開發環境

平時在寫代碼的時候，大多都在WIN10/WIN7/Mac.

這些系統都可以稱為開發環境。咱們為了更高效的開發應用程序，安裝很多的軟件，會

導致操作系統不安全，穩定性降低。

2.1. 生產環境（學會如何操作，Linux操作系統）

在生產環境中，操作不會采用Win10/Mac。這種操作系統相對不安全，生產環境是要面向全體用戶的，一般會采用專業的操作系統。

大多數市面上使用的都是基于Linux的操作系統，還有Windows版本的服務器操作系統

Windows 2003 service

02. WEB1.0 & WEB2.0

2.1. WEB1.0時期

在WEB1.0時期，由于帶寬不足，這時的項目大多是內容少，用戶量也不多，甚至有一些項目不需要對外開放，對安全性和穩定性的要求是不高的，

單體架構就足以應對

2.2. WEB2.0時期

隨之到來的WEB2.0 實現了ADSL撥號上網，寬帶提速，最高可以達到8M 用戶量也就不斷增加，一些門戶網站也開始活躍，項目就需要考慮安全性，和穩定性。

在基于單體架構的設計中，無法滿足WEB2.0對項目的需求，需要在單體架構上搭建集群（多個服務器），

在搭建集群之后，可以提升項目的穩定性，并且并發量增加，也可以承受住

2.3. 搭建集群后出現的問題

1. 用戶的請求到底要發送到那臺服務器上，如何才能保證請求平均的分發給不同的服務器，從而緩解用戶量增加的壓力

2. 編寫項目時，如果用戶登錄成功，將用戶的標識存放到的Session中，在搭建集群之后，數據共享問題

3. 當數據量特別龐大時，如果還直接去數據庫查詢，速度很慢，如何提升查詢效率

4. 針對大家在搜索一些數據時，where content like '%#{xxx}% ’

2.4. 針對上述問題，如何解決（中間件）

1.Nginx，用來解決用戶請求平均分發

2.Redis， 用來解決數據共享并實現緩存功能

3.ElacticSearch，用來解決搜索數據的功能

03. 垂直架構

比如項目包含了三個模塊，用戶模塊，商品模塊，訂單模塊，商品模塊。

一般商品瀏覽的商品模塊流量最大，為了防止商品模塊壓力過大，一般直接有效的方法就是搭建集群。

在單體架構的集群上去搭建，效果相對比較差。隨著項目的不斷更新，項目中的功能月越來越多，最嚴重的可能會導致項目無法啟動

關于單體架構中，完美的體驗了低內聚，高耦合。（開發的要求是高內聚，低耦合）

為了解決上述的各種問題，更新了垂直架構

04. 分布式架構

4.1 項目迭代

隨著項目的不斷迭代，新老功能之間需要相互交互，服務器與服務器之間需要通信的。

項目一般分為三層的 Controller Service Dao。導致程序變慢的重災區，一般是Service和Dao，在搭建集群時，確實針對三層都搭建集群，效果不是很好。

架構從垂直架構，演變到了分布式架構

分布式架構落地的技術：

為了解決各個服務之間的通信，國內通訊的方式有兩種：

1.Dubbo 采用的RPC方式

2.SpringCloud 采用的HHTP方式

05. 分布式架構常見問題

5.1服務之間的異步通訊

在使用分布式架構之后，服務之間的通信都是同步的。

在一些不是核心業務的功能上，咱們希望實現異步通訊。

為了實現服務之間的異步通訊，需要學習MQ. MQ-RabbitMQ（消息隊列）

5.2 服務之間通信地址的維護

由于服務越來越多，每個服務的訪問地址都是不一樣的。協議：//地址：端口號

由于我們的模塊繁多，并且模塊搭建的集群數量增加，會導致其他模塊需要維護各種ip地址等信息，導致項目的維護性極低，耦合性變高，并且也無法實現負載均衡的功能

需要使用一個技術來解決當前問題：

Eureka注冊中心幫助我們管理服務信息 ：實現通訊地址維護

Robbin可以幫助我們實現服務之間的負載均衡 ：實現服務之間的負載均衡

5.3 服務降級

在上述的架構中，如果說訂單模塊出現了問題。

只要是涉及到訂單模塊的功能，全部都無法使用。

可能會導致服務器提供的線程池耗盡，給用戶友好的提示都是無法做到的

為了解決上述的問題，使用Hystrix處理，

Hystrix提供了線程池隔離的方式，避免服務器線程池耗盡，在一個服務無法使用時，可以提供斷路器的方式解決

使用Hystrix 幫我們實現斷路器和隔離，并最終服務降級

Eureka,Robbin,Hystrix 都是SpringClod中的組件

5.4 海量數據

海量數據最終會導致數據庫無法存儲全部的內容。即便數據庫可以存儲海量的數據，在查詢數據時，數據庫的響應是極其緩慢的

在用戶高并發的情況下，數據庫也是無法承受住的

為了解決上述的問題，可以基于MyCat實現數據庫的分庫分表。

06. 微服務架構

雖然已經將每個模塊獨立的做開發，比如商品模塊，壓力最大的是商品的查詢。

在單獨模塊中再次拆分項目的方式就可以稱為微服務架構。微服務架構其實屬于分布式架構的

6.2 容器化技術

為了解決模塊過多，運維成本增加的問題。采用Docker容器化技術來幫助我們管理

后期在學習的時候，也需要大量的軟件，可以使用Docker來幫助我們按照軟件。

6.3 分布式架構下的其他問題

分布式架構幫助我們解決了很多問題，但是隨之也帶來了跟多問題：

1. 分布式事務：

最傳統的操作事務的方式，是通過Connection連接對象的方式操作，

Spring也提供了聲明式事務的操作，為了解決事務的問題，后續會使用到RabbitMQ 或者使用到 LCN 方式解決

2.分布式鎖：

傳統的鎖方式，一種是synchronize 或者 Lock鎖，在分布式環境下，傳統的鎖是沒有效果的。為了解決鎖的問題，后續會使用Redis 或者 Zookeeper來解決

3.分布式任務：

在傳統的定時任務下，由于分布式環境的問題，可能會造成任務重復執行，一個比較大的任務希望可以拆分。為了解決這個問題，后續會使用Redis + Quartz 或者 Elastic-Job。

學習視頻歡迎關注智聯優課：