.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 因素

  1. 基准代碼:基准代碼和應用之間總是保持一一對應的關系:
  • 一旦有多個基准代碼,就不能稱為一個應用,而是一個分布式系統。分布式系統中的每一個組件都是一個應用,每一個應用可以分別使用 12因素 進行開發
  • 多個應用共享一份基准代碼是有悖於 12因素 原則的。解決方案就是將共享的代碼拆分為獨立的類庫,然后使用 依賴管理 策略去加載它們
  1. 顯示聲明依賴
  2. 配置:推薦將配置保存於環境變量中
  3. 把后端服務當作附加資源
  4. 嚴格分享構建和運行
  5. 以一個或多個無狀態進程運行應用
  6. 通過端口綁定提供服務:12因素 應用完全自我加載,而不依賴於任何網絡服務就可以創建一個面向網絡的服務。互聯網應用通過端口綁定來提供服務,並監聽發送至該端口的請求
  7. 通過進程模型進行擴展
  8. 快速啟動和優雅終止可最大化健壯性
  9. 盡可能的保持開發,預發布,線上環境相同
  10. 把日志當作事件流
  11. 后台管理任務當作一次性進程運行

雲原生 VS 微服務

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

然而,盡管微服務可通過構建雲原生應用來交付,可企業仍需要采取許多措施,才能在生產環境中熟練地管理微服務

而想要享受雲原生應用的各種益處,也並非一定需要微服務

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

1.3.4 技術中台

課程鏈接

https://appsqsyiqlk5791.h5.xiaoeknow.com/v1/course/video/v_5f39bdb8e4b01187873136cf?type=2

知識共享許可協議

本作品采用知識共享署名-非商業性使用-相同方式共享 4.0 國際許可協議進行許可。

歡迎轉載、使用、重新發布,但務必保留文章署名 鄭子銘 (包含鏈接: http://www.cnblogs.com/MingsonZheng/ ),不得用於商業目的,基於本文修改后的作品務必以相同的許可發布。

如有任何疑問,請與我聯系 (MingsonZheng@outlook.com) 。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM