21 | 代码重复:搞定代码重复的三个绝招
- 利用工厂模式 + 模板方法模式,消除 if…else 和重复代码
- 假设要开发一个购物车下单的功能,针对不同用户进行不同处理:
- 普通用户需要收取运费,运费是商品价格的 10%,无商品折扣;
- VIP 用户同样需要收取商品价格 10% 的快递费,但购买两件以上相同商品时,第三件开始享受一定折扣;
- 内部用户可以免运费,无商品折扣。
针对上面问题:我们就利用工厂模式 + 模板方法模式,不仅消除了重复代码,还避免了修改既有代码的风险。这就是设计模式中的开闭原则:对修改关闭,对扩展开放。
-
利用注解 + 反射消除重复代码 有code展示的,可以看看的
-
利用属性拷贝工具消除重复代码
- 对于三层架构的系统,考虑到层之间的解耦隔离以及每一层对数据的不同需求,通常每一层都会有自己的 POJO 作为数据实体。比如,数据访问层的实体一般叫作 DataObject 或 DO,业务逻辑层的实体一般叫作 Domain,表现层的实体一般叫作 Data Transfer Object 或 DTO。
除了模板方法设计模式是减少重复代码的一把好手,观察者模式也常用于减少代码重复(并且是松耦合方式)
22 | 接口设计:系统间对话的语言,一定要统一
我们知道,开发一个服务的第一步就是设计接口。接口的设计需要考虑的点非常多,比如接口的命名、参数列表、包装结构体、接口粒度、版本策略、幂等性实现、同步异步处理方式,缓存策略 等。这其中,和接口设计相关比较重要的点有三个,分别是包装结构体、版本策略、同步异步处理方式。今天,我就通过我遇到的实际案例,和你一起看看因为接口设计思路和调用方理解不一致所导致的问题,以及相关的实践经验。
-
接口的响应要明确表示接口的处理结果 — 了解 RestControllerAdvice ResponseBodyAdvice 使用 自定义返回格式场景
-
要考虑接口变迁的版本控制策略 – 自定义 RequestMappingHandlerMapping,RequestMappingHandlerMapping 的作用,是根据类或方法上的 @RequestMapping 来生成 RequestMappingInfo 的实例
- 第一,版本策略最好一开始就考虑。
- 第二,版本实现方式要统一。
- 自定义 @APIVersion 注解实现 APIVersionHandlerMapping
- 问题 2:在“要考虑接口变迁的版本控制策略”这一节的例子中,我们在类或方法上标记 @APIVersion 自定义注解,实现了 URL 方式统一的接口版本定义。你可以用类似的方式(也就是自定义 RequestMappingHandlerMapping),来实现一套统一的基于请求头方式的版本控制吗? RequestCondition
-
接口处理方式要明确同步还是异步:所以,这种优化接口响应速度的方式并不可取,更合理的方式是,让上传接口要么是彻底的同步处理,要么是彻底的异步处理
23 | 缓存设计:缓存可以锦上添花也可以落井下石
使用 Redis 做缓存虽然简单好用,但使用和设计缓存并不是 set 一下这么简单,需要注意缓存的同步、雪崩、并发、穿透等问题。今天,我们就来详细聊聊。 原文讲的很不错
- 不要把 Redis 当作数据库
- 常用的数据淘汰策略
- 注意缓存雪崩问题
- 注意缓存击穿问题(双重检查)
- 注意缓存穿透问题
- 注意缓存数据同步策略
24 | 业务代码写完,就意味着生产就绪了?
- 那么,生产就绪需要做哪些工作呢?我认为,以下三方面的工作最重要。
- 第一,提供健康检测接口
- 第二,暴露应用内部信息
- 第三,建立应用指标 Metrics 监控。
- 准备工作:配置 Spring Boot Actuator
- 健康检测需要触达关键组件 (线程池,redis等) HealthIndicator CompositeHealthContributor
- 对外暴露应用内部重要组件的状态
- 指标 Metrics 是快速定位问题的“金钥匙”
介绍了如何使用 Spring Boot Actuaor 实现生产就绪的几个关键点,包括健康检测、暴露应用信息和指标监控。
25 | 异步处理好用,但非常容易用错
异步处理是互联网应用不可或缺的一种架构模式,大多数业务项目都是由同步处理、异步处理和定时任务处理三种模式相辅相成实现的。
不过,异步处理虽然好用,但在实现的时候却有三个最容易犯的错,分别是异步处理流程的可靠性问题、消息发送模式的区分问题,以及大量死信消息堵塞队列的问题。
- 异步处理需要消息补偿闭环
- 注意消息模式是广播还是工作队列
- 别让死信堵塞了消息队列
26 | 数据存储:NoSQL与RDBMS如何取长补短、相辅相成?
- 取长补短之 Redis vs MySQL
- 取长补短之 InfluxDB vs MySQL
- 取长补短之 Elasticsearch vs MySQL
- 结合 NoSQL 和 MySQL 应对高并发的复合数据库架构