常识六流程服务
常识系列,作为一名互联网门外汉的科普系列
流程服务，乍一看,很高深的样子。其实是个很简单的东东！
看到流程，千万别想到workflow那种复杂的玩意。
不知道别的公司，别的部门有没有这种服务，这种服务是因实际痛点情况符合底层团队而生的一种服务。
定义
流程服务：一连串按特定顺序请求的服务集
由定义可知特性：
- 是个服务集，不只单单某个服务
- 这些服务会被特定顺序请求，如果顺序错乱，请求就会被打断
痛点
为什么会有流程服务？它的价值在哪里
背景
公司一般都是前后端分离，分为前端，中间层，后端。
中间层做了相关聚合，后端已经很底层了。
有多底层呢？底层到只有数据操作，如DB,redis之类的存储操作
比如用户相关：
- 用户名密码方式登陆，就是查user表
- 通过用户名查询用户信息
- 通过用户ID查询用户信息
- 登陆成功后发送消息
- 登陆成功不用发送消息
这样三个接口，你单单想想，有多大价值，没毕业的学生做得不一定有多差
当然你可更加聪明点：写个万能查询接口，上层有什么样的条件，传过来就行了，拼个万能sql
一个接口，万岁！
如果你不参与整体项目需求评审，项目架构设计，你会觉得你的工作相当无聊，只有CRUD。
痛点
首先一个接口肯定是不行了
- 接口职责不清
- 性能不能保证
- 服务治理是个空话
- 重构艰难
- 测试困难
根据这痛点，我们职责划分一下，性能，治理都可以解决
那是不是就没有了痛点呢？
举个列子：有个活动，推广用户绑定邮箱，获得一定的奖励
绑定邮箱，对应saveUserEmail接口，就是个插入DB操作，too simple；
有个客诉，说绑定邮箱了，没有拿到奖励。客服要找人解决，找谁？ 肯定是底层，数据在底层，有没有绑定邮箱，绑定渠道是什么？什么时间绑定的？
数据都是从上游到下游，但查问题时，都是从下游推导上游
这种底层接口，上游都可以调用，什么时候什么情况什么业务调用的，底层开发完全不清楚。
到底是底层存储错了，还是上游传参错了？
反正这个数据是底层存储，底层需要去梳理调用链，分析下是存错了，还是上游传错了，给客服一个解释，给用户一个交待。
弄不好一个接口有千百个调用方，底层实在是难
讲到这，痛点就清楚了，接口场景的缺失是底层最大的痛点
流程服务
有了痛点，就寻找解决方法：流程服务
不再让中间层聚合所有服务，由底层提供流程服务，简化了中间层聚合的复杂度，底层也保存了场景信息
比如手机快捷登陆流程
- 根据手机号查询是否有用户绑定此手机号
- 接入风控系统防刷，获取手机验证码
- 验证手机验证码
- 登陆成功返回用户信息，发送登陆成功消息
当上游请求请求此流程时，底层就知道是手机快捷登陆业务，不再是零散的接口调用
流程数据
流程数据需不需要存储？
流程的每一步如果存储，用什么存储呢？ mysql?redis?
流程的有效期是多久呢？是流程结束后清除，还是定时归档？
注意点
DB一般都使用主从架构，虽然大多数时候都是实时的，但也有延迟的时候，如果流程之间时间极短，如何保证主从同步完成时间小于流程切换时间?
如果用户流程不走完，比如一个流程有三步，用户只操作了第一步，或者前两步，那产生的脏数据怎么办？是回滚呢？还是定时清理？