设计模式原则

设计模式原则 设计模式的原则是理解和使用设计模式的基石。这些原则是面向对象设计的核心指导思想,设计模式本身就是这些原则在特定场景下的具体体现。 最重要的设计原则是 SOLID 原则,此外还有一些其他关键原则。 一、 SOLID 原则 SOLID 原则是五个最常用、最经典的设计原则,由 Robert C. Martin 提出。 1. 单一职责原则 核心思想: 一个类应该只有一个引起变化的原因。 详细解释:一个类只负责一项职责或功能。如果一個类承担的功能过多,就等于把这些职责耦合在一起,一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。 比喻: 一家餐厅,厨师负责做饭,服务员负责点菜和上菜,清洁工负责打扫。如果他们职责混杂,效率就会低下。 违反示例: 一个 UserService 类,既负责用户信息的增删改查,又负责将用户数据导出为PDF报表,还负责发送邮件通知。 修正: 将 UserService 拆分为 UserService(用户业务逻辑)、UserReportGenerator(报表生成)和 EmailService(邮件服务)。 2. 开闭原则 核心思想: 软件实体(类、模块、函数等)应该对扩展开放,对修改关闭。 详细解释: 当需求发生变化时,我们应该通过添加新的代码来扩展功能,而不是修改已有的、已经工作正常的代码。这是最重要的原则,是很多设计模式的目标。 比喻: 一台电脑,你可以扩展USB设备(鼠标、键盘、硬盘),而无需为了支持新设备而拆开主机修改主板。 违反示例: 一个 AreaCalculator 类,有一个 calculate 方法,里面用 if-else 来判断是圆形还是矩形来计算面积。如果要增加三角形,就必须修改这个类的代码。 修正: 定义一个 Shape 接口,包含 calculateArea 方法。让 Circle 和 Rectangle 类实现这个接口。AreaCalculator 只需遍历 Shape 列表调用其方法即可。要新增三角形,只需创建 Triangle 类实现 Shape,无需修改任何现有类。 3. 里氏替换原则 核心思想: 所有引用基类的地方必须能透明地使用其子类的对象。 详细解释: 子类必须能够完全替代它们的父类,而不产生任何错误或意外的行为。也就是说,子类只能在保持原有行为的基础上进行扩展,而不能覆盖或改变父类的核心行为。 比喻: 你父亲会开车,你作为儿子继承了他,你也会开车(保持了父亲的行为),但你可能会开得更快或者还会修车(扩展),你绝不能把“开车”这个行为重定义为“游泳”。 违反示例: Rectangle 类有 setWidth 和 setHeight 方法。Square 类继承 Rectangle,并重写了 setWidth 和 setHeight,使其同时设置宽和高。那么,一个接收 Rectangle 参数并调整其宽高的函数,如果传入一个 Square 对象,就会得到错误的结果。 修正: 重新考虑继承关系,或者让 Rectangle 和 Square 都实现一个 Shape 接口,而不是使用继承。 4....

2025年10月13日 · 1 min · Leanku

MySQL 中主要的日志类型

MySQL 中主要的日志类型 MySQL 提供了多种日志类型,每种都有其特定的目的和格式。理解这些日志对于数据库管理、性能调优、数据恢复和故障排查至关重要。 下面我将详细介绍 MySQL 中主要的日志类型及其格式 总结概览 日志类型 主要目的 格式 是否默认开启 错误日志 记录 MySQL 启动、运行、停止时的错误、警告和提示信息。 文本格式 是 二进制日志 记录所有更改数据的语句,用于主从复制和数据恢复。 STATEMENT, ROW, MIXED 否 (8.0默认开启) 通用查询日志 记录所有到达 MySQL 的客户端连接和执行的语句。 文本格式 / CSV 格式 否 慢查询日志 记录执行时间超过指定阈值的查询,用于性能优化。 文本格式 / CSV 格式 否 重做日志 InnoDB 特有的,用于保证事务的持久性和崩溃恢复。 物理格式(二进制) 是 回滚日志 InnoDB 特有的,用于保证事务的原子性和 MVCC。 逻辑格式 是 详细解析 1. 错误日志 这是 DBA 首先需要查看的日志,当数据库出现任何异常时,它通常是排查问题的起点。 内容:启动/关闭信息、错误信息、警告信息、在复制环境中从服务器线程的启动信息等。 格式:纯文本格式,易于阅读。 配置参数: log_error:指定错误日志文件的位置。 示例内容: 2023-10-27T08:00:00.000000Z 0 \[Note\] Server started. 2023-10-27T08:01:23.456789Z 5 \[Warning\] Aborted connection 5 to db: 'test' user: 'root' host: 'localhost' 2....

2025年10月13日 · 2 min · Leanku

微服务治理-API网关

