.NET 雲原生架構師訓練營（模塊一 架構師與雲原生）--學習筆記

目錄

• 什麼是軟件架構
• 軟件架構的基本思路
• 單體向分佈式演進、雲原生、技術中臺

1.1 什麼是軟件架構

1.1.1 什麼是架構？

Software architecture = {Elements, Forms, Rationale/Constraints}

元素、形式/模式、基本原理和限制

爲何須要軟件架構？

軟件架構的終極目標是用最小的人力成原本知足構建和維護系統的需求

一個軟件架構的優劣，能夠用它知足用戶需求的成原本衡量。若是該成本很低，而且在系統的整個生命週期內一直都維持這樣的低成本，那麼這個系統的設計就是優良的，若是該系統的每次發佈都會提高下一次變動的成本，那麼這個設計就是很差的，就這麼簡單。

--架構整潔之道

產品經理

• 需求分析
• 需求設計
• 項目管理
• 產品運營

1.1.2 什麼是架構師？

系統的維度

負責總體系統的架構設計，主要是基礎服務和各系統間的協調上，着眼全局不太注重某個應用自己架構，好比關注服務器負載，可靠性，伸縮，擴展，數據庫切分，緩存應用等方法的基礎架構設計

應用程序的維度

負責某個應用的技術架構，主要偏業務系統，關注理解業務，梳理模型，設計模式，接口，數據交互等方面

業務流程的維度

關注某一個行業、業務的領域分析，獲取領域模型，最終得到系統的模型

也能夠叫業務領域專家、行業專家、產品諮詢師、資深顧問

下降成本

經過設計和實現優良的軟件架構來持續下降軟件的構建和維護成本

軟件架構這項工做的實質就是規劃如何將系統拆分紅組件，並安排好組件之間的排列關係以及組件之間互相通訊的方式

如何下降成本？

• 低成本維護（容易被改動和理解）
• 軟件可複用
• 輕鬆部署

設計原則會給咱們答案

軟件架構師的目標是建立一種系統形態，該形態會以策略爲最基本的元素，並讓細節與策略脫離關係，一個優秀的軟件架構師應該致力於最大化可選項數量

職能

1. 負責公司系統架構設計、研發工做
2. 承擔從業務向技術轉換的橋樑做用
3. 協做項目經理制定項目計劃和控制項目進度
4. 負責輔助並指導 SA 開展設計工做
5. 負責組織技術研究和攻關工做
6. 負責組織和管理公司內部的技術培訓工做
7. 負責組織及帶領公司內部員工研究與項目相關的新技術
8. 管理技術支撐團隊並給項目、產品開發實施團隊提供技術保障
9. 理解系統的業務需求，制定系統的總體框架（包括：技術框架和業務框架）
10. 對系統框架相關技術和業務進行培訓，指導開發人員開發
11. 解決系統開發、運行中出現的各類問題
12. 對系統的重用、擴展、安全、性能、伸縮性、簡潔等作系統級的把握

軟件週期內，標準組織架構下的各個職位的分工

• CEO
• CTO/CIO
• 產品總監/技術總監/架構師 Architect Director
• 資深開發/Manager
• 高級開發/Leader

1.1.3 軟件架構分類

從架構師的工做內容上來劃分能夠分爲三類：

• 系統架構師
• 應用架構師
• 業務架構師

系統架構師/基礎架構師

從系統的維度，負責總體系統的架構設計，主要是基礎服務和各系統間協調上，着眼全局不太注重某個應用自己架構，好比關注服務器負載，可靠性，伸縮，擴展，數據庫切分，緩存應用等方面的基礎架構設計。

應用架構師

從應用程序的維度，負責某個應用的技術架構，主要偏業務系統，關注理解業務，梳理模型，設計模式，接口，數據交互等方面。

業務架構師

從業務流程的維度，關注某一個行業、業務的領域分析，獲取領域模型，最終得到系統的模型。也能夠叫業務領域專家、行業專家、產品諮詢師、資深顧問。

基礎架構、前端架構、後端架構是從職責上的分類。

.NET雲原生架構師訓練營講什麼，怎麼講，講多久

https://mp.weixin.qq.com/s/JWOIScGrX0Hszz4uqdA6qw

1.1.4 架構風格

• 分層架構
• 微核架構/六邊形架構/簡潔架構
• 事件驅動架構
• 微服務架構
• 雲架構

軟件架構入門

http://www.ruanyifeng.com/blog/2016/09/software-architecture.html

1.2 軟件架構的基本思路

1.2.1 如何理解需求

軟件需求（第3版）

https://book.douban.com/subject/26307910/

需求分類

1.2.2 非功能性需求

• 觀感需求
• 易用性：性能/可用性
• 可擴展性
• 可維護性

1.2.3 4+1模型

• 場景視圖
• 邏輯視圖
• 開發視圖
• 處理視圖
• 物理視圖

1.2.4 場景視圖

• 用戶能夠開設一個訓練營成爲營長
• 營長能夠制定訓練營學生的任務和計劃，能夠快速利用到其餘訓練營
• 營長能夠邀請其餘用戶加入訓練營成爲學員
• 營長能夠對學員進行分組
• 營長能夠添加指定學員成爲助教並指定到分組
• 學員能夠接受邀請加入訓練營成爲學員
• 學員加入訓練營以後能夠完成訓練營內的任務
• 學員能夠對訓練營內的指定問題進行提問
• 學員能夠查看本身的學員檔案
• 營長/助教能夠回答學員提出的問題
• 營長/助教能夠對學員完成的任務進行考評打分

