架構經驗總結

20250511-總結經驗

一、SOA

1）過程：需求分析、系統設計、系統實現、構件組裝、部署運維、后開發階段。

2）特點：無狀態、單一職責、明確定義接口、自包含、模塊化、粗粒度、重用性、兼容性、互操作性、松耦合、策略聲明。

3）標準：文檔標準化、通信協議標準、應用程序、統一登記與集成、服務質量。

4）組成：UDDI、WSDL、SOAP、WEB Service。

5）應用：

????????分析階段：

????????????????*單體應用：預約掛號系統是單體應用。

????????????????*用例圖：通過用例圖分析需求。

????????????????*類：醫院、用戶、訂單、支付、三方服務等。

? ? ? ? ? ? ? ? *拆分：預測系統用戶超千萬、萬級并發、單服務器資源小、需要負載均衡，所以需要拆分。

????????????????*性能可用性：添加緩存、負載均衡。

????????????????*文檔：需求規格說明書、需求約束。

????????設計階段：

????????????????*模塊UDDI、WSDL、SOAP、WEB Service的設計。

????????????????*UDDI：1服務注冊表。2重用nacos、Eureka。

????????????????*WSDL：1參數、接口、協議、URI、請求方法。

????????????????*SOAP：消息傳遞規范。（XML）

????????????????*RESTful：輕量級通信。（XML、JSON、text）

????????????????*WEB Service：1用例圖劃分。2通信圖表示交互。3環調用問題。4負載均衡、集群、redis、ES。

????????????????*文檔：接口規范、開發手冊、體系結構規格說明書、質量設計說明書。

????????????????*設計模型：1狀態圖、活動圖、序列圖、通信圖、時間圖、交互概覽圖。2類圖、對象圖、構件圖、部署圖。

????????實施階段：實現、構件組裝、測試、運行維護。

二、ABSD

1）過程：體系結構需求、體系結構設計、體系結構文檔化、體系結構復審、體系結構實現、體系結構演化。

2）特點：體系結構驅動、自頂向下遞歸細化、功能分解、體系結構風格實現質量和商業需求、模版使用。

3）設計方法：采用視圖視角描述架構；用例描述功能需求；質量場景描述質量需求；

4）應用

????????**需求：1提高性能、可用性，系統需要能承載千萬用戶量，并發支持萬級別，實現一年99.95%時間正常運行，系統需要提高運維能力以保證復雜場景的穩定運行；2預約掛號使用用例圖表示功能需求；3類：醫院、醫生、科室、用戶、訂單、支付、三方服務等。4構件：機構、用戶、訂單、支付、三方服務等構件。5評審。

????????**設計：1微服務、分層結構風格；2ATAM評估確定，微服務+微服務聚合器，使用微服務方式實現，再使用面向服務的開發方法定義微服務之間的交互，注冊中心；3映射構件，機構、訂單、三方服務開發，用戶和支付復用，另增加Nacos作為服務注冊與發現（中間件加進去提高可用性和性能）。4使用通信圖表示構件間關系。5用4+1視圖表示系統體系結構各個視角。6組織評審，分析師、架構師、測試、產品、項目經理、利益相關者，確定設計是否有風險、缺陷。（這個時候可以加上ES）

????????????????分析構件間相互作用：問題-微服務循環調用，解決-微服務聚合器。

????????**文檔化：1背景使用文字，多圖表示（注釋），形成體系結構規格說明書；2非功能性需求性能（<3s）、可用性（>99.95%/年），形成質量設計說明書，測試使用。

????????**復審：找醫院代表、系統工程師、項目經理、產品經理、利益相關者。風險：JWT鑒權，接口請求頭中使用明文Token標識不安全，需要改變策略但遲遲沒有解決；權衡：反向代理添加防黃牛，降低性能和可用性。

????????**實現：編碼、測試、部署，重用用戶和支付需要Spring的架構升級，其他的使用新Spring架構開發，遵循能復用即復用的機會復用方式，獲得構件后組裝成預約掛號系統，通過jmeter測試通過滿足高并發的要求，通過生產環境模型一周的運行軌跡也圓滿的符合可用性的標準。

