一文看懂Java微服務(wù)架構(gòu)，WEB2.0，垂直架構(gòu)，分布式架構(gòu)，微服務(wù)架構(gòu)
Java微服務(wù)架構(gòu)
目錄：
- 了解開發(fā)環(huán)境&生成環(huán)境
- WEB1.0 & WEB2.0
- 垂直架構(gòu)
- 分布式架構(gòu)
- 微服務(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時期，由于帶寬不足，這時的項目大多是內(nèi)容少，用戶量也不多，甚至有一些項目不需要對外開放，對安全性和穩(wěn)定性的要求是不高的，
單體架構(gòu)就足以應(yīng)對
2.2. WEB2.0時期
隨之到來的WEB2.0 實現(xiàn)了ADSL撥號上網(wǎng)，寬帶提速，最高可以達(dá)到8M 用戶量也就不斷增加，一些門戶網(wǎng)站也開始活躍，項目就需要考慮安全性，和穩(wěn)定性。
在基于單體架構(gòu)的設(shè)計中，無法滿足WEB2.0對項目的需求，需要在單體架構(gòu)上搭建集群（多個服務(wù)器），
在搭建集群之后，可以提升項目的穩(wěn)定性，并且并發(fā)量增加，也可以承受住
2.3. 搭建集群后出現(xiàn)的問題
- 用戶的請求到底要發(fā)送到那臺服務(wù)器上，如何才能保證請求平均的分發(fā)給不同的服務(wù)器，從而緩解用戶量增加的壓力
- 編寫項目時，如果用戶登錄成功，將用戶的標(biāo)識存放到的Session中，在搭建集群之后，數(shù)據(jù)共享問題
- 當(dāng)數(shù)據(jù)量特別龐大時，如果還直接去數(shù)據(jù)庫查詢，速度很慢，如何提升查詢效率
- 針對大家在搜索一些數(shù)據(jù)時，where content like '%#{xxx}% ’
2.4. 針對上述問題，如何解決（中間件）
1.Nginx，用來解決用戶請求平均分發(fā)
2.Redis， 用來解決數(shù)據(jù)共享并實現(xiàn)緩存功能
3.ElacticSearch，用來解決搜索數(shù)據(jù)的功能
03. 垂直架構(gòu)
比如項目包含了三個模塊，用戶模塊，商品模塊，訂單模塊，商品模塊。
一般商品瀏覽的商品模塊流量最大，為了防止商品模塊壓力過大，一般直接有效的方法就是搭建集群。
在單體架構(gòu)的集群上去搭建，效果相對比較差。隨著項目的不斷更新，項目中的功能月越來越多，最嚴(yán)重的可能會導(dǎo)致項目無法啟動
關(guān)于單體架構(gòu)中，完美的體驗了低內(nèi)聚，高耦合。（開發(fā)的要求是高內(nèi)聚，低耦合）
為了解決上述的各種問題，更新了垂直架構(gòu)
04. 分布式架構(gòu)
4.1 項目迭代
隨著項目的不斷迭代，新老功能之間需要相互交互，服務(wù)器與服務(wù)器之間需要通信的。
項目一般分為三層的 Controller Service Dao。導(dǎo)致程序變慢的重災(zāi)區(qū)，一般是Service和Dao，在搭建集群時，確實針對三層都搭建集群，效果不是很好。
架構(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ù)的功能上，咱們希望實現(xiàn)異步通訊。
為了實現(xiàn)服務(wù)之間的異步通訊，需要學(xué)習(xí)MQ. MQ-RabbitMQ（消息隊列）
5.2 服務(wù)之間通信地址的維護(hù)
由于服務(wù)越來越多，每個服務(wù)的訪問地址都是不一樣的。協(xié)議：//地址：端口號
由于我們的模塊繁多，并且模塊搭建的集群數(shù)量增加，會導(dǎo)致其他模塊需要維護(hù)各種ip地址等信息，導(dǎo)致項目的維護(hù)性極低，耦合性變高，并且也無法實現(xiàn)負(fù)載均衡的功能
需要使用一個技術(shù)來解決當(dāng)前問題：
Eureka注冊中心幫助我們管理服務(wù)信息 ：實現(xiàn)通訊地址維護(hù)
Robbin可以幫助我們實現(xiàn)服務(wù)之間的負(fù)載均衡 ：實現(xiàn)服務(wù)之間的負(fù)載均衡
5.3 服務(wù)降級
在上述的架構(gòu)中，如果說訂單模塊出現(xiàn)了問題。
只要是涉及到訂單模塊的功能，全部都無法使用。
可能會導(dǎo)致服務(wù)器提供的線程池耗盡，給用戶友好的提示都是無法做到的
為了解決上述的問題，使用Hystrix處理，
Hystrix提供了線程池隔離的方式，避免服務(wù)器線程池耗盡，在一個服務(wù)無法使用時，可以提供斷路器的方式解決
使用Hystrix 幫我們實現(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實現(xiàn)數(shù)據(jù)庫的分庫分表。
06. 微服務(wù)架構(gòu)
雖然已經(jīng)將每個模塊獨立的做開發(fā)，比如商品模塊，壓力最大的是商品的查詢。
在單獨模塊中再次拆分項目的方式就可以稱為微服務(wù)架構(gòu)。微服務(wù)架構(gòu)其實屬于分布式架構(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。