1.2.5 邏輯視圖

面向對象分解

用來支持功能性需求、系統應該被拆分爲哪些問題域、對象

1.2.6 開發視圖

關注軟件模塊組織和開發環境上、從組件、模塊、子系統的組織和分層

每一層爲上層提供有限的良好定義的接口供調用

• 團隊結構
• 開發流程
• 測試計劃
• 項目協做工具
• Road Map 發佈計劃

1.2.7 處理視圖

關注進程、線程、對象等運行的概念，以及相關的併發、同步、通訊等問題

從軟件實現的角度去關注非功能性需求

單體

分佈式

2.8 物理視圖

從硬件角度去關注非功能屬性

單體

分佈式

1.3 單體向分佈式演進、雲原生、技術中臺

1.3.1 單體的問題

• 巨大的代碼庫
• 過載的 IDE
• 過載的 WEB 容器
• 持續部署困難
• 應用擴展困難
• 難於進行規模化開發

模式: 單體架構

https://microservices.io/patterns/cn/monolithic.html

1.3.2 高可用架構

系統設計

• 故障轉移
• 超時控制
• 降級和限流

系統運維

• 灰度發佈
• 故障演練

故障轉移

徹底對等的節點之間作故障轉移

在對等節點之間作故障轉移，相對來講簡單些

在這類系統中全部節點都承擔讀寫流量，而且節點中不保存狀態，每一個節點均可以做爲另外一個節點的鏡像

不對等的節點之間，即系統中存在主節點也存在備節點

使用最普遍的故障檢測機制是「心跳」

你能夠在客戶端上按期地向主節點發送心跳包，也能夠從備份節點上按期發送心跳包

當一段時間內未收到心跳包，就能夠認爲主節點已經發生故障，能夠觸發選主操做

超時/降級/限流

數據庫訪問超時、rpc/遠程調用超時、緩存/隊列等其餘中間件訪問超時

探測出系統或者服務單位內容許出現的最大請求，直接拒絕後面的請求

水平/垂直擴展

水平（也叫橫向擴展）：用更多的節點支撐更大的請求

如成千上萬的螞蟻完成一項搬運工做

垂直（也叫縱向擴展）：擴展一個點的能力支撐更大的請求

如利用一我的的能力，如蜘蛛俠逼停火車

AKF 擴展立方

X 軸：表明無差異的克隆服務和數據，工做能夠很均勻的分散在不一樣的服務實例上

Y 軸：關注應用中職責的劃分，好比數據類型，交易執行類型的劃分

Z 軸：關注服務和數據的優先級劃分，如分地域劃分

業務模塊化打造單體和分佈式部署同步支持方案

https://mp.weixin.qq.com/s/HE7BxH_RZo45bY2baNgt5Q

模塊拆分原則

• 微服務拆分的大部份原則依舊適用
• 一個業務模塊對應一個數據庫，不能直接查另外一個業務模塊的數據庫
• 模塊之間的調用經過抽象契約接口來完成
• 模塊之間互相依賴只能依賴於抽象契約

1.3.3 雲原生

什麼是雲原生

雲原生技術有利於各組織再公有云、私有云和混合雲等新型動態環境中，構建和運行可彈性擴展的應用

雲原生的表明技術包括容器、微服務、服務網絡、不可變基礎設施和聲明式 API

這些技術可讓咱們構建高度穩定、可控、可觀測的鬆散耦合應用

但云原生方案的重點並非應用部署在何處，而是如何構建、部署和管理應用

關鍵點

• 不可變基礎設施
• 12 因素：https://12factor.net/zh_cn/

12 因素

1. 基準代碼：基準代碼和應用之間老是保持一一對應的關係：

• 一旦有多個基準代碼，就不能稱爲一個應用，而是一個分佈式系統。分佈式系統中的每個組件都是一個應用，每個應用能夠分別使用 12因素 進行開發
• 多個應用共享一份基準代碼是有悖於 12因素 原則的。解決方案就是將共享的代碼拆分爲獨立的類庫，而後使用 依賴管理 策略去加載它們

1. 顯示聲明依賴
2. 配置：推薦將配置保存於環境變量中
3. 把後端服務看成附加資源
4. 嚴格分享構建和運行
5. 以一個或多個無狀態進程運行應用
6. 經過端口綁定提供服務：12因素 應用徹底自我加載，而不依賴於任何網絡服務就能夠建立一個面向網絡的服務。互聯網應用經過端口綁定來提供服務，並監聽發送至該端口的請求
7. 經過進程模型進行擴展
8. 快速啓動和優雅終止可最大化健壯性
9. 儘量的保持開發，預發佈，線上環境相同
10. 把日誌看成事件流
11. 後臺管理任務看成一次性進程運行

雲原生 VS 微服務

雲原生方案與微服務架構相似

然而，儘管微服務可經過構建雲原生應用來交付，可企業仍須要採起許多措施，才能在生產環境中熟練地管理微服務

而想要享受雲原生應用的各類益處，也並不是必定須要微服務

不少企業都經過基於相同的原則，構建出更優秀的模塊化單體式應用，從而取得雲原生方案的種種效益

1.3.4 技術中臺