如何写业务代码
业务研发面对的问题
- 稳定的业务模式
- 不稳定的需求
- 业务对交付的渴望
假设
- 命名规范（《clean code》）
- 面向对象设计（SOLID原则、贫血/充血模型、设计模式）
系统要拆分
- 每一个用例（解决的一个问题）都由访问逻辑和执行逻辑组成。访问逻辑负责用例执行的顺序与分支，并调用执行逻辑完成完整业务逻辑。
- 访问逻辑由单独的交易系统负责。执行逻辑由个子系统负责。
工程要拆分
三层架构 + 洋葱架构
代码要拆分
- 业务代码：描述核心业务逻辑的代码，核心是保持业务的流程及业务状态的一致性
- 领域对象与领域服务，不得对外部有任何依赖（工具类除外）
- 最核心的几个抽象：
- 校验：参数有效性校验、参数的业务属性校验。在进入正常业务逻辑代码前，完成所有的校验工作。
- 异常：业务异常：所有不符合业务逻辑而产生的异常。 系统异常：因为程序本身or依赖产生的异常。 所有的异常第一位runningtime异常。
- 数据: 业务数据：保存领域对象状态的数据。 非业务数据：过程数据。业务的核心流程中，只对业务数据的持久化负责。
- 参数：任何时候，任何方法的参数都需要对象化（除了查询）
- 业务流水号：要有业务流水号
代码要分类
每个子系统（或者对象）提供5类基本接口：
- 做事情：void doing:做某个改变系统系统状态业务决策，成功无返回，失败抛异常，并明确失败原因，无论是系统异常还算业务异常。需要做业务幂等。
- 判断事情：boolean deciding:做某个不改变系统状态的业务决策，成功返回tre或false，失败抛异常，并明确失败原因，无论是系统异常还算业务异常。天然幂等。
- “知道”Object knowing:期待返回结果。因为系统提供knowing方法，本质上是对外宣传我知道这件事情。如果返回null，则应抛业务异常。
返回系统内“开箱即用”的知识，即系统内的活动对象所拥有的知识，无需去存储内搜索，无业务决策。一般返回具体对象或列表。天然幂等（所以knowing一般通过当前活动的domain对象向外暴露） - “查找”分3种：
- “搜索” Set finding：不期待返回结果。查找本身有可能找不到，无论是否能够查找到，均返回集合。不抛业务异常，只抛程序异常。返回系统内需要通过存储介质“搜索”才能得到的知识。一般返回具体对象或列表。天然幂等（所以finding一般动过dao对象对外暴露，或者干脆由专门的查询系统对外暴露）
- “严格获取” Object get：期待返回结果，并且根据业务规则，有且只返回一个符合预期的结果。如果获取不到，抛业务异常。
- “不严格获取”：Object getIfExist不期待一定返回结果，根据业务规则，可以有也可以没有。如果有结果，只返回一个符合预期结果。如果获取不到，不抛业务异常
- “工具类”：不你属于任何一个业务对象，无状态，结果仅仅由输入参数决定，幂等
一些其他原则
访问原则：
- 子系统仅接受产品层发起的doing方法
- 子系统对产品层及其他子系统开发非doing方法
- 子系统必须对外界提供领域化接口和领域化查询接口，不接受调用方的特殊化接口。特列：上游对性能极度敏感，且原有接口无优化空间，可以专门提供特别的接口。
- 子系统不对展现逻辑负责
- 系统间传递领域化参数，并定制化thrift传输对象
- 调用方异常必须包含被调用方的原始异常栈
- 所有需要适配的工作，由调用方自行负责
- 所有子系统，必须接受产品系统的业务流水号，并提供根据业务流水号查询历史数据的能力
- 所有带业务流水号的查询，子系统必须保持数据的最新与准确
- doing、deciding、get由子系统提供业务一致性保证（抛业务异常）
- knowing、finding、getIfExsit由调用方提供业务一致性保证（抛业务异常）
- 信息传递最短路径原则。子系统自己可以获取的信息，不能由其他系统代为传递
- 当外部访问者需要新的概念，并且此概念完全由领域类的数据定义时，此概念由领域方维护和解释。
校验原则
- 参数合法性（无论字面校验、业务校验）由产品系统负责
- 由子系统负责的领域的流程准入合法性，由产品系统调用子系统的deciding方法校验。
- 无论交易系统是否校验过，领域系统必须完整自己领域类的完整校验
数据存储原则
- 每个子系统严格区分业务数据与过程数据
- 每个子系统只对自己领域内的数据负责，不对调用方负责。
- 每个子系统负责自己领域的的数据一致性或者完备性，不得要求被调用方为自己的业务逻辑提供其内部业务决策不需要存储的数据。如果需要同步其他子系统数据，由当前子系统负责保证时效及数据一致性
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2017-10-21
系统的弹性
背景介绍 1999年，Dan Kegel 在互联网上发表了一篇文章，首次将 C10K 问题带入软件工程师的视野。在那个互联网勃兴的年代，计算机的运算处理能力，ISP 能够提供的带宽和网速都还十分有限，用户的数量也很少（那时候一个网站几百个人是很正常的事）。Dan Kegel 却已经敏锐地注意到极端的场景下资源紧张的问题。按照他的观察，某些大型的网络站点需要面对高达10000个客户端的并行请求。以当时的通行系统架构，单机服务器并不足以处理这个这个问题（当时绝大部分系统也没有那么大的流量，所以大部分人也没意识到这个问题）。因此，系统设计者必须为 C10K 问题做好准备。在那篇文章之中， Dan Kegel 提出了使用非阻塞异步 IO 模型，和使用各种内核系统调用黑魔法来提高系统 IO 性能的方式，来提高单机的并行处理能力。不得不说，这篇文章在当时很有先驱意义，它使得大规模网络系统的流量问题浮上了水面，也让人们意识到了系统容量建模和扩容提升性能的重要性。在它的启发下，C10K 问题出现了很多变种，从并发 C10K clients，到并发 C10K...
2017-12-22
分布式事务
问题定义对经典的电商场景而言：下单是个插入操作，扣减金额和库存是个更新操作，操作的模型不同，如果进行分布式的服务拆分，则可能无法在一个本地事务里操作几个模型，涉及跨库事务。 CAP 定义根据 Eric Brewer 提出的 CAP 理论： Consistency：All Nodes see the same data at the same time Availability：Reads and writes always succeed Partition tolerance：System continues to operate despite arbitrary message loss or failure of part of the system 由此诞生三种共识/分布式一致性算法： CA = 2PC，即 2PC 无法分区容错 AP = Gossip，即 Gossip 无法保证一致性 CP = Paxos，即 Paxos...
2018-01-30
几种共识算法
达成共识的英文原文是 come to consensus。达成共识以后，也未必代表数据是完全一致的（Raft 算法中 leader 发出 append log 的 commit 命令即算达成共识？但如果中途数据丢失，则还是会有子节点数据不一致）。 在分布式环境下，多个系统协同工作的效率，受制于系统交叉点的性能。在需要达成分布式共识的场景下，分布式共识算法在保证系统安全性的同时，限制了全系统横向扩展的性能提升。 根据环境的不同，可以应用不同的共识算法。 在完全互信的环境下-私有链、私有的分布式数据库，节点之间可以使用 Paxos 或者 Raft 这种 leader 相对固定的算法。 在有限互信的环境下-联盟链，可以使用 PBFT。PBFT 算法是依据确定性的投票（可能是漫长的投票，也可能进入死循环）达到确定性一致的算法。 在没有互信的情况下-公有链，可以使用 POW/POS/DPOS/POA。这类算法是基于概率得到正确的最终一致性，性能比 PBFT 要稍微好点。 最好的共识算法应该模块化，例如 Corda 中的 notary，Hyperledger fabric 中的...
2018-04-02
一个滚动重启的状态保存问题
很多时候滚动重启，都会导致状态丢失。比较好的设计方法是把服务本身设计成无状态的，然后在上游的服务上做好 failover，然后增加 standby server，让 sticky 数据 transmit 到 standby 机器上，让 request 失败以后可以自己由上游重传到 standby server。然后就可以滚动重启了。 这大部分场景下还要考虑幂等的问题。 这就看得出热配置热替换的重要性了。在大多数情况下，除了发布新的 feature 升级以外，都应该尽量用热配置来避免重启。
2018-11-28
正交性
所谓正交性（orthogonal 意为正交的），就是设计的维度与其他维度完全隔离，一个正交的设计/值域设计，其变化绝不会受其他正交维度影响，也不会影响其他正交维度。 我们可以把 API 设计成正交的。这样 API 有独立变化的空间的。 我们可以把问题域切分清楚。问题域之间完全不相互干涉（注意跨问题域问题）。 我们可以把变量、字段、列设计成正交的。这样不同业务场景下，列之间的赋值不会相互覆盖。
2019-08-30
《高可用恢复思路》笔记
遇到线上问题，经常陷入一个误区：一定要找到问题的根因（root cause）。但实际上对线上应用而言，最重要的是恢复可用性，所以在开发设计环境除了完成功能性需求以外，还需要加入非功能性设计的需求： 限流保护。抵挡来自突发流量冲垮整个集群。 降级保护，对调用的服务接口保持警惕，其各种因素导致不可用，可以对齐降级，从而确保核心功能可用。 削峰填谷（traffic shaping），不因突发数据来袭，造成任务消费陡增，造成调用系统的连串抖动。 这些基本的系统保护，是应对未来的各种突发不确定事件的高可用思考。 以上描述的是问题的应对机制设计，问题的发现机制，也需要结构化地考虑，体系化地建设： 发现机制，是我们的眼睛，也是基础。 监控主指标，需要找对业务的主要指标，常见的主指标一般是：RT（响应时间）、总量、成功量、失败量、成功率。 主指标有异常，还要有细分维度（即结果还可以内部 group by aggregation）。 快速恢复 根据监控快速寻找问题发生的方向和位置。 找对恢复的人、恢复的预案。 倾向于选择成本低的恢复手段。——...