微服务治理-API网关 API Gateway 是微服务系统的统一入口层,负责请求路由、协议转换、安全控制、流量治理与聚合编排,是连接外部世界与内部微服务体系的核心枢纽。 一、介绍(Introduction) 1.1 为什么需要 API Gateway? 在没有网关之前: 问题 1:客户端需要知道所有服务地址 前端 / App 直接耦合后端服务拓扑。 问题 2:安全无法统一控制 每个服务都要: 鉴权 权限 限流 黑名单… 问题 3:跨服务调用暴露内部结构 问题 4:接口碎片化 一个业务页面可能需要多个服务,前端要请求 4~10 次 API。 1.2 API Gateway 的作用 Client │ ▼ API Gateway │ ├── User Service ├── Order Service ├── Payment Service └── Inventory Service 网关成为: 唯一入口 1.3 API Gateway 解决什么问题? 1. 统一入口 如:所有请求:https://api.xxx.com/* 2. 路由转发 /api/user → user-service、 /api/order → order-service...

2025年09月15日 · 2 min · Leanku

微服务治理-服务监控

微服务治理-服务监控 服务监控(Metrics Monitoring)用于对系统运行状态进行持续量化观测,通过指标数据(QPS、RT、错误率、资源使用率等)实现对微服务系统健康状况的实时评估与告警。 一、介绍 1.1 为什么需要监控? 链路追踪解决的是:“这一次请求为什么慢?” 但通常还需要知道:“整个系统现在健康吗?” 比如:系统很卡问题 你需要判断: 是 CPU 高了? 是数据库慢了? 是某个接口爆了? 还是流量暴涨? 1.3 监控解决什么问题? 一句话总结: 把系统运行状态数字化 + 可视化 + 可告警 核心能力: 实时状态 历史趋势 异常检测 自动告警 容量规划 1.4 三大核心指标类型 System Metrics(系统指标) Application Metrics(应用指标) Business Metrics(业务指标) 二、核心指标(Metrics) 2.1 系统指标(System Metrics) 关注机器层面: CPU 使用率 内存使用率 磁盘 IO 网络流量 2.2 应用指标(Application Metrics) 关注服务本身: QPS(每秒请求数) RT(响应时间) 错误率(Error Rate) 并发连接数 2.3 业务指标(Business Metrics) 关注业务结果: 下单成功率 支付成功率 注册转化率 GMV 三、应用 Prometheus + Grafana + Alertmanager轻量级监控告警系统

2025年09月15日 · 1 min · Leanku

微服务治理-服务调用

微服务治理-服务调用 微服务拆分之后,服务之间不再是进程内方法调用,而是通过网络进行通信。服务调用(Service Communication)就是研究不同服务之间如何安全、高效、可靠地进行数据交换。 一、介绍 1.1 为什么需要服务调用? 在单体架构中:只掉调用方法,比如 $user = $this->userService->getUser(1); 只是一次普通的方法调用(Method Call)。 没有网络、没有序列化、没有超时、没有连接 而微服务以后: 已经变成:HTTP、TCP、gRPC 所有调用都变成:网络通信(Network Communication) 1.2 微服务调用有哪些方式? 主要有三种: 1. HTTP REST 优点: 简单 通用 调试方便 缺点: JSON 较大 序列化效率较低 2. RPC 看起来像:本地方法。 实际上走的是网络。 3. gRPC 底层: HTTP/2。 Protobuf。 速度:非常快。 1.3 怎么选择调用方式? 场景 推荐 对外 API HTTP REST 内部服务调用 gRPC 旧系统兼容 HTTP 高频通信 gRPC 即: 外部使用 HTTP。 内部使用 gRPC。 二、原理 2.1 一次 HTTP 调用发生了什么? 业务代码 │ ▼ DNS / 服务发现 │ ▼ TCP 建立连接 │ ▼ 发送 HTTP 请求 │ ▼ User Service │ ▼ 返回 JSON 如果没有连接池。...

2025年09月15日 · 1 min · Leanku

微服务治理-注册中心

微服务治理-注册中心 一、介绍 1.1 什么是注册中心 注册中心可以理解为: 整个微服务系统的“通讯录”或“服务目录”。 在单体应用中: Web │ ▼ Controller │ ▼ Service │ ▼ Repository 所有模块都运行在同一个进程中,方法之间直接调用: $user = $this->userService->getUser($id); 开发者无需关心: 服务在哪里? IP 是多少? 端口是多少? 因为它们都在同一个应用中。 而在微服务架构中: User Service 10.0.0.10 │ Order Service ---------------- Product Service 10.0.0.11 10.0.0.12 现在 Order Service 想调用 User Service。 问题来了:Order Service 怎么知道 User Service 在哪里? 如果直接写 IP:虽然可以运行,但会产生很多问题。 1.2 为什么不能写死 IP? 假设:今天:User Service 10.0.0.10 后面因为扩容:User Service 10.0.0.20 或者增加服务器:10.0.0.xxx 那么: 所有调用 User Service 的项目:都要修改配置。 到底调用哪一个? 于是:...

2025年09月15日 · 2 min · Leanku

微服务治理-负载均衡

