Java业务开发常见错误100例------②设计篇 (7讲)

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 应对高并发的复合数据库架构

答疑篇：设计篇思考题答案合集