mirror of
https://github.com/chai2010/advanced-go-programming-book.git
synced 2025-05-27 23:12:20 +00:00
129 lines
7.5 KiB
Markdown
129 lines
7.5 KiB
Markdown
# 5.8. interface 和 table-driven 开发
|
||
|
||
在 web 项目中经常会遇到外部依赖环境的变化，比如：
|
||
|
||
1. 公司的老存储系统年久失修，现在已经没有人维护了，新的系统上线也没有考虑平滑迁移，但最后通牒已下，要求 N 天之内迁移完毕。
|
||
2. 平台部门的老用户系统年久失修(怎么都是年久失修，摔！)，现在已经没有人维护了，真是悲伤的故事。新系统上线没有考虑兼容老接口，但最后通牒已下，要求 N 个月之内迁移完毕。
|
||
3. 公司的老消息队列人走茶凉，年久失修(汗)，新来的技术精英们没有考虑向前兼容，但最后通牒已下，要求半年之内迁移完毕。
|
||
|
||
嗯，所以你看到了，我们的外部依赖总是为了自己爽而不断地做升级，且不想做向前兼容，然后来给我们下最后通牒。如果我们的部门工作饱和，领导强势，那么有时候也可以倒逼依赖方来做兼容。但世事不一定如人愿，即使我们的领导强势，读者朋友的领导也还是可能认怂的。
|
||
|
||
我们可以思考一下怎么缓解这个问题。
|
||
|
||
## 业务系统的发展过程
|
||
|
||
互联网公司只要可以活过三年，工程方面面临的首要问题就是代码膨胀。系统的代码膨胀之后，可以将系统中与业务本身流程无关的部分做拆解和异步化。什么算是业务无关呢，比如一些统计、反作弊、营销发券、价格计算、用户状态更新等等需求。这些需求往往依赖于主流程的数据，但又只是挂在主流程上的旁支，自成体系。
|
||
|
||
这时候我们就可以把这些旁支拆解出去，作为独立的系统来部署、开发以及维护。这些旁支流程的时延如若非常敏感，比如用户在界面上点了按钮，需要立刻返回(价格计算、支付)，那么需要与主流程系统进行 RPC 通信，并且在通信失败时，要将结果直接返回给用户。如果时延不敏感，比如抽奖系统，结果稍后公布的这种，或者非实时的统计类系统，那么就没有必要在主流程里为每一套系统做一套 RPC 流程。我们只要将下游需要的数据打包成一条消息，传入消息队列，之后的事情与主流程一概无关(当然，与用户的后续交互流程还是要做的)。
|
||
|
||
通过拆解和异步化虽然解决了一部分问题，但并不能解决所有问题。随着业务发展，单一职责的模块也会变得越来越复杂，这是必然的趋势。一件事情本身变的复杂的话，这时候拆解和异步化就不灵了。我们还是要对事情本身进行一定程度的封装抽象。
|
||
|
||
## 使用函数封装业务流程
|
||
|
||
最基本的封装过程，我们把相似的行为放在一起，然后打包成一个一个的函数，让自己杂乱无章的代码变成下面这个样子：
|
||
|
||
```go
|
||
func BusinessProcess(ctx context.Context, params Params) (resp, error){
|
||
ValidateLogin()
|
||
ValidateParams()
|
||
AntispamCheck()
|
||
GetPrice()
|
||
CreateOrder()
|
||
UpdateUserStatus()
|
||
NotifyDownstreamSystems()
|
||
}
|
||
```
|
||
|
||
不管是多么复杂的业务，系统内的逻辑都是可以分解为 step1 -> step2 -> step3 ... 这样的流程的。
|
||
|
||
每一个步骤内部也会有复杂的流程，比如：
|
||
|
||
```go
|
||
func CreateOrder() {
|
||
ValidateDistrict() // 判断是否是地区限定商品
|
||
ValidateVIPProduct() // 检查是否是只提供给 vip 的商品
|
||
GetUserInfo() // 从用户系统获取更详细的用户信息
|
||
GetProductDesc() // 从商品系统中获取商品在该时间点的详细信息
|
||
DecrementStorage() // 扣减库存
|
||
CreateOrderSnapshot() // 创建订单快照
|
||
return CreateSuccess
|
||
}
|
||
```
|
||
|
||
在阅读业务流程代码时，我们只要阅读其函数名就能知晓在该流程中完成了哪些操作，如果需要修改细节，那么就继续深入到每一个业务步骤去看具体的流程。写得稀烂的业务流程代码则会将所有过程都堆积在少数的几个函数中，从而导致几百甚至上千行的函数。这种意大利面条式的代码阅读和维护都会非常痛苦。在开发的过程中，一旦有条件应该立即进行类似上面这种方式的简单封装。
|
||
|
||
## 使用 interface 来做抽象
|
||
|
||
业务发展的早期，是不适宜引入 interface 的，很多时候业务流程变化很大，过早引入 interface 会使业务系统本身增加很多不必要的分层，从而导致每次修改几乎都要全盘否定之前的工作。
|
||
|
||
当业务发展到一定阶段，主流程稳定之后，就可以适当地使用 interface 来进行抽象了。这里的稳定，是指主流程的大部分业务步骤已经确定，即使再进行修改，也不会进行大规模的变动，而只是小修小补，或者只是增加或删除少量业务步骤。
|
||
|
||
如果我们在开发过程中，已经对业务步骤进行了良好的封装，这时候进行 interface 抽象化就会变的非常容易，伪代码：
|
||
|
||
```go
|
||
// OrderCreator 创建订单流程
|
||
type OrderCreator interface {
|
||
ValidateDistrict() // 判断是否是地区限定商品
|
||
ValidateVIPProduct() // 检查是否是只提供给 vip 的商品
|
||
GetUserInfo() // 从用户系统获取更详细的用户信息
|
||
GetProductDesc() // 从商品系统中获取商品在该时间点的详细信息
|
||
DecrementStorage() // 扣减库存
|
||
CreateOrderSnapshot() // 创建订单快照
|
||
}
|
||
```
|
||
|
||
我们只要把之前写过的步骤函数签名都提到一个 interface 中，就可以完成抽象了。
|
||
|
||
在进行抽象之前，我们应该想明白的一点是，引入 interface 对我们的系统本身是否有意义，这是要按照场景去进行分析的。假如我们的系统只服务一条产品线，并且内部的代码只是针对很具体的场景进行定制化开发，那么实际上引入 interface 是不会带来任何收益的。至于说是否方便测试，这一点我们会在之后的章节来讲。
|
||
|
||
如果我们正在做的是平台系统，需要由平台来定义统一的业务流程和业务规范，那么基于 interface 的抽象就是有意义的。举个例子：
|
||
|
||
TODO，interface 实现的 uml 图
|
||
|
||
平台需要服务多条业务线，但数据定义需要统一，所以希望都能走平台定义的流程。作为平台方，我们可以定义一套类似上文的 interface，然后要求接入方的业务必须将这些 interface 都实现。如果 interface 中有其不需要的步骤，那么只要返回 nil，或者忽略就好。
|
||
|
||
在业务进行迭代时，平台的代码是不用修改的，这样我们便把这些接入业务当成了平台代码的插件(plugin)引入进来了。如果没有 interface 的话，我们会怎么做？
|
||
|
||
```go
|
||
import (
|
||
"sample.com/travelorder"
|
||
"sample.com/marketorder"
|
||
)
|
||
|
||
func CreateOrder() {
|
||
switch businessType {
|
||
case TravelBusiness:
|
||
travelorder.CreateOrder()
|
||
case MarketBusiness:
|
||
marketorder.CreateOrderForMarket()
|
||
default:
|
||
return errors.New("not supported business")
|
||
}
|
||
}
|
||
|
||
func ValidateUser() {
|
||
switch businessType {
|
||
case TravelBusiness:
|
||
travelorder.ValidateUserVIP()
|
||
case MarketBusiness:
|
||
marketorder.ValidateUserRegistered()
|
||
default:
|
||
return errors.New("not supported business")
|
||
}
|
||
}
|
||
|
||
// ...
|
||
switch ...
|
||
switch ...
|
||
switch ...
|
||
```
|
||
|
||
没错，就是无穷无尽的 switch，和没完没了的垃圾代码。引入了 interface 之后，我们的 switch 只需要在业务入口做一次。
|
||
|
||
|
||
## interface 是必须的吗？
|
||
|
||
## 要不要用继承？
|
||
|
||
## table-driven 开发
|