????????**演化：收集用戶評價，獲得變更需求并歸類，首先制定演化計劃并評審，根據計劃開發或適配構件，替換組裝適配構件，更新體系結構的構件關系，然后進行測試，后評審發布階段，最后得到演化后的系統。

????????????????例：Easy Excel工具POI漏洞，升級3版本以上，經討論優先級較高、不能影響用戶使用，涉及訂單服務的更新，更新測試，金絲雀發布，運行3個月后正式更新生產。

三、架構評估

1）目標：

????????SAAM關注修改性、功能性、適應性、擴展性、移植性，通過場景分析驗證架構是否滿足系統需求，識別架構缺陷、風險點，支持架構決策。

????????ATAM關注性能、可用性、修改性、安全性等，通過評估多個質量屬性之間的權衡和優先級，核心：識別架構的風險點，支持架構優化，增強利益相關者協作。

2）質量屬性：

????????SAAM：修改性、功能性、適應性、擴展性、移植性等，單一質量屬性；通過質量屬性具體化為場景，評估體系結構滿足特定需求的適應能力。

????????ATAM：性能、可用性、修改性、安全性等，負載質量屬性；通過分析多個質量屬性之間的沖突和權衡，發現潛在的設計風險，并提供改進建議。

3）評估活動：

????????SAAM：場景開發、架構描述、單個場景評估、場景交互、總體評估。（側重場景驅動分析，方法簡單、易于實施，適合中小型項目）

????????ATAM：1描述階段：描述ATAM、描述業務目標、描述架構；2調查分析階段：提出架構方法、質量屬性效用樹、分析架構方法；3測試階段：場景討論與場景分級、分析架構方法；4報告階段：整理手機資料、通知項目干系人；（強調利益相關者參與，確保結果的全面性和可靠性，適合復雜系統的評估）

4）應用

????????ATAM：

????????????????描述階段：

????????????????????????描述ATAM：ATAM是基于場景的架構評估方法，通過評估多個質量屬性，從沖突中權衡獲得最優的架構，核心是識別風險點，提出改進策略；

????????????????????????描述業務目標：預約掛號目標是為用戶提供一個穩定、實時的醫療服務平臺，需要支撐名醫搶號時期的壓力；

????????????????????????描述架構：Spring框架，單體式架構、業務耦合、名醫搶號時期系統出現卡頓、嚴重時崩壞、單臺服務器資源使用猛增、黃牛搶號；

????????????????調查與分析：

????????????????????????提出體系結構方法：微服務、分層結構風格。微服務：伸縮性、服務化、SpringBoot框架、服務注冊表、小微輕松讀專；分層結構：結構清晰/層次分明、層間解耦、SpringMVC框架、版本迭代、安全性高（向下訪問）。

????????????????????????生成質量屬性效用樹：性能、可用性、安全性、可修改性。性能：名醫搶號功能需要支持萬級的并發；可用性：系統一年要99.95的時間平穩運行；安全性：需要預防黃牛搶號，提升搶號的公平性；可修改性：迭代每月一次。

????????????????????????分析體系結構方法：性能、可用性 > 安全性 > 可修改性。

????????????????????????????????首先，保障系統可用，再，保障系統的響應時間，平均響應時間<3s；

????????????????????????????????提高防黃牛策略：IP段黑名單、有效時間法、有效令牌法；

????????????????????????????????約定一個月迭代一次功能/優化。

????????????????????????????????風險點：業務耦合性太高，在名醫搶號期間會導致其他業務功能吞吐量降低，影響用戶體驗；權衡點：拆分服務雖然提高了伸縮性，但是性能和維護性會下降；非風險點：反向代理添加防黃牛策略可能會過濾掉正常用戶搶號。敏感點：選擇HTTP協議、使用JSON輕量級數據格式、專有網絡，可以提高系統溝通性能、安全性。

????????????????????????????????架構抉擇：通過分析，分層結構雖然也能伸縮、擴展和易于學習，但是可用性和性能重要，且業務需要拆分開來，資源按需分配，微服務體系結構適合，容器化、服務注冊發現nacos。

????????????????測試階段：

