一文看懂Java微服務架構，WEB2.0，垂直架構，分布式架構，微服務架構
Java微服務架構
目錄：
- 了解開發環境&生成環境
- WEB1.0 & WEB2.0
- 垂直架構
- 分布式架構
- 微服務架構
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. 搭建集群后出現的問題
- 用戶的請求到底要發送到那臺服務器上，如何才能保證請求平均的分發給不同的服務器，從而緩解用戶量增加的壓力
- 編寫項目時，如果用戶登錄成功，將用戶的標識存放到的Session中，在搭建集群之后，數據共享問題
- 當數據量特別龐大時，如果還直接去數據庫查詢，速度很慢，如何提升查詢效率
- 針對大家在搜索一些數據時，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。
