[TOC] ### 系統設計關鍵流程: > 需求分析 -> 概要設計 -> 詳細設計 -> 邏輯模型設計 -> 物理模型設計 -> 數據庫創建 -> 代碼實現 -> 測試 -> 上線維護 *文檔參考:* > `需求文檔、概要設計文檔、詳細設計文檔、ER圖等邏輯模型、物理模型、數據字典等` ***優點:*** 1. 強調需求分析和業務知識,貼近業務本質和規律,具有較高的準確性。 2. 分步演進,逐漸深入和完善設計方案,有利于管理復雜度。 3. 考慮數據庫選擇和實現兩方面,設計過程簡明清晰。 4. 測試用例嚴密,保證實現的正確性。 缺點: 1. 過程比較長,難以應對快速變化的需求。 2. 涉及的技能和知識較廣,難度較大。 3. 不能確保獲得全面和準確的需求,存在部分主觀判斷。 邊界范圍: 1. 適用于中大型系統工程,對小型系統設計要作適當簡化。 2. 更適合互聯網產品開發,對于傳統企業系統適用性稍差。 3. 數據庫模型以關系型數據庫為主,NoSQL數據庫設計過程有差異。 4. 偏重功能設計,非功能需求設計較少涉及,需要補充。 5. 代碼實現階段的選擇會影響整體設計,如選擇不同前后端框架。 ### *流程說明* ： * 需求分析:收集業務需求和域知識,理解業務規則和流程。這是設計的基礎和前提。 * 概要設計:根據`需求分析`結果,設計系統的總體結構和框架。確認業務對象及其關系,劃分模塊和服務,演進出一份概要設計方案。 * 詳細設計:在`概要設計`的基礎上,設計各業務對象的屬性及關系,設計服務接口,劃分微服務或內部服務,設計中間件和接口,設計前后端分工等。輸出詳細的設計文檔。 * 邏輯模型設計:將`詳細設計`中的數據實體及其關系映射為實體關系模型圖或其他邏輯模型。確認每個實體的屬性。 * 物理模型設計:根據選定的DBMS,將`邏輯模型`轉化為對應的物理模型。如在MySQL下,轉化為數據庫表結構和關系。添加索引、約束等。 * 數據庫創建:根據`物理模型`,創建數據庫和表,添加索引、約束等,創建用戶和權限,完成數據庫的初始環境配置。 * 代碼實現:根據`詳細設計`,使用選定的語言和框架實現系統代碼,包括后端服務、前端頁面、第三方接口等的開發。 * 測試:編寫測試用例,進行單元測試、集成測試、性能測試、場景測試等,徹底測試系統功能和非功能需求。 * 上線和維護:系統上線后進入維護期,需要持續更新和優化系統,不斷完善設計和測試,將反饋信息融入到新的迭代版本。 ## 技術架構 ### 1，微服務 > 技術范圍: - 分布式系統:微服務架構是一種分布式架構模式 - 面向服務:基于服務拆分業務,服務之間松耦合 - 持續交付:微服務更易于持續集成和交付 - 容錯性:微服務系統具有較高的容錯性和彈性 > 技術邊界: - Spring Boot:快速開發微服務 - Spring Cloud:提供微服務架構的一站式解決方案 - Netfilx OSS:提供微服務核心組件,由Spring Cloud實現 - Docker:提供容器虛擬化,便于微服務打包和部署 - Kubernetes:容器編排管理平臺,管理微服務 - Zuul:API網關,面向服務的統一入口 - Eureka:服務發現與注冊中心 - Ribbon:客戶端負載均衡 - Feign:聲明式REST客戶端,簡化RESTful服務調用 - Hystrix:提供延遲和容錯功能,防止聯級故障 - Config Server:集中管理各個微服務的配置文件 - Bus:消息總線,廣播端點事件 除此之外,還有log aggregation, tracing系統,metrics監控等相關技術。 > 特性: - 單一職責:每個服務只專注于完成一項任務 - 輕量級通信:服務之間采用輕量級的通信機制,如HTTP RESTful API - 獨立部署:服務獨立部署、上線和擴展 - 中心化配置:使用配置中心管理各服務配置 - 敏捷靈活:微服務架構更加敏捷和靈活 > 使用場景: - 大型復雜系統: 易于拆分和管理 - 互聯網應用: 需快速修改和部署 - 持續交付: 每日或每周發布新功能 - 大型團隊: 不同團隊負責不同的服務 > 應用方法: 1. 拆分系統為多個服務,每個服務執行一項業務功能 2. 服務間通過API進行通信 3. 每個服務獨立部署,使用輕量級通信機制 4. 使用服務注冊與發現解決服務依賴關系 5. 使用配置中心管理服務配置,實現快速重新配置 6. 增加服務實例提高系統擴展性 7. 容錯機制防止聯級故障 > 項目結構關系: 圍繞業務拆分多個子系統,形成一個分布式系統。 > 實施關鍵流程: 1. 拆分系統為多個服務 2. 服務間通過API調用進行集成 3. 每個服務獨立部署和發布 4. 注冊與發現解決服務依賴 5. 配置中心管理服務配置 6. 監控系統運行狀態和性能 7. 根據需求增加服務實例 8. 日志與追蹤關聯不同服務調用 用戶訪問網關→調用不同服務完成業務→服務調用服務(可選)→數據庫持久化 >#### 微服務集成架構通常包含以下要素: 1. API網關:作為系統的統一入口,實現服務路由、認證、限流等功能。 Zuul和Spring Cloud Gateway是常用實現。 2. 服務注冊與發現:管理各個微服務的依賴關系與服務信息。Eureka和Consul是常用的實現。 3. 客戶端負載均衡:在服務調用方選擇服務提供方實例。Ribbon是Spring Cloud的客戶端負載均衡實現。 4. 服務調用:客戶端調用服務端的REST API。Feign提供聲明式的REST客戶端調用。 5. 配置中心:集中管理各個微服務的外部配置。Spring Cloud Config是Spring的配置中心實現。 6. 消息隊列:實現異步通信和削峰填谷。RabbitMQ和Kafka是常用消息中間件。 7. 服務熔斷與降級:在服務不可用時提供兜底方案,防止連鎖故障。Hystrix是Netflix開源的熔斷器實現。 8. 日志聚合:將分布式環境下的日志聚合,方便問題排查。ELK是LOGGING系統,被Spring Cloud日志聚合方案采用。 9. 監控:監控各個微服務的運行指標和調用鏈路,以監控系統整體運行狀況。Prometheus、Zipkin和Spring Boot Admin是常用監控選型。 基于以上要素構建的一個簡單微服務集成架構如下: ``` -------- | 服務1 | ------ / \ -------- | | | |--| | 用戶 --| API網關 | -------- | | / | -------- | 服務2 | <------- |Config| \ / | server| -------- -------- | | | ------------- | -------------- |服務注冊中心|--| 配置中心 | | Eureka | | Spring Cloud | | | | Config | ------------- -------------- ``` 理解微服務集成架構的各個要素及其關系,有助于我們設計規劃較為完備的微服務方案。熟練掌握Spring Cloud等框架,我們可以更高效地構建微服務集成方案,開發云原生應用系統。 云原生應用系統以微服務為基礎,具有容器化、彈性擴展、持續交付、中心化配置管理等特征。它可以更好地利用云計算的優勢,快速響應業務變化,構建高可用和可伸縮的應用系統。 ### 2，分表分庫 > 技術范圍: - 數據庫拆分: 將數據庫拆分為多個數據庫實例,以提高性能和可擴展性 - 數據庫分片: 在多個數據庫實例之間分布數據,實現橫向擴展 - 讀寫分離: **在主數據庫進行寫操作,從數據庫進行讀操作,提高性能** > 技術邊界: - `MySQL`: 關系型數據庫,提供表/庫拆分、分片、主從復制等功能 - `sharding-jdbc:` ***基于JDBC實現的分庫分表框架*** - `MyCAT:` 數據庫中間件,實現讀寫分離、分庫分表 - `Kingshard:` Golang開發的數據庫中間件,提供proxy和router - `Codis:` Redis分片中間件,實現Redis的分表分庫 - `Hibernate Shards:` Hibernate的分庫分表實現 數據庫實例之間通過中間件進行通信與協調,中間件實現數據庫的邏輯拆分與路由功能。 其中MyCAT和sharding-jdbc較為常用,典型架構如下: ``` 應用1 應用2 | | | | |- sharding-jdbc(或MyCAT) | | | | | | DB1(主) DB2(從) DB3 DB4 ``` 應用通過sharding-jdbc或MyCAT訪問數據庫,實現讀寫分離和分庫分表功能。 理解這些技術和架構,可以幫助我們設計高性能和高可擴展的數據庫系統。根據業務需求選擇合適的技術方案和工具,實現數據庫的拆分、分片和讀寫分離。 > 特性: - 橫向擴展:通過數據庫拆分實現系統擴展 - 高性能:減少單數據庫的訪問壓力,提高性能 - 高可用:同時訪問多個數據庫實例,單實例故障不影響全局 - 靈活擴容:可根據業務需求擴容數據庫實例 > 使用場景: - 高并發系統:需要支持高并發和大量數據 - 業務關聯性低:數據之間關聯較低,易于拆分 - 讀寫分離:主數據庫寫,從數據庫讀,提高性能 > 應用方法: 1. 拆分大表為小表,拆分規則設計合理 2. 使用中間件實現讀寫分離和分庫分表 3. 數據庫之間通過中間件通信與協調 4. 應用通過中間件訪問數據庫 5. 中間件實現 SQL 路由、鑒權、監控等功能 6. 數據庫之間數據同步與一致性保證機制 > 項目結構關系: 應用通過中間件訪問拆分后的數據庫集群。 > 實施關鍵流程: 1. 確定拆分策略,設計表結構 2. 安裝和配置數據庫中間件 3. 配置讀寫分離和表路由規則 4. 數據同步與數據一致性方案 5. 應用系統接入中間件 6. 路由規則優化 7. 監控系統運行情況 8. 根據業務變化調整拆分規則和擴容規劃 理解分表分庫的特性和應用場景,有助于我們設計高性能、高擴展的數據庫方案。通過數據庫拆分,可以實現系統的橫向擴展,解決單體數據庫難以 scale 的問題。 掌握`MyCAT、sharding-jdbc`等中間件,我們可以更高效地實現數據庫拆分,開發大數據量、高并發的系統。熟練運用分庫分表技術,已經成為構建大型系統不可或缺的能力。 > #### 設計表結構時考慮后期業務變化和拆分規則調整,需要注意以下幾點: ##### 1. 避免過度依賴業務: 表結構不要和某個具體業務規則或場景緊耦合。這會使任意業務變更都要對應修改表結構,不利于后期調整。 ##### 2. 增加冗余度: 為了靈活調整拆分規則,表結構上可以增加一定的數據冗余。避免某個字段變成拆分的唯一憑據,造成調整困難。 ##### 3. 擴展性考慮: 表結構設計需要考慮未來大量數據的存儲與查詢。要避免出現單表瓶頸,無法有效拆分和擴展的情況。 ##### 4. 主鍵選型靈活: 選擇范圍自增、哈希等可以有效控制數據分布的主鍵方式。這樣可以根據需要調整分片建或合并,較為靈活。單純的自增ID則拆分后難以遷移。 ##### 5. 松耦合設計: 采用類似于實體-值對象模型的設計思想,表與表之間的耦合度較松,這樣各表可以相對獨立地拆分或調整。 ##### 6. Archive 表: 對歷史舊數據設計Archive表用于存儲。主線業務表只保留熱點數據。這有利于主業務表的拆分與優化。 ##### 7. 分區表考慮: 對大表可考慮使用分區表功能,這可以簡化拆分規則的調整,避免大范圍數據遷移的問題。 > 除表結構設計外,我們還需要考慮延遲寫入、日志備份等機制,這可以降低因拆分規則調整導致的數據同步與一致性問題的難度。 綜上,提高表結構的獨立性、靈活性與擴展性,有利于后期的業務變更與拆分規則調整。但也需要對數據遷移、同步與備份等問題有清晰的認識,并采取相應的機制與策略進行規避。這需要設計人員對分庫分表實現的核心要素有比較全面的理解。 >技術邊界、特性、使用場景、應用方法、與項目中的結構關系和實施關鍵流程。