????????????????????????場景討論和分級：邀請利益相關者，三方醫院人員、項目經理、技術總監、產品、測試、架構師，討論設計方案。提出循環調用問題，使用微服務聚合器，限制調用層級為兩層。4+1視圖。文檔：體系結構規格說明書、質量設計說明書。

????????????????????????分析架構方法/測試架構：根據體系結構規格說明書部署系統，根據質量設計說明書評估可用性和性能指標。邀請更多的人評價系統，更新質量屬性效用樹，收集風險點、權衡點等問題，提出決策，最終確定了微服務架構的正確性。

????????????????總結：

????????????????????????收集討論過程中的質量屬性效用樹、風險點、權衡點、敏感點等，以及處理結果，再細化設計文檔，通知項目干系人。

四、云原生

1）過程：系統架構設計的生命周期：需求分析-設計-實現-構件組裝-部署階段-后開發階段；

2）特點：虛擬化、非功能委托、自動化、整合服務、隨用隨取；

3）原則：服務化、無服務器、服務網格、彈性、韌性、所有過程自動化、可觀測性、零信任、架構持續演化。

4）模式：服務化、無服務器、服務網格、可觀測、存算分離、分布式事務（XA/BASE/TCC/Sage/AT）、事件驅動架構。

5）介紹：

????????服務化：接口約定定義彼此業務關系；標準協議確保彼此互聯互通；領域模型驅動、測試驅動開發、容器化部署；提高代碼質量和迭代速度；

????????服務網格：將微服務之間的連接、安全、流程、可觀測等通用功能下沉為基礎設施，讓應用于平臺基礎設施解耦；分離組件、安全策略、流量控制、微隔離；

????????無服務器模式：部署從人工轉到自動化；委托，不關心存儲節點、操作系統、網絡、計算機性能等；按需分配；自動擴展；高可用；快速部署；

????????存算分離：云存儲，暫態數據、結構化、非結構化數據；服務器無狀態；

????????分布式事務：

????????可觀測：

6）應用：服務化——存算分離——容器化——無服務器——服務網格——分布式事務

????????Kubernetes：容器編排技術；服務調度；存算分離；

????????Docker：容器化

????????Prometheus：可觀測；日志收集，ES、Logstash、Kibana

????????服務化：微服務、HTTP、Nacos、Redis、Elastic search（分布式搜索和分析引擎）

????????CICD：持續集成持續部署；

????????自動化：Kubernetes自動拉起。

????????分布式數據庫代理：Cobar

????????服務網格：lstio

五、特定領域軟件架構DSSA

1）過程：領域分析、領域設計、領域實現；

????????領域分析：領域專家、領域分析人員。目標獲取領域模型，描述系統的共同需求。

????????領域設計：領域設計人員。目標獲取領域架構，滿足被建模的領域需求。形成重用基礎設施規約。要求領域經驗的設計人員。

????????領域實現：領域實現人員。依據模型、架構，開發組織可重用信息、軟件可重用的實現。軟件重用、再工程、領域經驗的開發人員。

2）DSSA的建立過程：定義領域范圍、定義領域特定元素、定義領域特定設計和需求約束、定義領域模型和體系結構、產生收集可重用產品單元。

3）特點：嚴格定義的問題域和問題解域、普遍性（用于領域特定應用開發）、對整個領域構件的組織模型的恰當抽象、【具備領域固定、典型、開發過程中重用的元素】。

4）應用：機構服務

????????定義領域范圍：確定需求、確定時間。醫療領域：生活中必不可少、公司對醫療有功底、邀請多個醫院的技術專家。領域范圍：創建醫院、科室、醫生，發放號源，單日預約搶號，檢索定位，三方醫院交互。

????????定義領域特定元素：定義領域字典、領域同義詞字典。醫療領域專家培訓（機構概念、his代表醫院、普通醫生沒有實體數據（排班）），建立領域詞典（學習查詢）。

????????定義領域特定設計和需求約束：識別約束，記錄約束對設計和實現造成的后果。基礎功能實現，搶號的性能問題設計（緩存）、檢索與定位設計、三方醫院請求數據（緩存鎖定號源）。搶號數據一致性問題（消息隊列，異步通知搶號結果）采用BASE理論。

