.NET 云原生架構師訓練營(模塊一 架構師與云原生)--學習筆記
目錄
什么是軟件架構
軟件架構的基本思路
單體向分布式演進、云原生、技術中臺
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/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 高可用架構
系統設計
故障轉移
超時控制
降級和限流
系統運維
灰度發布
故障演練
在對等節點之間做故障轉移,相對來說簡單些
在這類系統中所有節點都承擔讀寫流量,并且節點中不保存狀態,每個節點都可以作為另一個節點的鏡像
使用最廣泛的故障檢測機制是“心跳”
你可以在客戶端上定期地向主節點發送心跳包,也可以從備份節點上定期發送心跳包
當一段時間內未收到心跳包,就可以認為主節點已經發生故障,可以觸發選主操作
水平/垂直擴展
水平(也叫橫向擴展):用更多的節點支撐更大的請求
如成千上萬的螞蟻完成一項搬運工作
垂直(也叫縱向擴展):擴展一個點的能力支撐更大的請求
如利用一個人的能力,如蜘蛛俠逼?;疖?/p>
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 技術中臺
.NET 云原生 機器學習
版權聲明:本文內容由網絡用戶投稿,版權歸原作者所有,本站不擁有其著作權,亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容,請聯系我們jiasou666@gmail.com 處理,核實后本網站將在24小時內刪除侵權內容。