目錄
- 什麼是軟體架構
- 軟體架構的基本思路
- 單體向分布式演進、雲原生、技術中台
1.1 什麼是軟體架構
1.1.1 什麼是架構？
Software architecture = {Elements, Forms, Rationale/Constraints}
元素、形式/模式、基本原理和限制
為什麼需要軟體架構？
軟體架構的終極目标是用最小的人力成本來滿足建構和維護系統的需求
一個軟體架構的優劣，可以用它滿足使用者需求的成本來衡量。如果該成本很低，并且在系統的整個生命周期内一直都維持這樣的低成本，那麼這個系統的設計就是優良的，如果該系統的每次釋出都會提升下一次變更的成本，那麼這個設計就是不好的，就這麼簡單。
--架構整潔之道
産品經理
- 需求分析
- 需求設計
- 項目管理
- 産品營運
1.1.2 什麼是架構師？
系統的次元
負責整體系統的架構設計，主要是基礎服務和各系統間的協調上，着眼全局不太注重某個應用本身架構，比如關注伺服器負載，可靠性，伸縮，擴充，資料庫切分，緩存應用等方法的基礎架構設計
應用程式的次元
負責某個應用的技術架構，主要偏業務系統，關注了解業務，梳理模型，設計模式，接口，資料互動等方面
業務流程的次元
關注某一個行業、業務的領域分析，擷取領域模型，最終獲得系統的模型
也可以叫業務領域專家、行業專家、産品咨詢師、資深顧問
降低成本
通過設計和實作優良的軟體架構來持續降低軟體的建構和維護成本
軟體架構這項工作的實質就是規劃如何将系統拆分成元件，并安排好元件之間的排列關系以及元件之間互相通信的方式
如何降低成本？
- 低成本維護（容易被改動和了解）
- 軟體可複用
- 輕松部署
設計原則會給我們答案
軟體架構師的目标是建立一種系統形态，該形态會以政策為最基本的元素，并讓細節與政策脫離關系，一個優秀的軟體架構師應該緻力于最大化可選項數量
職能
- 負責公司系統架構設計、研發工作
- 承擔從業務向技術轉換的橋梁作用
- 協作項目經理制定項目計劃和控制項目進度
- 負責輔助并指導 SA 開展設計工作
- 負責組織技術研究和攻關工作
- 負責組織和管理公司内部的技術教育訓練工作
- 負責組織及帶領公司内部員工研究與項目相關的新技術
- 管理技術支撐團隊并給項目、産品開發實施團隊提供技術保障
- 了解系統的業務需求，制定系統的整體架構（包括：技術架構和業務架構）
- 對系統架構相關技術和業務進行教育訓練，指導開發人員開發
- 解決系統開發、運作中出現的各種問題
- 對系統的重用、擴充、安全、性能、伸縮性、簡潔等做系統級的把握
軟體周期内，标準組織架構下的各個職位的分工
- CEO
- CTO/CIO
- 産品總監/技術總監/架構師 Architect Director
- 資深開發/Manager
- 進階開發/Leader
1.1.3 軟體架構分類
從架構師的工作内容上來劃分可以分為三類：
- 系統架構師
- 應用架構師
- 業務架構師
系統架構師/基礎架構師
從系統的次元，負責整體系統的架構設計，主要是基礎服務和各系統間協調上，着眼全局不太注重某個應用本身架構，比如關注伺服器負載，可靠性，伸縮，擴充，資料庫切分，緩存應用等方面的基礎架構設計。
從應用程式的次元，負責某個應用的技術架構，主要偏業務系統，關注了解業務，梳理模型，設計模式，接口，資料互動等方面。
從業務流程的次元，關注某一個行業、業務的領域分析，擷取領域模型，最終獲得系統的模型。也可以叫業務領域專家、行業專家、産品咨詢師、資深顧問。
基礎架構、前端架構、後端架構是從職責上的分類。
.NET雲原生架構師訓練營講什麼，怎麼講，講多久
https://mp.weixin.qq.com/s/JWOIScGrX0Hszz4uqdA6qw1.1.4 架構風格
- 分層架構
- 微核架構/六邊形架構/簡潔架構
- 事件驅動架構
- 微服務架構
- 雲架構
軟體架構入門
http://www.ruanyifeng.com/blog/2016/09/software-architecture.html1.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.html1.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 因素
- 基準代碼：基準代碼和應用之間總是保持一一對應的關系：
- 一旦有多個基準代碼，就不能稱為一個應用，而是一個分布式系統。分布式系統中的每一個元件都是一個應用，每一個應用可以分别使用 12因素 進行開發
- 多個應用共享一份基準代碼是有悖于 12因素 原則的。解決方案就是将共享的代碼拆分為獨立的類庫，然後使用 依賴管理 政策去加載它們
- 顯示聲明依賴
- 配置：推薦将配置儲存于環境變量中
- 把後端服務當作附加資源
- 嚴格分享建構和運作
- 以一個或多個無狀态程序運作應用
- 通過端口綁定提供服務：12因素 應用完全自我加載，而不依賴于任何網絡服務就可以建立一個面向網絡的服務。網際網路應用通過端口綁定來提供服務，并監聽發送至該端口的請求
- 通過程序模型進行擴充
- 快速啟動和優雅終止可最大化健壯性
- 盡可能的保持開發，預釋出，線上環境相同
- 把日志當作事件流
- 背景管理任務當作一次性程序運作
雲原生 VS 微服務
雲原生方案與微服務架構類似
然而，盡管微服務可通過建構雲原生應用來傳遞，可企業仍需要采取許多措施，才能在生産環境中熟練地管理微服務
而想要享受雲原生應用的各種益處，也并非一定需要微服務
很多企業都通過基于相同的原則，建構出更優秀的子產品化單體式應用，進而取得雲原生方案的種種效益
1.3.4 技術中台