????????定義領域模型和體系結構：產生體系結構，說明構成該模塊的語法和語義。現有業務需求產生領域模型（4+1），根據需求采用微服務架構模式（服務化、復用性好、獨立性），增加緩存（放號源）異步更新數據，最終一致性，消息推送。

????????產生收集可重用產品單元：為DSSA增加構件，用來解決領域中的問題。（redis緩存、ES檢索定位、極光消息推送中間件 + 異步線程短信通知搶號結果）

六、分布式

1）技術：CDN內容分發網絡、反向代理、負載均衡、微服務、分布式緩存、分布式文件系統、主從復制/讀寫分離/分庫分表、分布式數據庫、NoSQL。

2）特點：資源共享、提高運算速度（分配運算任務）、高可靠性、通信方便快捷（網絡互聯）。

3）應用：

????????CDN：結合網絡、連接、負載合理分配最近的節點。解決擁堵、優化網絡、降低延遲。

????????反向代理：服務端、接收轉發、轉發一個服務器中、轉發過濾、攔截器。 nginx + IP段黑名單/有效時間法/有效令牌法算法；

????????負載均衡：關注整體負載、轉發策略、利用率、保證吞吐和響應速度。 nginx + 權重

????????微服務：業務拆分、簡化業務復雜性、提高開發/維護效率。拆分、獨立使用技術、獨立擴展、小團隊開發、容器化、機構中心自由伸縮、輕量級通信。

????????分布式緩存：內存讀寫塊、熱點數據、持久化。 redis、存放號源、存放主頁熱點數據。

????????分布式文件系統：分散存儲、網絡連接、分布透明性； HDFS/OSS、身份認證。

????????主從復制/讀寫分離：主從、復制、讀寫分開；主寫從讀、從同步、最終一致性。（提高吞吐量、降低并發延遲）

????????分庫分表：分庫、分表；業務分庫、訪問頻率/范圍分表。

????????分布式數據庫：分片分布地點、全局外模式交互、全局概念模式分片透明性； Cobar分布式數據庫代理Mysql、業務拆分庫、按城市存儲分片數據；

????????NoSQL：鍵值對、列族、文檔、圖形； ES搜索引擎、倒排索引、地理位置、距離算法；（醫院信息）

七、軟件設計方法

1）方法：結構化、面向對象、面向服務、構件化、原型、敏捷。

2）特點：

????????結構化：1開發目標清晰化；2開發工作階段化；3開發文檔規范化；4設計方法結構化（自頂向下分解，自底向上實現）；5過程驅動；6應用場景：需求明確、變化少的中小型系統。

????????面向對象：1對象為核心、封裝/繼承/多態；2場景：高復雜度、需求頻繁變更的場景；3提高維護性、降低耦合。

????????面向服務：1服務化、跨平臺集成、異構系統整合、適合分布式架構需求；2場景：復雜業務、跨系統協作。

????????服務化：為請求者提供需要，以獨立服務為單元，使用標準化接口實現松耦合交互；

????????構件化：1復用、標準化接口（接口規范/兼容/擴展）；2場景：快速迭代的通用功能開發、快速獲得可運行的系統、低代碼平臺。

????????原型：1快速驗證需求、收集用戶反饋、降低需求理解偏差；2用戶深度參與、確保產品符合預期；3場景：需求不明確、頻繁變更、創新項目；

????????敏捷：1迭代交付、短周期、持續交付、快速響應變更；2團隊協作優先、強調面對面溝通、減少文檔依賴、提升開發靈活性。3場景：需求不明確、優先級動態調整的項目；

3）選型

????????面向服務：服務注冊表、服務化、微服務、粗粒度、輕量級通信。

????????敏捷：溝通、簡單、反饋、勇氣；小小簡單測試，40隱喻集體用戶，計劃重構，集成代碼規范。

4）應用：面向服務 + 敏捷

????????溝通：強調有效率的溝通。晨會匯報工作、周會總結經驗。每人負責兩個服務構件的開發（小團隊），架構設計時醫院、醫生、科室合為一個服務，機構名稱、his標識醫院、普通醫生屬于弱實體。

