[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. 分区表考虑: 对大表可考虑使用分区表功能,这可以简化拆分规则的调整,避免大范围数据迁移的问题。 > 除表结构设计外,我们还需要考虑延迟写入、日志备份等机制,这可以降低因拆分规则调整导致的数据同步与一致性问题的难度。 综上,提高表结构的独立性、灵活性与扩展性,有利于后期的业务变更与拆分规则调整。但也需要对数据迁移、同步与备份等问题有清晰的认识,并采取相应的机制与策略进行规避。这需要设计人员对分库分表实现的核心要素有比较全面的理解。 >技术边界、特性、使用场景、应用方法、与项目中的结构关系和实施关键流程。