Newbe.Claptrap项目周报1-还没轮影,先用轮跑
Newbe.Claptrap 项目周报 1,第一周代码写了一点。但主要还是考虑理论可行性。
周报是啥?
成功的开源作品,离不开社区贡献者的积极参与。作为一个新启动的轮子项目,项目联合创始人【月落】有交代:
“我知道你代码能力也不怎么样,你就把你的想法每周的交代清楚。让他人看到项目的价值。等待越来越多的人发现项目价值所在的时候,自然就会给予更多的关注,甚至于参与的项目的开发当中。所以你要每周都写一下周报。周报最好侧重于讲解项目的概念,以及通过项目如何解决实际问题。当然也可以包含一些关于项目如何设计的内容,但要注意适度,通常大家不会太注意项目怎么实现。而更关注项目带来的价值。记住:只有产生了价值,项目才会成功。”
于是笔者就只能每周写一下周报,勉强维持生活这样子。
轮有轮样
新轮要有新轮的样子,“项目开张篇”中介绍了本框架相关的基础理论和工作原理。鉴于相关的理论内容对于刚刚接触的读者较为生疏,因此本节将前文最为关键的内容罗列如下以激发读者的回忆。
Actor 特性一:Actor 的状态是通过外部调用 Actor 而改变的。
Actor 特性一补 1:Actor 的状态不与外部进行共享。
Actor 特性一补 2:外部可以读取 Actor 状态。
Actor 特性二:Actor 是“单线程”工作的,每次只能处理一个请求。
Actor 特性二补 1:并发读取状态可以不是“单线程”。
框架定义的 Actor 类型——Claptrap:通过事件模式,产生事件并通过事件改变自身状态的 Actor。
框架定义的 Actor 类型——Minion:与 Claptrap 对比,Minion 不产生事件而是读取对应 Claptrap 的事件来改变自身的状态。允许存在多个 Minion 对应一个 Claptrap。
通过 Claptrap 和 Minion 配合完成“转账”业务。
月落大佬名言警句 1:世界上本也不存在“银弹”。一套框架解决不了所有问题。 月落大佬名言警句 2:业务复杂度是不会因为系统设计变化而减少的,它只是从一个地方转移到了另外的地方。
还没轮影,先用轮跑
现在我们拥有了 Claptrap 和 Minion 的概念。接下来,结合一些业务场景,实验一下框架能否应对各种各样的业务需求。
再美的技术手段无法应对现实的需求与变化,那也只能技术花瓶。——刚刚学完赛博坦 XII 量子计算机指令集的月落
业务场景
这是一个简单的电商系统:
- 只卖一种绿色的水晶,为了方便描述,将这个商品命名为“原谅水晶”。
- 用户可以使用自己账号中的余额购买原谅水晶。余额是通过外部支付系统充值进来的。充值部分,暂时不是业务场景需要考虑的。
- 每个用户还有一个积分,很巧,这个积分的图标也是绿色的,因此,将这个积分命名为“原谅积分”。
- 原谅积分的获取方式有很多,例如:用户注册;邀请其他用户注册;被邀请用户进行了消费,邀请者也可以获得;原谅即挖矿;现实中获得了原谅;等等其他的一些方式,这部分可能需要配合后续的活动持续增加获得方式。
- 原谅积分可以在进行购买原谅水晶时,抵扣一部分需要支付的金额。
- 原谅积分在未来很可能有其他的用途。
- 购买原谅水晶的支付方式未来很可能不止余额和原谅积分两种。
以上就是对于这个电商系统的一部分需求描述。需求未来肯定是会变化的。
要素察觉
电商系统,最为主要的业务场景自然是和商品的交易有关的业务场景。不论其他的需求场景多么的复杂,交易相关的业务场景必然是首当其冲需要分析解决的。
那么首先,我们将“用户确认购买原谅水晶”这个场景用简单的语言描述一下程序需要执行的业务内容:
- 需要检查用户的余额是否足够
- 假如用户选择了积分抵扣,需要检查用户的积分是否足够
- 需要检查库存是否足够
- 需要扣减用户的余额
- 需要扣减库存
- 假如用户选择了积分抵扣,需要扣减用户的积分
如果采用直接操作数据表的方式实现以上六个要点,对于绝大部分开发者来说应该是十分简单的。开启一个数据库事务,至少具备行级锁,将数据进行检查和更新,便可以完成这个业务。那么现在使用本框架进行实现,根据“业务复杂度不减少”的基本事实,也同样需要实现以上六个要点。
未卜先知
首先,在不太讨论依据的前提下,笔者围绕上文提到的一些主体概念,设计了以下这些 Claptrap:
概念 | 英文命名 | 缩写 | 代表颜色 |
---|---|---|---|
原谅 水晶 | SKU | S | ■■■■■ |
原谅积分 | UserPoint | P | ■■■■■ |
用户余额 | UserBalance | B | ■■■■■ |
依轱辘画轮
按照前篇的“转账”业务场景的流程设计,此处采用相同的方式设计一下购买的逻辑。如下图所示:
分析一下这个设计方案:
依照业务逻辑的顺序,完成了库存检查、库存扣减、余额检查、余额扣减、积分检查、积分扣减的业务步骤。
注意 Client 和 Claptrap S 之间的调用线的存在时间,只有在一开始的时候,也就是说,客户端仅需要稍作等待,便可以得到响应。
Claptrap S 将事件推送给 Minion S 之后便可以继续响应新的请求。确保了多个用户进行并发购买商品即确保了商品不会超卖,也确保了响应事件足够短。
整个业务逻辑的入口是 S、这样可以确保用户在锁定库存的前提下进行支付,避免了用户付了钱没有办法买到商品的情况。
基于形状上的原因,这种设计方案被命名为 “链形设计(Chain-Like Design)”。