朱晔的互联网架构实践心得S2E1：业务代码究竟难不难写？

注意，这是个人架构实践心得的第二季的系列文章，第一季有10篇你也能够回顾。 见https://www.cnblogs.com/lovecindywang/category/1296779.html

最近我一直在思考几个问题：

• 业务代码究竟难不难写？
• 一直开发业务代码是否是彻底学不到东西？
• 5年+开发经验的老程序员的价值在哪里？
• 如何经过面试来区分业务代码开发的水平？

其实，这几个问题或多或少是相互关联的。有的时候你们也会自嘲说，“程序员接手的代码永远是烂摊子，而后本身继续在这个烂摊子上产出代码，留给又一波后人接手”。十几年来经历过十来个公司，我看了很多差的代码，也看了很多好的代码，本身产出过垃圾代码，也带领团队实现过一些自认为不错的代码。你可能会说，业务代码就是增删改查，和框架代码的难度不能比，彻底是机械劳动，其实我以为不彻底是这样，甚至彻底不是这样，我我的认为写出能跑的业务代码不难，但要写出好的业务代码实际上是挺难的，更重要的是若是系统设计的足够好，在很长一段时间内系统的可维护性是可控的，只须要简单扩展便可，若是基础打的不够好，那么项目可能就是一次性项目，下面我列出业务系统我关注的一些点，你想一想是否是有道理。

标准化

标准的项目结构

我本身很是注重搭建项目结构的起步过程，模块的划分、目录（包）的命名，我以为很是重要，若是作的足够好，别人导入项目后可能只须要10分钟就能够大概了解结构了。

一、有些名词是约定俗成的，你们一眼就能看出是啥东西的，好比：

• 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的。

二、有些名词可能就须要内部有一个统一，好比不一样的层次面向数据库，面向业务，面向UI，面向RPC须要有不一样的POJO，咱们须要明确一套对应的命名，能明确就好，好比下面的这些POJO咱们其实挺难分辨其用途的，须要进行规范，而且放置于匹配的目录结构中：

• CreateOrderRequest / CreateOrderResponse
• CreateOrderParam / CreateOrderDto

咱们能够约定第一组用于服务自己访问外部（的Rpc服务也好，REST服务也好），第二组用于服务自己对外提供的Web Api，好比：

• controllers
  • OrderController
    • queryOrder()
    • createOrder()
  • QueryOrderParam
  • QueryOrderDto
  • CreateOrderParam
  • CreateOrderDto
• rpcs
  • UserService
    • login()
    • register()
  • 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;
}

咱们能够这么和客户端的开发来明确：
一、即便遇到错误，Http状态码仍是200，Http状态码若是是500或是404的话那必定是网关层面的错误了，这个错误不是后端服务返回的
二、在Http状态码仍是200的时候表明收到了后端的返回，前端去按照ApiResult以Json格式反序列化Http Body的报文
三、而后查看success（若是没success也行，咱们能够约定code是200就是成功），若是是success表明后端服务成功处理了请求，若是不成功，则根据后端给的错误代码映射表根据code进行处理或直接提示message中的内容。注意，这里的success只表明后端是否成功处理了请求，不表明请求表明的业务逻辑是否成功处理。举一个例子，若是这个请求是异步支付请求，那么success==true表明前端给的参数都正确，后端正确接受了支付申请，不表明支付成功
四、在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年+经验丰富的程序员应当有能力开一个好头，或者说愿意在老代码上去作一些改变，不然你的价值在哪里呢？

本文只是展开了一些想到的内容，每一点都有不少东西能够写，也没时间一些子展开说太多，这些细节留在从此的文章慢慢展开了。