大话后端开发的奇淫技巧大集合

Hi，大家好，很荣幸有这个机会可以通过写博文的方式，把这些年在后端开发过程中总结沉淀下来的经验和设计思路分享出来

模块化设计

根据业务场景，将业务抽离成独立模块，对外通过接口提供服务，减少系统复杂度和耦合度，实现可复用，易维护，易拓展

项目中实践例子：

Before：

在返还购APP里有个【我的红包】的功能，用户的红包数据来自多个业务，如：邀请新用户注册领取100元红包，大促活动双倍红包，等各种活动红包，多个活动业务都实现了一套不同规则的红包领取和红包奖励发放的机制，导致红包不可管理，不能复用，难维护难拓展

After：

• 重构红包业务

• 红包可后台管理

  • 红包信息管理，可添加，可编辑，可配置红包使用的规则，可管理用户红包

• 红包奖励发放统一处理

• 应用业务的接入只需要专注给用户进行红包发放即可

设计概要

红包模块

Before VS After

Before VS After

产品有时提出的业务需求没有往这方面去考虑，结合场景和未来拓展需要，在需求讨论的时候提出模块化设计方案，并可以协助产品进行设计

通用服务抽离

在项目开发中经常会遇到些类似的功能，但是不同的开发人员都各自实现，或者因为不能复用又重新开发一个，导致了类似功能的重复开发，所以我们需要对能够抽离独立服务的功能进行抽离，达到复用的效果，并且可以不断拓展完善，节约了后续开发成本，提高开发效率，易于维护和拓展

项目中实践例子：

Before

在业务中经常需要对用户进行信息通知，如：短信定时通知，APP消息推送，微信通知，等

开发人员在接到需求中有通知功能的时候没有考虑后续拓展，就接入第三方信息通知平台，然后简单封装个信息通知方法，后续也有类似信息通知需求的时候，另一个开发人员发现当前这个通知方法无法满足自己的需求，然后又自己去了解第三方平台重新封装了通知方法，或者后续需求加了定时通知的功能，开发人员针对业务去实现了个定时通知功能，但是只能自己业务上使用，其他业务无法接入，没有人去做这块功能的抽离，久而久之就演变成功能重复开发，且不易于维护和拓展

After

接触到这种可以抽离通用服务需求的时候，就会与产品确认这种需求是否后续会存在类似的需要，然后建议这把块需求抽离成通用服务，方便后续维护和拓展

设计概要

通用服务

Before VS After

通用服务

架构独立服务

项目开发过程中有些需求是与所在项目业务无关，如：收集用户行为习惯，收集商品曝光点击，数据收集提供给BI进行统计报表输出，公用拉新促活业务（柚子街和返还公用），类似这种需求，我们结合应用场景，考虑服务的独立性，以及未来的拓展需要，架构独立项目进行维护，在服务器上独立分布式部署不影响现有主业务服务器资源

项目中实践例子：

架构用户行为跟踪独立服务，在开发前预估了下这个服务的请求量，并会有相对大量的并发请求

架构方案：

• 项目搭建选择用nodejs来做服务端

  • 单进程，基于事件驱动和无阻塞I/O，所以非常适合处理并发请求

  • 负载均衡：cluster模块/PM2

• 架构nodejs独立服务

• 提供服务接口给客户端

• 接口不直接DB操作，保证并发下的稳定性

• 数据异步入库

  • 通过程序把数据从：消息队列=>mysql

• nodejs+express+redis(list)/mq+mysql

用户行为跟踪服务的服务架构图

独立服务

高并发优化

高并发除了需要对服务器进行垂直扩展和水平扩展之外，作为后端开发可以通过高并发优化，保证业务在高并发的时候能够稳定的运行，避免业务停滞带来的损失，给用户带来不好的体验

缓存：

• 服务端缓存

  • 内存数据库的分配的内存容量有限，合理规划使用，滥用最终会导致内存空间不足

  • 缓存数据需要设置过期时间，无效/不使用的数据自动过期

  • 压缩数据缓存数据，不使用字段不添加到缓存中

  • 根据业务拆分布式部署缓存服务器

  • 优先缓存

  • 只读缓存

  • 穿透DB问题

  • 更新/失效删除

  • redis

  • memcache

  • 内存数据库

  • 方式

  • 注意

• 客户端缓存

  • 更新频率不高的数据

  • 客户端请求数据接口，缓存数据和数据版本号，并且每次请求带上缓存的数据版本号

  • 服务端根据上报的数据版本号与数据当前版本号对比

  • 版本号一样不返回数据列表，版本号不一样返回最新数据和最新版本号

  • 方式

  • 场景：

服务端缓存架构图

缓存

异步

异步编程

• 方式：

  • 多线程编程

  • nodejs异步编程

• 场景：

  • 参与活动成功后进行短信通知

  • 非主业务逻辑流程需要的操作，允许异步处理其他辅助业务，等

业务异步处理

• 方式

  • 业务接口将客户端上报的数据PUSH到消息队列（MQ中间件），然后就响应结果给用户

  • 编写独立程序去订阅消息队列，异步处理业务

• 场景：

  • 参与成功后委婉提示：预计X天后进行红包发放

  • 大促活动整点抢限量红包

  • 并发量比较大的业务，且没有其他更好的优化方案，业务允许异步处理

• 注意：

  • 把控队列消耗的进度

  • 保证幂等性和数据最终一致性

• 缺陷：

  • 牺牲用户体验

【业务异步处理】架构图

作者：SFLYQ
链接：https://www.jianshu.com/p/fb6c62f35bc6