微服务治理-负载均衡 一、介绍 1.1 什么是负载均衡 负载均衡(Load Balancing)是微服务治理中的核心能力之一,它负责在多个服务实例之间合理分配请求,提高系统吞吐能力、可用性和扩展能力 假设: User Service 只有一台服务器:10.0.0.5 随着后面业务越来越大增加服务器:10.0.0.5,10.0.0.6,10.0.0.7 … 现在应该调用哪一个? 于是出现: 负载均衡(Load Balancing) 它负责: 从多个可用实例中选择一个最合适的实例。 1.2 为什么需要负载均衡? 假设:10000 个请求全部发送:10.0.0.5 导致服务宕机 结果: 10.0.0.6, 10.0.0.7 却一直空闲 负载均衡能够平均分配 1.3 负载均衡解决什么问题? 主要包括 1.流量分摊 2.提高可用性 3.方便扩容 4. 支持灰度发布 二、原理 2.1 整个调用流程 Order Service ↓ Service Discovery ↓ Registry ↓ 返回: 10.0.0.5 10.0.0.6 10.0.0.7 ↓ Load Balance ↓ 选择: 10.0.0.6 ↓ HTTP 2.2 轮询(Round Robin) 特点: 简单 公平 实现容易 缺点: 不能反映机器性能差异。 2.3 随机 优点:...

2025年09月15日 · 1 min · Leanku

微服务治理-配置中心

微服务治理-服务发现 一、介绍 1.1 什么是配置中心 在单体应用时代,我们通常这样管理配置: .env文件 但是进入微服务以后。 现在:每个服务都有自己的配置 比如REDIS_HOST需要修改,几十个服务的.env都要修改 于是就需要: 配置中心(Configuration Center) 1.2 配置中心解决什么问题? 一句话总结: 统一管理所有配置。 二、原理 2.1 配置中心整体架构 典型架构: Config Center (Nacos / Apollo) ▲ │ Read Config│ ┌────────┬─────────┼──────────┐ ▼ ▼ ▼ ▼ Gateway User Order Payment 服务:启动 读取:配置。 运行: 监听:配置变化。 2.2 配置加载流程 User Service为例 启动 ↓ 读取配置中心 ↓ 下载配置 ↓ 缓存到本地 ↓ 程序启动 2.3 动态刷新 配置修改时: 配置中心通知各个服务,自动刷新,无需重启 2.4 配置版本管理 如果修改错误:可以恢复上一版本 2.5 环境隔离 比如 开发环境DEV、测试环境TEST、预发布UAT、生产环境PROD 配置分别管理 三、主流配置中心 产品 特点 是否支持动态刷新 Nacos 注册中心 + 配置中心 ✅ Apollo 配置中心 ✅ Consul KV KV 存储 + 配置 ✅ Etcd KV 存储 ✅ Nacos最常用...

2025年09月15日 · 1 min · Leanku

微服务治理-链路追踪

微服务治理-链路追踪 链路追踪(Distributed Tracing)是微服务可观测性(Observability)的核心能力之一,用于在分布式系统中还原一次请求的完整调用路径,并定位性能瓶颈与故障点。 一、介绍 1.1 为什么需要链路追踪? 在单体应用中:一次请求在同一个进程内完成,只需要 打日志 打断点 其他调试 即可定位问题。 但在微服务架构中: Client ↓ API Gateway ↓ User Service ↓ Order Service ↓ Payment Service ↓ Inventory Service ↓ DB / MQ 一次请求变成: 跨进程 + 跨机器 + 跨网络 1.2 典型问题 问题1:不知道慢在哪里 比如 :接口很慢 但系统里有:Gateway、User、、Order… 你无法判断:到底慢在谁? 问题2:日志分散 如: Gateway logs User logs Order logs Payment logs 每个服务都有日志,但它们之间没有关联关系。 问题3:无法串联一次请求 无法确认日志是不是同一个请求? 1.3 链路追踪要解决什么问题? 把一次请求在多个微服务中的完整路径“串起来” 核心能力: 请求路径可视化 性能瓶颈定位 服务依赖分析 故障快速定位 二、原理 2.1 核心概念 链路追踪有三个核心概念:...

2025年09月15日 · 2 min · Leanku

连接池

连接池 一、概述 1.1 什么是连接池 连接池(Connection Pool)是: 预先创建一定数量的连接,并统一管理和复用这些连接,而不是每次请求都重新建立连接。 这里的"连接"不仅指数据库连接,还包括: MySQL 连接 Redis 连接 HTTP 连接 gRPC 连接 Kafka 连接 RabbitMQ 连接 本质上,只要是建立成本较高、可以复用的连接,都适合使用连接池。 1.2 为什么需要连接池 假设没有连接池: 每个请求执行流程如下: HTTP Request │ ▼ 创建 MySQL 连接 │ ▼ 执行 SQL │ ▼ 关闭连接 如果系统每秒有 5000 个请求, 服务器的大量资源都会浪费在建立连接上,而不是执行业务。 1.3 建立一个连接到底需要做什么? 以 MySQL 为例: Application │ ▼ TCP 三次握手 │ ▼ SSL/TLS(可选) │ ▼ MySQL 用户认证 │ ▼ 权限校验 │ ▼ 初始化 Session │ ▼ 返回连接对象 这整个过程远比执行一条简单 SQL 更耗时。...

2025年08月15日 · 2 min · Leanku