架構目的和指標
架構目的：
架構設計的主要目的是爲了解決軟件系統複雜度帶來的問題，是用最小的人力成本來滿足需求的開發和響應需求的變化，用最小的運行成本來保障軟件的運行。讓軟件達到“高內聚、松耦合”，從而使軟件具有:
- 易擴展——易於增加新的功能
- 更強壯——不容易被粗心的程序員破壞
- 可移植——能夠在多樣的環境下運行
- 更簡單——容易理解、容易維護
設計目標:
- 可擴展性(Scalable)
- 可靠性(Reliable)，支持灰度發佈，異地容錯
- 可伸縮 (Extensible)，支持水平擴展和垂直增強
- 可維護性(Maintainable)，一是排除現有的錯誤，二是新需求可反映到現有系統中去。
- 安全性(Secure)
- 可定製化(Customizable)
- 客戶體驗(Customer Experience)，必須易於使用。
架構的方法論
面向對象
設計原則-SOLID
設計原則-SOLID
設計模式的六大原則有：
- Single Responsibility Principle：單一職責原則
- Open Closed Principle：開閉原則
- Liskov Substitution Principle：里氏替換原則
- Law of Demeter：迪米特法則
- Interface Segregation Principle：接口隔離原則
- Dependence Inversion Principle：依賴倒置原則
把這六個原則的首字母聯合起來（ L 算做一個）就是 SOLID （solid，穩定的），其代表的含義就是這六個原則結合使用的好處：建立穩定、靈活、健壯的設計。
單一責任原則：
當需要修改某個類的時候原因有且只有一個（THERE SHOULD NEVER BE MORE THAN ONE REASON FOR A CLASS TO CHANGE）。換句話說就是讓一個類只做一種類型責任，當這個類需要承擔其他類型的責任的時候，就需要分解這個類。
開放封閉原則：
軟件實體應該是可擴展，而不可修改的。也就是說，對擴展是開放的，而對修改是封閉的。這個原則是諸多面向對象編程原則中最抽象、最難理解的一個。
里氏替換原則：
當一個子類的實例應該能夠替換任何其他類的實例時，它們之間才具有is-A關係。
依賴倒置原則：
- 高層模塊不應該依賴於低層模塊，二者都應該依賴於抽象
- 抽象不應該依賴於細節，細節應該依賴於抽象
接口分離原則：
不能強迫用戶去依賴那些他們不使用的接口。換句話說，使用多個專門的接口比使用單一的總接口總要好。
設計模式類型
設計模式類型
CAP定理
CAP是Consistency、Availablity和Partition-tolerance的縮寫。分別是指：
- 一致性（Consistency）：每次讀操作都能保證返回的是最新數據；
- 可用性（Availablity）：任何一個沒有發生故障的節點，會在合理的時間內返回一個正常的結果；
- 分區容忍性（Partition-tolerance）：當節點間出現網絡分區，照樣可以提供服務。
1.一致性：一致性是指數據在多個副本之間是否能夠保持一致的特性。假如現在的多個節點中的數據是保持一致的，當執行完某一個更新操作之後，應當要保證系統的數據然後處於一致性的狀態。對於一個將數據副本分佈在不同的分佈式節點上，如果對第一個結點的數據進行了更新的操作，並且更新成功之後，卻沒有讓第二個節點得到相應的更新。當外部系統再去調用第二個節點時，獲取到的依然是原始的數據，這就是分佈式數據不一致的情況了。在分佈式系統中，如果能夠做到針對一個數據項更新操作執行成功之後，所有的用戶都可以讀取到最新的值，那麼這樣的系統就被認爲是具有強一致性的。
2.可用性：可用性是指系統提供的服務必須一直處於可用的狀態，對於用戶的每一個操作請求總是能夠在有限的時間內，返回結果。有限的時間內：對於用戶的一個操作請求，系統必須能夠在指定的時間內返回對應的結果。如果超過了這個時間，就認爲系統是不可用的。返回結果是可用性的一個非常重要的指標，它要求系統在完成對用戶請求的處理後，返回一個正常的響應結果。正常的響應結果包含成功或失敗，而不是一個讓用戶迷惑的結果。
3.分區容錯性：分佈式系統在遇到任何網絡分區故障的時候，仍然需要對外提供滿足一致性和可用性的服務。
CAP
一個分佈式系統既然不能同時滿足上述的三個需求，因此在進行對cap定理的應用時，我們就需要去拋棄一項。
①選擇CA
放棄分區容錯性，比較簡單的方式就是把所有的數據都放在一個分佈式節點上。那不就又成爲了單機應用了嗎？
②選擇CP
放棄可用性，一旦出現網絡故障，受到影響的服務需要再等待一定時間，因爲系統處於不可用的狀態。
③選擇AP
放棄一致性，這裏所指的一致性是強一致性，但是確保最終一致性。是很多分佈式系統的選擇。
小結：從cap的定理可以看出，分區容錯性是一個最基本的要求，因爲既然是一個分佈式系統，必然要部署到兩個或兩個以上的節點上，否則，就不是分佈式系統，因此我們只能在一致性和可用性尋求平衡。
BASE理論
BASE理論
base是Basically Available（基本可用）、Soft state（軟狀態）和Eventually consistent（最終一致性）三個短語的簡寫。base是對cap中一致性和可用性的權衡的結果。是根據cao理論演變而來，核心思想是即使無法做到強一致性，但是每個應用根據自身的業務特點，採用適當的方式來使系統達到最終與執行。
①基本可用
基本可用指的是分佈式系統出現了不可預知故障的時候，允許損失部分可用性。響應時間合理延長，功能上適當做服務降級。
②弱狀態
弱狀態指的是允許系統中的數據存在中間狀態，並認爲該中間狀態不會影響系統的整體可用性，即允許在各個節點數據同步時存在延時。
③最終一致性
最終一致性強調的是系統中所有的數據副本，在經過一段時間的同步之後，最終能夠達到一個一致的狀態。因此，最終一致性的本質是需要系統保證數據最終能夠達到一致。而不需要實時保證系統數據的一致性。
AKF架構原則
AFK立方體
X軸擴展
所謂X軸代表把同樣的工作或數據鏡像分配給多個實體。換句話說就是複製服務然後負載均衡。這也是最簡單最基礎的擴展。
示例：我有個網站，一開始部署在服務器A上對外服務，隨着訪問人數增加，一臺服務器的性能無法支持，於是我又在服務器上B上同樣部署了網站，然後在前面部署了Apache或者Nginx來分流訪問，這就是最基本的X軸擴展。
Y軸擴展
針對X軸擴展產生的問題，我們需要將大型服務進行拆解，把分割的工作指責和數據分配給多個實體這也就是Y軸擴展。也是微服務理論誕生的基礎。
示例：我把網站的註冊登錄模塊，首頁新聞展示模塊，後臺維護模塊拆成了多個微服務進行部署維護。 X軸擴展和Y軸擴展並不矛盾，是可以結合的，比如我發現新聞展示模塊壓力很大，我可以對新聞展示模塊進行X軸擴展，部署多個鏡像來分擔壓力。
Z軸擴展
Z軸代表按照客戶、客戶的需要、位置或者價值分割或分配工作職責。一般在超大型系統中，架構設計就會面臨Z軸擴展的需求。
示例：網站一開始建設在上海數據中心，面向全國服務。隨着公司業務的增長，西安的客戶大量增加，但是訪問上海數據中心速度很慢，所以公司考慮在西安建立數據中心來應對用戶訪問，這就是Z軸擴展。
康威定律
- 第一定律:企業溝通方式會通過系統設計表達出來
- 第二定律:再多的時間也沒辦法讓任務完美至極，但總有時間能將它完成
- 第三定律:線型系統和線型組織架構間有潛在的異質同態特性
- 第四定律:大系統比小系統更適用於任務分解
架構思維
架構思維圖
架構的變遷
架構的變遷圖
單體架構：最簡單架構風格所有代碼在一個項目中，團隊所有成員，可隨時任意修改一段代碼或增加一些新的代碼。
單體架構圖
Web應用程序發展的早期，大部分web工程師將所有的功能模塊打包到一起並放在一 個web容器中運行，所有功能模塊使用同一個數據庫。
特點:
1、所有的功能集成在一個項目工程中。
2、所有的功能打在一個war包部署到服務器。
3、通過部署應用集羣和數據庫集羣來提高系統的性能。
優點:
1、項目架構簡單，前期開發成本低，週期短，小型項目的首選。
2、開發效率高，模塊之間交互採用本地方法調用。
3、容易部署，運維成本小，直接打包到web容器即可運行。
4、容易測試，無依賴，在本地就可以啓動調試完整的系統。
缺點:
1、全部功能集成在一個工程中，對於大型項目不易擴展及維護。
2、版本迭代速度逐漸變慢，修改就要將整個應用全部編譯。
3、無法針對某業務按需伸縮。
垂直架構：分層是典型的對復 雜系統進行結構化 思考和抽象聚合的 通用方法，也符合金字塔原理。MVC是一個常見的三層架構模式。
垂直架構圖
針對單體架構的不足，爲了適應大型項目的開發需求，許多公司將一個單體系統按業 務垂直拆分爲若干系統，系統之間通過網絡交互來完成用戶的業務處理，每個系統可 分佈式部署，這種架構稱爲分佈式架構。
特點:
1、按業務垂直拆分成一個一個的單體系統，此架構也稱爲垂直架構。
2、系統與系統之間的存在數據冗餘，耦合性較大，如上圖中三個項目都存在客戶信息。
3、系統之間的接口多爲實現數據同步，如上圖中三個項目要同步客戶信息。
優點:
1、通過垂直拆分，每個子系統變成小型系統，功能簡單，前期開發成本低，週期短。
2、每個子系統可按需伸縮。
3、每個子系統可採用不同的技術。
缺點:
1、子系統之間存在數據冗餘、功能冗餘，耦合性高。
2、按需伸縮粒度不夠，對同一個子系統中的不同的業務無法實現，比如訂單管理和用戶管理。
SOA架構：面向服務架構是一種建設企業IT生態系統的架構指導思想。SOA關注服務，服務是最基本的業務功能單元， 服務之間通過ESB通信。
SOA架構圖
SOA是一種面向服務的架構，基於分佈式架構，它將不同業務功能按服務進行拆分， 並通過這些服務之間定義良好的接口和協議聯繫起來。
特點:
1、基於SOA的架構思想，將重複公用的功能抽取爲組件，以服務的方式向各個系統提供服務。
2、各個系統與服務之間採用webservice、rpc等方式進行通信。
3、ESB企業服務總線作爲系統與服務之間通信的橋樑。
優點:
1、將重複的功能抽取爲服務，提高開發效率，提高系統的可重用性、可維護性。
2、可以針對不同服務的特點按需伸縮。
3、採用ESB減少系統中的接口耦合。
缺點:
1、系統與服務的界限模糊，會導致抽取的服務的粒度過大，系統與服務之間耦合性高。
2、雖然使用了ESB，但是服務的接口協議不固定，種類繁多，不利於系統維護。
微服務架構：微服務架構風格以實現一組小服務的方式來開發一個獨立的應用系統方法。其中每個小服務運行在獨立進程。服務間通過ApiGW機制通信。
微服務架構圖
基於SOA架構的思想，爲了滿足移動互聯網對大型項目及多客戶端的需求，對服務層進行細粒度的拆分，所拆分的每個服務只完成某個特定的業務功能，比如訂單服務只實現訂單相關的業務，用戶服務實現用戶管理相關的業務等等，服務的粒度很小，所以稱爲微服務架構。
特點:
1、服務層按業務拆分爲一個一個的微服務。
2、微服務的職責單一。
3、微服務之間採用RESTful、RPC等輕量級協議傳輸。
4、有利於採用前後端分離架構。
優點:
1、服務拆分粒度更細，有利於資源重複利用，提高開發效率。
2、可以更加精準的制定每個服務的優化方案，按需伸縮。
3、適用於互聯網時代，產品迭代週期更短。
缺點:
1、開發的複雜性增加，因爲一個業務流程需要多個微服務通過網絡交互來完成。
2、微服務過多，服務治理成本高，不利於系統維護。
微服務架構2.0-Service Mesh
Service Mesh
優點:
1、屏蔽分佈式系統通信的複雜性(負載均衡、服務發現、認證授權、監控追蹤、流量控 制等等)，服務只用關注業務邏輯。
2、真正的與語言無關，服務可以用任何語言編寫，只需和Service Mesh通信即可。
3、對應用透明，Service Mesh組件可以單獨升級。
缺點:
1、邊緣網絡，IoT場景:資源非常有限，不適合啓動太多Sidecar。
2、FaaS場景:應用自身足夠輕量，甚至比Sidecar還要輕量。
3、Serverless場景:ScaletoZero時，對冷啓動速度有嚴格要求，Sidecar的啓動和初始化可能拖累應用啓動速度。