????????簡單：簡單設計，注重實現。HTTP輕量級通信、使用Swagger接口文檔、編碼注釋（評審）、編碼插件（0警告）、機會復用、CICD流水線、每個服務專一性。（名醫搶號的緩存邏輯）

????????反饋：團隊間人員及時反饋。敏感點、權衡點、風險點、非風險點；代碼規范咨詢資深開發人員，代碼評審不足之處反饋并提出解決方案；

????????勇氣：開發/重構期間，勇于抉擇和實踐。實踐：名醫搶號直接緩存、添加ES搜索引擎和位置定位、分布式部署Docker+k8s。

八、軟件可靠性

1）技術：容錯（N版本/恢復塊/冗余）、檢錯（監控/告警/熔斷/降級）、降低復雜度（系統結構/算法/圈復雜度/調用鏈的長短）、雙機熱備技術（雙機熱備/雙機互備/雙機雙工）

2）模型：種子法、可靠性增長模型、系統結構分析模型、執行路徑分析方法模型。

????????可靠性度量指標：故障率、平均修復時間MTTR、平均失效等待時間MTTF、平均失效間隔時間MTBF、可靠度

3）開發期可靠性管理：

????????需求分析：可靠性目標、影響可靠性因素、可靠性驗收標準、初步的活動計劃、收集可靠性數據規約、可靠性文檔編寫規約。

????????概念結構設計：可靠性度量方案、可靠性驗收方案、可靠性設計、整理可靠性活動計劃、收集可靠性數據、確定后續活動計劃、編寫可靠性文檔。

????????詳細結構設計：可靠性設計、可靠性預測、調整可靠性活動計劃、收集可靠性數據、確定后續活動計劃、編寫可靠性文檔。

????????編碼：編碼、單元測試、修改問題、調整可靠性活動計劃、收集可靠性數據、確定后續活動計劃、編寫可靠性文檔。

????????測試：集成測試、系統測試、排錯、建模（用戶看）、收集評價、調整可靠性活動計劃、收集可靠性數據、確定后續活動計劃、編寫可靠性文檔。

????????實施：驗收測試、排錯、調整可靠性活動計劃、收集可靠性數據、可靠性評價、編寫可靠性文檔。

????????可靠性評價過程：可靠性建模、收集可靠性數據、可靠性評估預測。

4）應用：

????????容錯技術：冗余策略，服務、數據多份副本，保證安全性；1）服務最少兩個副本運行、機構中心采用5個副本；2）數據庫采用分布式的方式，通過業務分庫分表，每個庫都采用主從復制方式。

????????檢錯技術：

????????????????未發生的異常：我們采用了prometheus構建，采集系統狀態、指標規則監控告警，短信、通信軟件和郵件通知。

????????????????已發生的異常：采用降級和熔斷策略，降級：服務器>80%，離線計算業務自動從服務器上推出。熔斷：請求錯誤率>60%，自動斷開請求，響應異常信息，并告警。

????????????????降低復雜度：結構（調用鏈長度）、算法、環路復雜度

????????????????????????結構：系統設計階段，遵循模塊獨立性，使用設計原則、設計模式；模塊獨立性：小團隊開發、獨立選擇技術、獨立部署、運行不依賴其他服務；單一職責：機構中心只關系醫院相關功能、訂單服務只關注用戶的訂單信息處理；責任鏈模式：系統調用需要過濾未登錄的用戶，對每次操作數據都要有日志記錄；

????????????????????????算法：減少時間復雜度、注意空間復雜度、兩者均衡、并行化；1）高頻計算：預計算結果緩存，訂單統計；2）負載決策：分治法，醫院、醫生查詢根據購買的關鍵字打標區分開來，分級處理；3）實時數據：采用惰性加載，體檢套餐列表圖片劃到展示；

????????????????????????環路復雜度：一個函數中，if數量<10，行數<80；采用提煉函數設置有意義的函數名；

????????雙機熱備：采用了異地多活方式，系統可以分鐘級切換，防水火地雷戰，平時使用流量分發策略，使兩個云的系統都可接受流量提高利用率。

????????服務器集群技術：負載均衡，權重（機器硬件分級）。