簡介
web1.0時代
web2.0時代
互聯網時代 互聯網+ --》智慧城市。 2012年提出。
雲計算+大數據時代
背景
隨着互聯網的發展，網站應用的規模不斷擴大，常規的垂直應用架構已無法應對，分佈式服務架構以及流動計算架構勢在必行，亟需一個治理系統確保架構有條不紊的演進。
1、第一時期
單一應用架構
all in one(所有的模塊在一起，技術也不分層)
網站的初期，也認爲互聯網發展的最早時期。會在單機部署上所有的應用程序和軟件。
所有的代碼都是寫在JSP裏面，所有的代碼都寫在一起。這種方式稱爲all in one。
特點：
1、不具備代碼的可維護性。
2、容錯性差。
因爲我們所有的代碼都寫在JSP頁裏。當用戶或某些原因發生異常。（1、用戶直接看到異常錯誤信息。2、這個錯誤會導致服務器宕機）
容錯性，是指軟件檢測應用程序所運行的軟件或硬件中發生的錯誤並從錯誤中恢復的能力，通常可以從系統的可靠性、可用性、可測性等幾個方面來衡量。
單體地獄。:只需一個應用，將所有功能都部署在一起，以減少部署節點和成本。
2 第一時期後階段
解決方案:
1、分層開發（提高維護性）【解決容錯性】
2、MVC架構（Web應用程序的設計模式）
3、服務器的分離部署
特點：
1、MVC分層開發（解決容錯性問題）
2、數據庫和項目部署分離
問題：
隨着用戶的訪問量持續增加，單臺應用服務器已經無法滿足需求。
解決方案：
集羣。
3 可能會產生的幾個問題：
1.1. 高可用
“高可用性”（High Availability）通常來描述一個系統經過專門的設計，從而減少停工時間，而保持其服務的高度可用性。(一直都能用)
1.2. 高併發
高併發（High Concurrency）是互聯網分佈式系統架構設計中必須考慮的因素之一，它通常是指，通過設計保證系統能夠同時並行處理很多請求。
高併發相關常用的一些指標有響應時間（Response Time），吞吐量（Throughput），每秒查詢率QPS（Query Per Second），併發用戶數等。
響應時間：系統對請求做出響應的時間。例如系統處理一個HTTP請求需要200ms，這個200ms就是系統的響應時間。
吞吐量：單位時間內處理的請求數量。
QPS：每秒響應請求數。在互聯網領域，這個指標和吞吐量區分的沒有這麼明顯。
併發用戶數：同時承載正常使用系統功能的用戶數量。例如一個即時通訊系統，同時在線量一定程度上代表了系統的併發用戶數。
1.2.1. 提升系統的併發能力
提高系統併發能力的方式，方法論上主要有兩種：垂直擴展（Scale Up）與水平擴展（Scale Out）。
1. 垂直擴展
垂直擴展：提升單機處理能力。垂直擴展的方式又有兩種：
（1）增強單機硬件性能，例如：增加CPU核數如32核，升級更好的網卡如萬兆，升級更好的硬盤如SSD，擴充硬盤容量如2T，擴充系統內存如128G；
（2）提升單機架構性能，例如：使用Cache來減少IO次數，使用異步來增加單服務吞吐量，使用無鎖數據結構來減少響應時間；
在互聯網業務發展非常迅猛的早期，如果預算不是問題，強烈建議使用“增強單機硬件性能”的方式提升系統併發能力，因爲這個階段，公司的戰略往往是發展業務搶時間，而“增強單機硬件性能”往往是最快的方法。
總結：不管是提升單機硬件性能，還是提升單機架構性能，都有一個致命的不足：單機性能總是有極限的。所以互聯網分佈式架構設計高併發終極解決方案還是水平擴展。
2. 水平擴展
水平擴展：只要增加服務器數量，就能線性擴充系統性能。水平擴展對系統架構設計是有要求的，難點在於：如何在架構各層進行可水平擴展的設計，
可擴展性。
1.3. 高性能
高性能（High Performance）就是指程序處理速度快，所佔內存少，cpu低
4、集羣操作
集羣：同一個業務，部署在多個服務器上。
特點：
1、項目採用多臺服務器(集羣）部署
優點：
支持高併發。
支持高可用。
問題1： Session如何共享？
答： Redlis Cluster集羣方案
問題2： 這些集羣的服務器，用戶的請求該往哪裏進行轉發？
答： 用nginx服務器來完成分發請求。實現負載均衡策略機制。
注意：很多IT公司用的都是這種架構需求
數據庫壓力變大
我們能過集羣方案nginx+tomcat將應用層的性能進行有效的提升。但是數據庫的負載奪力慢慢增加。怎麼來搞高數據庫層面的訪問壓力（負載）？
解決方案：
讀寫分離
讀寫分離：主從數據庫之間進行數據同步。master負載增刪改操作。 slave負載讀操作。
mysql本身就提供了master-slave的方式完成主從複製功能。
使用搜索引擎緩解數據庫的訪問壓力+能力
數據庫做讀庫的情況下，數據庫本身對模糊查詢的功能支持不是特別優秀，像電商類的網站，搜索是非常核心的功能模塊。即使做了讀寫分離。這個問題也不能有效解決電商網站查詢（分詞技術）等。針對於該問題，有必要引入搜索引擎技術。
目前非常主流的搜索引擎技術：
solr elasticsearch whoosh
引入緩存機制減輕數據庫的訪問壓力
隨着訪問量的持續增加，數據庫的訪問壓力變的越來越大（雖然做了主從複製）。對於這些熱點數據（用戶訪問頻繁的信息），如果每都到數據庫中進行查詢。（很多通用查詢的功能）。
放在內存中又不特別合適。（手機登錄驗證碼操作、爲了IP限制頻繁訪問服務器...) 嘗試使用Redis.
數據庫的水平/垂直拆分。
垂直擴展 能力終歸還是有限的。
單個表： 1000萬--》1個億數據 （單個表的數據能力終歸還是有限的）
表：垂直拆分。
id ,name,age,bire..tel...remark....
熱數據/冷數據 --》垂直拆分方案。
表：水平拆分。
按照：時間、地區、（按照業務邏輯進行拆分）。
分庫分表：
採用第三方數據庫中間件：mycat sharding-jdbc drds(阿里)
當前狀態特點：
通過設計保證高可用、高併發。
（不斷的對服務器進行擴容...)
產生的問題：
問題1：服務器價錢？（服務器維護成本、人工維護）？
問題2：可維護性差
問題3：可擴展性差
問題4：協同開發不方便(大家都去改相同的業務代碼。易發生代碼錯誤/衝突)
問題5：單體架構（隨着業務的不斷增加，代碼會變得越來越多）。導致服務部署時，文件變的越來越大
5、第二時期
垂直應用架構
當訪問量逐漸增大，單一應用增加機器帶來的加速度越來越小，將應用拆成互不相干的幾個應用，以提升效率。此時，用於加速前端頁面開發的Web框架(MVC)是關鍵。
理解：（植被垂直分佈）
水平拆分：
將一個大的單體應用，拆分成多個小應用。
橫着拆：
exam:
拆分完成對拆分手的項目進行聚合，提出概念父工程（ssm_parent）
exam-parent //父工程概述（聚合）
父工程目錄下僅有pom.xml，故不需要進行編碼。
1、 項目需要的依賴信息、在父工程中定義。子模塊繼承。
2、 將各個子模塊聚合到一起。
exam-commons.jar
exam-pojo.jar //應用模塊 java bean類
exam-mapper.jar//應用模塊 持久層類和接口
exam-service.jar// 業務邏輯層類和接口
exam-web //web層
1、eclipse爲例
2、Idea爲例
利用MAVEN做的模塊的拆分和聚合。
解決問題：
1、模塊複用
2、 解決服務器部署內容變小。
閒置了大量的服務器。（如果用戶對某個層訪問量過大時，只需要將該層業務多部署些服務即可。）
（阿里雲、百度雲、騰訊雲、新浪雲、京東雲）
在沒有出現雲之前：
一些公司需不需要購買服務器+需要運維人員對服務器進行維護。
行業：大量Linux運維工程師
企業：服務器拖管企業
垂直拆分:
將一個大的應用拆成互不相干的幾個小應用。每個應用是獨立的Web項目部署。
解決問題：
問題1：維護性（如果想做需求變更。只需要調整某個應用模塊即可）
問題2：功能擴展（隨着業務的不斷增加，只需要創建新的應用即可）
問題3：協同開發方便(不同的團隊修改不同的業務)
問題4：部署內容大小/性能擴展(只需要對訪問量大的服務器多部署幾臺)
問題1：（客戶對頁面的要求變的越來越高。修改會越來越頻繁）頁面的變化大。每一個應用從頭到尾都是完整的，如果客戶要對頁面進行修改，這個應用服務需要重新部署？
問題2：隨着業務的不斷增加，應用模塊越來越多，各個模塊之間一定需要業務進行交互？
6、第三時期
分佈式服務架構
當垂直應用越來越多，應用之間交互不可避免，將核心業務抽取出來，作爲獨立的服務，逐漸形成穩定的服務中心，
使前端應用能更快速的響應多變的市場需求。此時，用於提高業務複用及整合的分佈式服務框架(RPC)是關鍵。
分佈式：將一個業務拆分成多個子業務，部署在不同的服務器上。
針對如上情況，
問題1：（客戶對頁面的要求變的越來越高。修改會越來越頻繁）頁面的變化大。每一個應用從頭到尾都是完整的，如果客戶要對頁面進行修改，這個應用服務需要重新部署？
答：界面+業務邏輯實現分離（前後端分離開發）。【橫着拆 水平拆分】
問題2：隨着業務的不斷增加，應用模塊越來越多，各個模塊之間一定需要業務進行交互？
分析 ：
以前如果在同一臺服務器上，（模塊的依賴進程來完成調用）
通過如上圖，發現，不同的應用部署在不同的服務器上。服務和服務之間調用【進程間調用】
答：
解決方案：RPC/HTTP/HttpClient
RPC（Remote Procedure Call）—遠程過程調用，它是一種通過網絡從遠程計算機程序上請求服務，而不需要了解底層網絡技術的協議。
架構的改變一定會帶來一些新的技術和新的問題
分佈式事務、分佈式鎖、分佈Session問題。分佈式日誌管理。
問題1：
當服務越來越多。服務和服務之間的調用 會變的非常混亂。
問題2：
當服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現
假如：會議管理功能訪問量小，但部署了100臺服務器。 支付管理功能訪問量大，也部署了20臺服務器。
7、第四時期
流動計算架構
當服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增加一個調度中心基於訪問壓力實時管理集羣容量，提高集羣利用率。此時，用於提高機器利用率的資源調度和治理中心(SOA)是關鍵。
SOA(面向服務架構)
功能：解決多服務混亂問題、
服務治理中間件：（dubbo/SpringCloud)
基於訪問壓力實時管理集羣容量，提高集羣利用率。提高機器利用率的資源調度和治理中心。
示例：
以一個公司爲例：有基層員工， 有管理層， 有老闆。
最初大家都聽老闆指揮，誰幹什麼誰幹什麼，根據需要，你可能今天干A事情，明天干B事情，後來人越來越多了，事情也越來越多了，做事情的效率越來越多，管理也很混亂，
就開始做部門劃分（服務化），專門部門做專門事情的，IT部門只做研發，人事部門只做招聘； 這個時候就無法避免的發生跨部門協作（服務器調用）， 但是你怎麼知道有這樣一個部門可以做這個事情呢，就要依賴行政部門（註冊中心），新成立的部門要在行政哪裏做一個備案（服務註冊），然後公佈一下，讓其他部門知道了（服務發佈），大家就可以在新的工作秩序裏面嗨皮的上班了，這個時候依然是在公司的組織架構中運轉；
8、第五時期
微服務架構：
微服務：單體應用拆分成互不相干的小應用。每一個小的應用稱爲微服務。
問題1： 構建單體應用時，(SSM web.xml、需要相應的所有jar、相應的配置文件)
當拆分構建多個微服務時（需要進行大量的項目【服務】創建）。
答：SpringBoot
SprintBoot出現的目的：就是爲了簡化代碼的初始化構建和開發配置。
總結：
架構的改變一定會帶來一些新的技術和新的問題
優點：
1、服務化的拆分粒度變的更細。（服務的複用性強），提高開發效率。
2、可根據需求自定義優化方案。（選擇最新的技術）
3、適合於互聯網項目。（產品迭代週期短。開發效率快）
缺點：
1、微服務過多，服務的管理（治理）成本高。
2、不利於服務的部署不方便。(Docker /k8s)
3、技術難點也在增加。（分佈式事務、分佈式鎖、分佈式Session、分佈式日誌）
4、對團隊的技術能力要求高。（dubbo/springcloud)