一、開發環境&生產環境
1.1 開發環境
平時在寫代碼時，大多都在是Win10/Win7/Mac，這些系統都可以稱呼為開發環境，咱們會為了更高效的開發應用程序，安裝很多很多的軟件，會導致操作系統不安全，穩定性降低。
1.2 生產環境
在生產環境中，操作系統不會采用Win10/Mac，這種操作系統相對不安全，生產環境是要面向全體用戶的，一般會采用專業的操作系統。
大多市面上使用的都是基于Linux的操作系統，當然還有Windows版本的服務器操作系統，Windows 2003 service等等。
由于Linux內核版本完全對外開源，市場占用率大，所以第一步我們要學會如何操作Linux操作系統。
二、Web1.0&Web2.0階段
2.1 Web1.0階段
在Web1.0階段，由于帶寬不足，這時的項目大多是內容少，用戶量也不多，甚至有一些項目不需要對外開放，對安全性和穩定性的要求是不高的。
單體架構就足以應對。
| 單體架構 |
|---|
 image.png
|
2.2 Web2.0階段
隨之到來的Web2.0階段，實現了ADSL撥號上網，寬帶提速，最高可以達到8M，用戶量也就不斷增加，一些門戶網站也開始活躍，項目就需要考慮安全性和穩定性。
在基于上面的單體架構圖中，無法滿足Web2.0對項目的需求。
在單體架構的基礎上去搭建集群。
在搭建集群之后，可以提升項目的穩定性，并且并發能力增強，還可以避免單點故障。
| 單體架構搭建集群 |
|---|
 image.png
|
2.3 搭建集群后發生的問題.
- 用戶的請求到底要發送到哪臺服務器上。如何保證請求平均的分發給不同的服務器，從而緩解用戶量增加的壓力。
- 編寫項目時，如果用戶登錄成功了，將用戶的標識放到Session域中，在搭建集群之后，數據共享問題。
- 當數據量特別龐大時，如果還直接去數據庫查詢，速度很慢，如何提升查詢效率。
- 針對大家在搜索一些數據時，where content like '%#{xxx}%'
- 等等……
為了解決上述的問題，需要使用到三門技術。
Nginx - 解決用戶請求平均分發。
Redis - 解決數據共享并實現緩存功能。
ElasticSearch - 解決搜索數據的功能。
| 插入中間件 |
|---|
 image.png
|
三、垂直架構
比如項目包含了三個模塊，用戶模塊，商品模塊，訂單模塊。如果商品模塊壓過大，一般最直接有效的方式就是搭建集群。在單體架構的集群上去搭建，效果相對比較差。
隨著項目的不斷更新，項目中的功能越來越多，最嚴重可能會導致項目無法啟動。
關于單體架構中，完美的體現了低內聚，高耦合，避開了開發的準則。
為了解決上述的各種問題，演進出了垂直架構。
| 垂直架構圖 |
|---|
 image.png
|
四、分布式架構
隨著項目的不斷迭代，新老功能之間需要相互交互，服務器和服務器之間是需要通訊的。
項目一般是分為三層的，Controller，Service，Dao。 導致程序變慢的重災區，一般是Service和Dao，在搭建集群時，確實針對三層都搭建集群，效果不是很好。
架構從垂直架構演變到了分布式架構。
分布式架構落地的技術，國內常用的方式有兩種
Dubbo RPC（通訊方式）
SpringCloud HTTP（通訊方式）
| 分布式架構圖 |
|---|
 image.png
|
五、分布式架構常見問題
5.1 服務之間的異步通訊
使用分布式架構之后，服務之間的通訊都是同步的。在一些不是核心業務的功能上，咱們希望可以實現異步通訊，以加快處理速度，可以更快的給用戶響應。
為了實現服務之間的異步通訊，需要使用RabbitMQ等消息隊列中間件。
| 分布式架構下，實現異步通訊 |
|---|
 image.png
|
5.2 服務之間通訊地址的維護.
由于服務越來越多，每個服務的訪問地址都是一樣的：協議://地址:端口號/路徑
由于模塊繁多，并且模塊搭建的集群數量增加，會導致其他模塊需要維護各種ip地址等信息，導致項目的維護性極低，耦合性變高，并且實現負載均衡也變得很麻煩。
需要使用以下技術來解決當前問題:
Eureka注冊中心幫助我們管理服務信息。
Robbin可以幫我們實現服務之間的負載均衡。
| Eureka實現通訊地址維護，Robbin實現服務之間的負載均衡 |
|---|
 image.png
|
5.3 服務降級
在上述的架構中，如果說訂單模塊出現了問題，只要是涉及到訂單模塊的功能，全部都無法使用，甚至可能會導致服務器提供的線程池耗盡。給用戶友好的提示都是無法做到的。
為了解決上述的問題，使用Hystrix處理：
Hystrix提供了線程池隔離的方式，避免服務器線程池耗盡，在一個服務無法使用時，還提供斷路器的方式來處理問題服務，從而執行降級方法，返回托底數據。
| 使用Hystrix幫我們提供斷路器和隔離，并最終服務降級 |
|---|
 image.png
|
5.4 海量數據
海量數據會導致數據庫無法存儲全部的內容，即便數據庫可以存儲海量的數據，在查詢數據時，數據庫的響應時極其緩慢的，在用戶高并發的情況下，數據庫也時無法承受住的。
為了解決上述的問題，可以基于MyCat實現數據庫的分庫分表。
| 基于MyCat實現分庫分表 |
|---|
 image.png
|
六、微服務架構
6.1 微服務架構
雖然已經將每個模塊獨立的做開發，比如商品模塊，壓力最大的是商品的查詢。
在單獨模塊中再次拆分項目的方式就可以稱之為微服務架構，微服務架構也是分布式架構。
| 微服務架構，在分布式架構的基礎上再次拆分 |
|---|
 image.png
|
6.2 模塊過多，運維成本增加
為了解決模塊過多，運維成本增加的問題，采用Docker容器化技術來幫助我們管理各個模塊的部署，還可以通過CI、CD持續集成，持續交付，持續部署。
而且后期在學習的時候，也需要大量的軟件，可以使用Docker來幫助我們快速的安裝軟件。
| Docker容器化技術 |
|---|
 image.png
|
6.3 分布式架構下的其他問題
分布式架構幫助我們解決了很多的問題，但是隨之也帶來了很多問題
6.3.1 分布式事務
最傳統的操作事務的方式，是通過Connection鏈接對象的方式操作，Spring也提供了聲明式事務的操作。
為了解決事務的問題，后續會使用到RabbitMQ或者LCN等方式來解決。
6.3.2 分布式鎖
傳統的鎖方式，synchronized | Lock鎖，在分布式環境下，傳統的鎖是沒有效果的。
為了解決鎖的問題，后續會使用到Redis或者Zookeeper來解決。
6.3.3 分布式任務
在傳統的定時任務下，由于分布式環境的問題，可能會造成任務重復執行，一個比較大的任務，需要可以拆分。
為了解決這個問題，后續會使用到Redis + Quartz或者Elastic-Job來解決。
