Java微服務(wù)架構(gòu)

目錄：

1.  了解開發(fā)環(huán)境&生成環(huán)境
2.  WEB1.0 & WEB2.0
3.  垂直架構(gòu)
4.  分布式架構(gòu)
5.  微服務(wù)架構(gòu)

1.了解開發(fā)環(huán)境&生產(chǎn)環(huán)境

1.1 開發(fā)環(huán)境

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

這些系統(tǒng)都可以稱為開發(fā)環(huán)境。咱們?yōu)榱烁咝У拈_發(fā)應(yīng)用程序，安裝很多的軟件，會

導(dǎo)致操作系統(tǒng)不安全，穩(wěn)定性降低。

2.1. 生產(chǎn)環(huán)境（學(xué)會如何操作，Linux操作系統(tǒng)）

在生產(chǎn)環(huán)境中，操作不會采用Win10/Mac。這種操作系統(tǒng)相對不安全，生產(chǎn)環(huán)境是要面向全體用戶的，一般會采用專業(yè)的操作系統(tǒng)。

大多數(shù)市面上使用的都是基于Linux的操作系統(tǒng)，還有Windows版本的服務(wù)器操作系統(tǒng)

Windows 2003 service

02. WEB1.0 & WEB2.0

2.1. WEB1.0時期

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

單體架構(gòu)就足以應(yīng)對

2.2. WEB2.0時期

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

在基于單體架構(gòu)的設(shè)計(jì)中，無法滿足WEB2.0對項(xiàng)目的需求，需要在單體架構(gòu)上搭建集群（多個服務(wù)器），

在搭建集群之后，可以提升項(xiàng)目的穩(wěn)定性，并且并發(fā)量增加，也可以承受住

2.3. 搭建集群后出現(xiàn)的問題

1.  用戶的請求到底要發(fā)送到那臺服務(wù)器上，如何才能保證請求平均的分發(fā)給不同的服務(wù)器，從而緩解用戶量增加的壓力
2.  編寫項(xiàng)目時，如果用戶登錄成功，將用戶的標(biāo)識存放到的Session中，在搭建集群之后，數(shù)據(jù)共享問題
3.  當(dāng)數(shù)據(jù)量特別龐大時，如果還直接去數(shù)據(jù)庫查詢，速度很慢，如何提升查詢效率
4.  針對大家在搜索一些數(shù)據(jù)時，where content like '%#{xxx}% ’

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

1.Nginx，用來解決用戶請求平均分發(fā)

2.Redis， 用來解決數(shù)據(jù)共享并實(shí)現(xiàn)緩存功能

3.ElacticSearch，用來解決搜索數(shù)據(jù)的功能

03. 垂直架構(gòu)

比如項(xiàng)目包含了三個模塊，用戶模塊，商品模塊，訂單模塊，商品模塊。

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

在單體架構(gòu)的集群上去搭建，效果相對比較差。隨著項(xiàng)目的不斷更新，項(xiàng)目中的功能月越來越多，最嚴(yán)重的可能會導(dǎo)致項(xiàng)目無法啟動

關(guān)于單體架構(gòu)中，完美的體驗(yàn)了低內(nèi)聚，高耦合。（開發(fā)的要求是高內(nèi)聚，低耦合）

為了解決上述的各種問題，更新了垂直架構(gòu)

04. 分布式架構(gòu)

4.1 項(xiàng)目迭代

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

項(xiàng)目一般分為三層的 Controller Service Dao。導(dǎo)致程序變慢的重災(zāi)區(qū)，一般是Service和Dao，在搭建集群時，確實(shí)針對三層都搭建集群，效果不是很好。

架構(gòu)從垂直架構(gòu)，演變到了分布式架構(gòu)

分布式架構(gòu)落地的技術(shù)：

為了解決各個服務(wù)之間的通信，國內(nèi)通訊的方式有兩種：

1.Dubbo 采用的RPC方式

2.SpringCloud 采用的HHTP方式

05. 分布式架構(gòu)常見問題

5.1服務(wù)之間的異步通訊

在使用分布式架構(gòu)之后，服務(wù)之間的通信都是同步的。

在一些不是核心業(yè)務(wù)的功能上，咱們希望實(shí)現(xiàn)異步通訊。

為了實(shí)現(xiàn)服務(wù)之間的異步通訊，需要學(xué)習(xí)MQ. MQ-RabbitMQ（消息隊(duì)列）

5.2 服務(wù)之間通信地址的維護(hù)

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

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

需要使用一個技術(shù)來解決當(dāng)前問題：

Eureka注冊中心幫助我們管理服務(wù)信息 ：實(shí)現(xiàn)通訊地址維護(hù)

Robbin可以幫助我們實(shí)現(xiàn)服務(wù)之間的負(fù)載均衡 ：實(shí)現(xiàn)服務(wù)之間的負(fù)載均衡

5.3 服務(wù)降級

在上述的架構(gòu)中，如果說訂單模塊出現(xiàn)了問題。

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

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

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

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

使用Hystrix 幫我們實(shí)現(xiàn)斷路器和隔離，并最終服務(wù)降級

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

5.4 海量數(shù)據(jù)

海量數(shù)據(jù)最終會導(dǎo)致數(shù)據(jù)庫無法存儲全部的內(nèi)容。即便數(shù)據(jù)庫可以存儲海量的數(shù)據(jù)，在查詢數(shù)據(jù)時，數(shù)據(jù)庫的響應(yīng)是極其緩慢的

在用戶高并發(fā)的情況下，數(shù)據(jù)庫也是無法承受住的

為了解決上述的問題，可以基于MyCat實(shí)現(xiàn)數(shù)據(jù)庫的分庫分表。

06. 微服務(wù)架構(gòu)

雖然已經(jīng)將每個模塊獨(dú)立的做開發(fā)，比如商品模塊，壓力最大的是商品的查詢。

在單獨(dú)模塊中再次拆分項(xiàng)目的方式就可以稱為微服務(wù)架構(gòu)。微服務(wù)架構(gòu)其實(shí)屬于分布式架構(gòu)的

6.2 容器化技術(shù)

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

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

6.3 分布式架構(gòu)下的其他問題

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

1. 分布式事務(wù)：

最傳統(tǒng)的操作事務(wù)的方式，是通過Connection連接對象的方式操作，

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

2.分布式鎖：

傳統(tǒng)的鎖方式，一種是synchronize 或者 Lock鎖，在分布式環(huán)境下，傳統(tǒng)的鎖是沒有效果的。為了解決鎖的問題，后續(xù)會使用Redis 或者 Zookeeper來解決

3.分布式任務(wù)：

在傳統(tǒng)的定時任務(wù)下，由于分布式環(huán)境的問題，可能會造成任務(wù)重復(fù)執(zhí)行，一個比較大的任務(wù)希望可以拆分。為了解決這個問題，后續(xù)會使用Redis + Quartz 或者 Elastic-Job。