由于各種原因，好久沒有寫文章了，最近學習了一下架構設計方面的知識，拿來和大家分享一下，
1. 架構是什么
架構是什么，大家能都說出一二，每個人對架構的理解又不盡相同，但對于架構，我們有幾個模糊相似的概念需要知道，分別是：系統與子系統，模塊與組件，框架與架構，來說說這幾種概念的區別，
1. 系統與子系統
1. 系統
維基百科的解釋是：
系統泛指由一群有關聯的個體組成，根據某種規則運作，能完成個別元件不能單獨完成的作業的群體，
抽象成三部分，分別為：關聯（有關聯的個體），規則（根據某種規則運作），能力（完成個別原件不不能單獨完成的作業，新能力），
2. 子系統
根據字面意思，和系統定義相同，只是范圍更小，舉個例子，如淘寶系統，里面有資金，購物，會員系統等，都是一個個子系統
2. 模塊與組件
模塊和組件都是系統的組成部分，但是從不同的角度拆分，有了不同的名稱
1. 模塊
從邏輯單元拆分，得到的就是模塊，主要用與職責分離
2. 組件
從物理單元拆分，得到的是組件，主要用于單元復用
3. 框架與架構
1. 框架
框架更多用于規范，如MVVC，MVP，如實作MVC的Spring框架
2. 架構
架構更多的關注的是系統的結構
2. 系統復雜度
現在，我們在設計架構或系統時，關注的點有很多，安全，可用，性能等，主要總結下來，有6點，分別是：高可用、高性能、可擴展、安全、低成本，規模，接下來對這幾點進行總結，
1. 高可用
對于用戶量大、訪問量高、重要的系統來說，高可用總是必不可少的，高可用分為二部分，分別是計算高可用和存盤高可用，
計算高可用主要是通過增加計算單元，如：多機部署，存盤高可用主要通過備份資料，保證資料一致性，但資料間同步，又是新的問題，不管是增加計算單元，還是資料備份，都未系統帶來了新的復雜性，但這些手段都是用來減少和避免不可用問題，而不是用來解決問題
2. 高性能
高性能復雜度主要體現在2個方面，分別是：單機高性能復雜度，集群高性能度，
1. 單機高性能復雜度
單機提高性能主要體現在：多執行緒，多行程，多執行緒在資料同步問題，多行程在通信方面都會帶來復雜度
2. 集群高性能復雜度
集群復雜度主要體現在：任務分配，任務拆解，任務分配是在集群中，對任務如何分配是一個問題，任務拆解是因為在集群中單節點性能達到最大的時候，只有通過將任務通過過系統處理，來提高性能，
3. 可擴展
可擴展的復雜度主要體現在：預測變化，抽象在一直改變，
只有預測未來業務的變化，才能設計出可擴展的系統，如：系統是否需要分庫分表，現在不需要，隨著業務增長需要嗎?..等等，
對系統抽象出來的代碼也會隨著業務的改變不停的改變，只有進行深層次抽象才能兼容多種業務邏輯，推薦多使用設計模式，設計模式主要用來將變化和穩定分離，
4. 低成本
低成本復雜度主要體現在與高可用相互違背，如：高性能可能需要引入新技術，自研新框架，或增加機器，這些都會帶來成本的增加，但低成本是架構設計考慮點，但不是首要點，
5. 安全
系統安全也是需要考慮，主要分為從架構層面和代碼層面，
架構層面需要考慮架構是否安全，如Ddos攻擊， 代碼層面要考慮功能是否安全，如：Sql注入，RSS
6. 規模
規模的復雜度主要體現在：規模增大，會量變引起質變，如用戶從1W變成10W，100W，就要考慮：高性能，高可用等，
3. 架構設計三原則
架構設計的主要原則體現在三方面，分別是：合適大于業界領先，簡單優于復雜，演化優于一步到位，
1. 合適大于業界領先
在做架構設計的時候，要選擇業務合適的，而并非業界領先的，如：設計一個學生管理系統，看到大公司都是用微服務，那我們就用是用微服務，這樣并不合適，因為學生管理系統在用戶量，功能上等都打不到這樣的量，單機就可以，可能需要考慮資料問題，但這在資料層面解決即可
2. 簡單優于復雜
在進行架構設計的時候，復雜的設計，帶來的邏輯關系，或業務處理關系就會變得更復雜，如：把一個系統拆分成10個系統互動，這樣帶來的問題遠遠大于一個系統，并且復雜的系統排查問題，就需要更多的時間，花費更多的精力
3. 演化優于一步到位
任何事物是符合生物進化論的，架構設計也是如此，一開始我們設計架構，并不能就"一步登天"，主要體現在：
- 人力，資源方便過多的投入會浪費資源
- 業務在不斷變化，并不能完全預測業務
在業務發展的的時候，會有更多的收入，這時候，再花費更多的資源，取其精華，去其糟粕，進行重構，這樣也是合適的，收入和投入是成正比的，避免在一開始，進行假大空設計，到頭來，業務并達不到量，浪費設計，或系統過與龐大，導致系統無法上線等問題，
4. 設計流程
設計流程主要也分了三部分，分別是：識別復雜度，設計備選方案，設計系統詳細方案，
1. 識別復雜度
根據業務的需求，將目前主要的復雜問題羅列出來，根據團隊，業務，技術等綜合情況排序，選出最先需要解決的復雜問題，
2. 設計備選方案
在識別出系統復雜度問題后，我們就需要出設計方案，但是設計方案不能只有一套，需要設計出3-5套，設計方案太少，可能會由于自己的疏忽，見識等問題，未能覆寫復雜問題，設計的太多會影響精力，耗費大量的時間，
設計出的備選方案，需要有較大的區別，而不是一些無關緊要的區別，如：訊息中間件是采用Kafka還是RocketMQ，而不是訊息延遲15s還是30s，
3. 設計出系統的詳細方案
在經過溝通后，選擇出來一套整體看起來可行的方案，這個時候我們就需要給出更多的細節，分步驟，分方式，分系統降低系統的復雜度，在設計詳細方案時，可以找出系統整體能否實施部署等問題，在根據出現問題，做出一些細節問題的修改，
4. 架構設計的目的
以上就是學習架構設計方面的知識啦，經過上面這些觀察，了解，總出來一個架構設計的目的，架構設計的目的主要有兩點：
- 解決系統軟體帶來的復雜度問題
- 應對業務或其他變化帶來的麻煩
在做架構設計的時候，要緊緊貼合架構設計的目的，我們才能設計出夠好的架構，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/287586.html
標籤：其他