业务代码究竟难不难写?
The following article is from 随缘主人的园子 Author 朱晔1983
最近我一直在思考几个问题:
业务代码究竟难不难写?
一直开发业务代码是不是完全学不到东西?
5年+开发经验的老程序员的价值在哪里?
如何通过面试来区分业务代码开发的水平?
其实,这几个问题或多或少是相互关联的。有的时候大家也会自嘲说,“程序员接手的代码永远是烂摊子,然后自己继续在这个烂摊子上产出代码,留给又一波后人接手”。十几年来经历过十来个公司,我看了不少差的代码,也看了不少好的代码,自己产出过垃圾代码,也带领团队实现过一些自认为不错的代码。
你可能会说,业务代码就是增删改查,和框架代码的难度不能比,完全是机械劳动,其实我觉得不完全是这样,甚至完全不是这样,我个人认为写出能跑的业务代码不难,但要写出好的业务代码其实是挺难的,更重要的是如果系统设计的足够好,在很长一段时间内系统的可维护性是可控的,只需要简单扩展即可,如果基础打的不够好,那么项目可能就是一次性项目,下面我列出业务系统我关注的一些点,你想想是不是有道理。
标准化
标准的项目结构
我自己非常注重搭建项目结构的起步过程,模块的划分、目录(包)的命名,我觉得非常重要,如果做的足够好,别人导入项目后可能只需要10分钟就可以大概了解结构了。
1、有些名词是约定俗成的,大家一眼就能看出是啥东西的,比如:
controllers
services
configs
utils
commons
jobs
比较重要的是确定先进行分类再分业务,还是先分业务再分类,在代码里混用这两种风格的结构就会很混乱:
controllers
order
user
jobs
order
user
order
services
mappers
user
services
mappers
对于直筒的三层架构的纯数据表驱动的代码我建议第一层是分类,第二层是业务功能:
看一眼controllers目录我们知道项目对外的Api能力
看一眼services目录我们知道项目的逻辑复杂度
看一眼mappers目录我们知道项目的表结构
对于有一些项目,不一定每一个逻辑都涉及到三层架构,数据流量比较复杂,我建议是按照业务功能先来分,下一层视情况也不一定完全是需要按照组件类型分二级目录,也可以是按功能来分:
core
storage
service
dispatcher
engine
context
callback
gateway
handler
notification
sms
push
对于这种目录结构一眼望去就能知道大概项目数据流和架构了,core对内,dispatcher做分发的感觉,callback是外部来的回调数据,notification是通知外部的数据流。这种数据流向复杂的项目,使用这种结构会比前一种合理的多,因为我们需要先关注数据流,而不是三层结构的层次,甚至对于core、dispatcher、notification我们知道其实是没有controller的。
2、有些名词可能就需要内部有一个统一,比如不同的层次面向数据库,面向业务,面向UI,面向RPC需要有不同的POJO,我们需要明确一套对应的命名,能明确就好,比如下面的这些POJO我们其实挺难分辨其用途的,需要进行规范,并且放置于匹配的目录结构中:
CreateOrderRequest / CreateOrderResponse
CreateOrderParam / CreateOrderDto
我们可以约定第一组用于服务本身访问外部(的Rpc服务也好,REST服务也好),第二组用于服务本身对外提供的Web Api,比如:
controllers
queryOrder()
createOrder()
OrderController
QueryOrderParam
QueryOrderDto
CreateOrderParam
CreateOrderDto
rpcs
login()
register()
UserService
LoginRequest
LoginResponse
RegisterRequest
RegisterResponse
services
OrderService
OrderServiceImpl
OrderEntity
storages
OrderMapper
OrderModel
总之,虽然可能10+人在维护相同的项目,目录结构的风格、命名、专用名词的使用一定要统一。
统一的框架
这个需要在开展项目之前明确下来,我见过有项目中同时使用了Spring MVC和Jersey做Web API,同时使用了Spring Scheduler和Quartz做任务调度。最好是项目开展前明确框架的版本并且搭建好项目脚手架,大概涉及:
Web API / Web MVC
Job Scheduler
Micro Service
Config Center
Redis Client
Data Access
Entity Mapper
MQ Client
当然,我们也可以独立出依赖管理的项目,专门由独立模块进行依赖版本管理。最差也要在Wiki上进行明确。
统一的API
如果项目涉及到对外提供API,那么非常有必要在初期就规范API的框架定义,涉及到:
包装类
Result<T>
的定义(见过一个项目用了三种包装类的)以及遇到错误的情况下,Http状态码的体现 比如这样的包装类格式:
public class ApiResult<T> {
boolean success;
String code;
String message;
String path;
long time;
T data;
}
我们可以这么和客户端的开发来明确:
1、即使遇到错误,Http状态码还是200,Http状态码如果是500或是404的话那一定是网关层面的错误了,这个错误不是后端服务返回的
2、在Http状态码还是200的时候代表收到了后端的返回,前端去按照ApiResult以Json格式反序列化Http Body的报文
3、然后查看success(如果没success也行,我们可以约定code是200就是成功),如果是success代表后端服务成功处理了请求,如果不成功,则根据后端给的错误代码映射表根据code进行处理或直接提示message中的内容。注意,这里的success只代表后端是否成功处理了请求,不代表请求代表的业务逻辑是否成功处理。举一个例子,如果这个请求是异步支付请求,那么success==true代表前端给的参数都正确,后端正确接受了支付申请,不代表支付成功
4、在success==true的情况下再去解析data中的内容,拿取客户端需要的信息,还是前面的例子,
data里可以是{"orderStatus":"PROCESSING", "orderId":"1234"}
,这个才是真正业务逻辑的数据和状态,success并不代表订单支付操作就是成功的,也可能是处理中的状态
所以这是几个层次的事情,
Http Status->ApiResult.status->ApiResult.data.orderStatus
加解密规范和签名规范 Api的加密解密以及签名最好在设计的时候就考虑进去,而且要仔细斟酌,否则以后很难变更,特别Api的使用方是客户端的情况,客户端很难轻易强更。如果做SAAS服务,建议参考大厂的规范,比如亚马逊AWS的API规范或阿里云API的规范,不建议自己造轮子,大厂做的API规范都是经过安全方面的专家深度思考的。
版本管理规范(比如Url path路由还是Http header路由) 如果使用了老版本的话,是否需要在返回内容中提示新版本的Url、版本号、老版本最后维护时间呢?这个就不展开了
所以统一Api这个事情不仅仅是Api的格式还涉及到安全处理、版本处理、客户端操作方式等等。对于一些需要服务端驱动客户端的业务(UI逻辑动态)来说,我们可以定义一套更复杂的ApiResult,让服务端告知客户端这个时候应该是提示还是跳转还是返回等等。
统一的源码工作模式
现在大家都使用Git,分支如何管理每一个公司(在Gitflow的基础上)都会略有不同,也需要和大家明确:
分支的定义(master、develop、release、hotfix、feature)
分支命名规范
checkout、merge request流程
提测流程
上线流程
Hotfix流程
别小这个,虽然这个和代码质量和架构无关,但是梳理清楚可以:
提高开发和测试的工作效率,人多也乱
减少甚至杜绝代码管理导致的线上事故
让项目管理者和架构师可以明确什么代码现在在哪里
方便运维处理发布和回滚
让项目的开发可以灵活适应多变的需求
容错性
见过一些项目在实现业务代码的时候是不考虑任何异常处理、事务处理、锁处理的,在流量小无并发的情况下,这些项目不容易爆发出严重的问题,基本能用。但是对于高并发的项目或将来可能会高速发展的项目,如果不考虑这些问题会死的很难看。
我们来想一下,如果现在在设计一个订单服务,如果因为网络问题、并发问题导致数据错乱、服务中断的可能在千分之一,如果一个业务一天只有1000次请求,1天才遇到这样1次问题,即使遇到了问题用户也不一定会来反馈,即使来反馈往往客服也能通过后台取消订单等操作来处理,这个问题不会爆发出来,如果一天的单量是1000万,那么每天可能就会有10000单异常的订单,这个可能就超过了客服的处理能力了。
很少有项目真正100%完全做好了所有细节,只不过往往是因为量小得不到大家的重视罢了。但我们想一下,如果遇到数据库或中间件级别大规模故障的情况下,如果一致性处理的不好,那么数据库恢复后可能会留下一大堆异常数据需要修复,如果处理的好,业务数据不会错乱,数据库恢复后业务马上可以恢复。在遇到事故的时候,系统这方面的设计功力就体现出来了。
一致性处理
在实现代码的时候需要考虑如下事情:
本地事务处理:见过一些代码完全不考虑事务,或者是只是知其然使用
@Transactional
,但是方法内部完全catch了所有异常的情况事务包含的方法块
嵌套事务、事务传播
什么时候遇到什么异常应该回滚
@Transactional
是否真正生效了?外部服务调用的事务问题
调用外部服务出现异常的时候,本地事务怎么处理
调用的外部服务是否允许重试(幂等调用)
调用外部服务出现未知结果后,怎么进行补偿
补偿是否有上限,是否存在死信数据卡死补偿的情况?
如果有2+外部服务连同本地数据库存储都需要有事务性,怎么实现
数据重复和顺序问题
先本地事务提交还是先调用外部接口(如果先调用外部接口,可能会遇到外部回调的时候本地事务还没提交找不到数据的情况)
从MQ收到的消息顺序问题怎么解决?
重新入MQ的延迟消息或重试消息乱序是否会有问题?
对外提供的Api或回调方法是否支持幂等?
锁的问题
哪个层面做锁?服务层分布式锁还是数据库层面锁?
乐观锁还是悲观锁?
你确信你的Redis锁方案是可靠的吗?
你是否知道多少请求再排队等待,又是为什么?
这些要做好真的很难,每一步都需要认证考虑,但是很遗憾见过的很多具有复杂业务的代码,在Service中一连串调用了N个外部服务进行写操作,方法内也实现了N个表的写操作,即不考虑外部服务的事务和补偿问题,本地也没有事务控制,出了错只是打印了堆栈然后客户端看到的是一个服务器忙。
异常处理
异常处理不仅仅是狭义上遇到了Exception怎么去处理,还有各种业务逻辑遇到错误的时候我们怎么去处理。就拿记日志这一件事情来说:
WARN和ERROR的选择需要好好考虑,WARN一般我倾向于记录可自恢复但值得关注的错误,ERROR代表了不能自己恢复的错误。对于业务处理遇到问题用ERROR不合理,对于catch到了异常也不是全用ERROR。
记录哪些信息,最好打印一定的上下文(用户Id、订单Id、外部传来的关键数据)而不仅仅是打印线程栈。
记录了上下问信息,是否要考虑日志脱敏问题?可以在框架层面实现,比如自定义实现logback的
ClassicConverter
我们知道catch到了异常或遇到了业务错误,我们除了记录日志还有很多选择,也需要认真考虑什么时候应该做什么:
直接返回
抛出异常
重试处理
恢复处理
熔断处理
降级处理
甚至关闭业务
这又涉及到了弹力设计的话题,我们的系统往往会对接各种外部服务、Api,大部分服务都不会有SLA,即使有在大并发下我们也需要考虑外部服务不可用对自己的影响,会不会把自己拖死。我们总是希望:
尽可能以小的代价通过尝试让业务可以完成
如果外部服务基本不可用,而我们又同步调用外部服务的话,我们需要进行自我保护直接熔断,否则在持续的并发的情况下自己就会垮了
如果外部服务特别重要,我们往往会考虑引入多个同类型的服务,根据价格、服务标准做路由,在出现问题的时候自动降级
架构设计
表
表的设计和Api的定义类似,属于那种开头没有开好,以后改变需要花10x代价的,我知道,一开始在业务不明确的情况下,设计出良好的一步到位的表结构很困难,但是至少我们可以做的是有一个好的标准:
统一的附加字段,create_time,update_time,version等
表的命名标准,比如
[domain]_[tablename]_[tabletype]
字段类型、长度标准
虽没有外键,但是外表关联字段和主表字段的命名标准
_id还是_no等字段命名的区别
除了标准,尽可能需要结合业务以及业务可能的扩展思考一下:
1:N的可能性,是有1就足够了,还是一开始就要设计1:N的层次关系
如果表字段可能会很多,业务变化多,是否考虑1:1甚至1:N的扩展表,把扩展字段从主表分开
表的领域职责,表可能也会分上游、中游、下游,什么字段应该在哪里太重要了(我觉得表的领域相当于之前提到的项目结构中的包的分类,这个最好一开始定义清楚)
关联表字段冗余冗余到什么程度,冗余字段的同步
枚举的维护方式,是否考虑字典表?
对于表结构文档,我觉得列出字段类型、长度、说明是不够的,如果能结合业务代码梳理清楚下面这些,那这个文档就是真正有价值的表结构文档:
记录由哪个业务模块创建
数据重要程度
数据归档方案
字段数据源头
字段会由谁更改
字段可能会在哪里缓存
设计模式
我想90%的业务项目都是所谓的三层结构,Web层处理参数调用Service层做DB层的聚合,Db层基本就是代码生成或Orm框架补充少量的手写SQL。对于这样的项目,大部分人认为是没有设计的,也不需要设计。我认为那是因为没有好好思考:
在我们写下if-else的时候,我们就可以考虑使用抽象类+具体实现类的方式来替代
在实现层次化业务处理的时候,就可以考虑使用Filter或职责链模式来实现
在封装外部Api的时候与其每次都写一套解析逻辑,我们是否考虑进行动态封装呢
在数据改变后我们要记录改版轨迹,与其复制粘贴是否考虑过发布订阅模式
说白了就是利用各种设计模式和OO思想,来尽可能在业务变化需要扩展的时候:
只是新增代码而不是修改代码
尽可能减少重复代码复制粘贴
尽可能让同类代码都呆在一起
尽可能让直筒式的代码有层次
往大了说
在一个公司层面,如果有几十个,几百个业务项目,我们看这个公司的技术水平到了什么程度,我个人认为不仅仅是用了什么新技术,而是是否:
具有统一的开发、服务框架
具有统一的运维、监控、中间件、测试平台
具有清晰的纵向领域划分
具有清晰的横向基础平台服务和基础业务服务
具有统一的代码工作模式
最简单的一个例子,一个业务从前到后跨10个事业部,100个服务,实现灰度测试,想想这件事情有多难?整个公司层面要实现步调一致的这些东西还确实很难,不仅仅是技术能力的体现,没有良好的组织架构,人心不齐,恐怕这些无法实现,实现了也无法推广,推广了也无法持续……当然,这些已经超出个人能做的了,作为程序员的我们应该从我做起,认真考虑前面提到的这些问题,至少在项目内部做良好的设计。
再来看看文首的问题,你看,虽然只是写业务代码,如果要写的足够好,必须要了解设计模式、理解各种弹力设计、理解事务、熟悉框架、了解中间件原理,怎么可能学不到东西,要实现健壮的业务代码,其实很难,要考虑的东西太多了,如果说写框架我们需要考虑不同的使用方和使用环境,这很难,写业务代码我们要考虑到千奇百怪的使用行为,要考虑到层次不起的对接方,这不比写框架简单。对于5年+经验丰富的程序员应当有能力开一个好头,或者说愿意在老代码上去做一些改变,否则你的价值在哪里呢?
本文只是展开了一些想到的内容,每一点都有很多东西可以写,也没时间一些子展开说太多,这些细节留在今后的文章慢慢展开了。
热烈庆祝本文作者朱老师在极客时间的专栏订阅破万!!!
……
关注本公众号,欢迎订阅。
技术琐话
以分布式设计、架构、体系思想为基础,兼论研发相关的点点滴滴,不限于代码、质量体系和研发管理。本号由坐馆老司机技术团队维护。