民生类

林依轮,原创当说到“事情驱动”时,咱们在说什么?,成长

文/Martin Fowler

译/梅雪松

上一年年末(译者注:2016年末),我和ThoughtWorks搭档一同参加了一个研讨会,评论“作业驱动”的实质。在曩昔的几年里,咱们构建的许多体系都许多运用了作业。关于这些体系,人们常常赞誉有加,但批北京镜鉴记评的声响也不绝于耳。咱们的北美办公室组织了一次峰会,来自世界各地的ThoughtWorks资深开发者出席会议并共享了他们的主意。

这次峰会的最大知道是到当人们议论“作业”时,实际上说的是彻底不同的东西,所以咱们花了许多时刻来整理一些有用的形式。本文扼要总结咱们的效果。

当领crackwatch域内有改变发作时,发三点水西土送作业音讯来告诉其它体系。作业告诉的一个要害点是源体系并不关怀外部体系的呼应。一般它底子不等待任何成果,即便有也是直接的。 发送作业的逻辑流与呼应该作业的逻辑流之间会有显着的阻隔。

作业告诉十分有用,由于它意味着低耦合,而且结构也十分简略。可是,当逻辑处理流跨过各种作业告诉时,它也或许成为问题。由于没有任何代码显式地医香小娘子描绘这个流程,所以这个流程是不行见的。一般,仅有的方法是经过监控体系来调查它。这会导致调试和修正流程变得很困难。这儿的风险在于,当你运用作业告诉来高雅地做林依轮,原创当提到“作业驱动”时,咱们在说什么?,生长体系解耦时,没有意识到更大规划的流程,而这会让你在未来几年中陷入困境。不论怎么,此形式依然十分有用,但你有必要当心圈套。

北京新神力酒店

举个比如,将作业用作被迫控制型指令(Passive-aggressive command)就归于这种圈套。它指的是源体系等待接纳方履行一个动作,此刻本该运用指令音讯(Command messa曼西亚哈泽尔ge)来展示此意图,可是却运用了作业。

作业不敬汉卿黑前史需求包括太大都据,一般只要一些ID信息和一个指向发送方、可供查询更多信息的链接。 接纳方知道它已发作改变,而且接纳到林依轮,原创当提到“作业驱动”时,咱们在说什么?,生长关于改变的最少信息,随后会向发送方宣布恳求,以决议下一步该做什么。

选用此形式时,能够在不需求拜访源体系的情况下,更新客户端的信息。客户办理体系或许在客户修正自己的具体信息(如地址)时抛出作业,作业包括了具体的修正数据。因而林依轮,原创当提到“作业驱动”时,咱们在说什么?,生长,接纳方无需与客户办理体系通讯,就能够更新自己的客户数据副本,以进行下一步的操作。

这种形式的一个显着缺陷是,有许多冗余数据和副本。但在存储很廉价的年代,这不是一个问题。咱们取得了更好的弹性,由于即便客户办理体系不行用时,接纳方体系依然能够正常作业。咱们减少了推迟,由于拜访客户信息不需求长途调林依轮,原创当提到“作业驱动”时,咱们在说什么?,生长用。咱们也不用忧虑一切来自消费端的查询给客户办理体系带来的负载。但它的确给作业接纳端带来种子狗了更多杂乱性,由于它有必要保护一切状况,而假如它直接拜访作业发送方查询信息,一般会愈加简略。

作业溯源(Event Sourcing)的中心思维是,每逢体系状况发作改变时,都将状况更改记载为作业,这样咱们就有决心在任何时刻都能够经过重丧命黑瞳新处理作业来重建体系状况。作业库成为事实的首要来历,体系状况彻底来历于它。关于程序员来说,最好的比如便是版别控制体系。一切的提交日志便是作业库,源码树的作业副本是体系状况。

作业溯源会引进许多问题,但mdc第二论坛我不会在这儿评论,我想着重一些常见的误解。退休梨精事林依轮,原创当提到“作业驱动”时,咱们在说什么?,生长件处理不用是异步的,以更新本地Git库为例,这彻底是一个同步操作,就像更新Subversion这样的集中式版别控制体系相同。当然具有一切这些提交答应你做各种风趣的作业,Git便是一个很好的比如,但中心提交从枫林山行底子上说是一个简略的动作。

另一个常见过错是,假定运用作业溯源体系的每个人都应该了解并拜访作业日志以确认有用的数据,但实际上他们很或许对作业日志只具有有限的了解。我正在运用编辑器写这篇文章,编辑器不知道我的源代码树中的一切提交,它仅仅假定磁盘上有一个文件。在根据医念霜华作业溯源的体系中,许多处理能够根据一个有用的作业副本。只要确实正需求作业日志中的信息时四平旋风哥才有必要处理它。假如需求的话,咱们能够有多个不同Schema的作业副本,但一般应该在范畴处理和经过作业日志派生作业副本之间做清晰差异。

运用作业日志时,构建作业副本的快照一般很有用,这样你就不用在每次需求作业副本时都从头开始处理一切作业。实际上这儿存在二元性,咱们能够将作业日志视为改变列表或状况列表。 咱们能够从一个派生出另一个。版别控制体系一般在作业日志中混合快照和增量改变,以取得最佳功用。[1]

考虑一下版别控制体系带来的价值,就很简略理解作业溯源有许多风趣的收益。作业日志供给了强壮的审计功用(账户买卖是帐户余额的作业溯源)。咱们能够重放作业日志到某个点来从头创立前史状况。在重放时注入假定作业能够探究纷歧加加上网导航样的前史。作业溯源使得非耐久化的作业副本(例如Memory将军的新娘 Image)变得合理可行。

作业溯源也有自己的问题。 当成果依赖于与外部体系的交互时,重放作业就会成为问题。跟着时刻的推移,咱们有必要清楚怎么处理作业Schema的改变。许多人发现作业处理给体系增加了许多杂乱性(虽然壮乡美酒喝不行我很想知道,首要原因是不是作业副本派生组件和范畴处理组件之间糟糕的阻隔)。

指令查询责任别离(CQRS)是指读取和写入别离具有独自的数据结构。 严格地说,CQRS跟作业没有关系,由于你彻底不需求任何作业就能够运用CQRS。但一般人们会将CQRS与之前的形式结合起来,因而咱们在峰会上就此进行了评论。

运用CQRS的理由是,在杂乱范畴中,运用单一模型处理读取和写入过于杂乱,咱们嘿六仔能够经过别离模型来简化。当拜访形式有差异时(例如许多读取和十分少的写入),这一点特别具有吸引力。可是,需求留意平衡CQRS的收益和别离模型所带林依轮,原创当提到“作业驱动”时,咱们在说什么?,生长来的额定杂乱度。我发现许多搭档对运用CQRS十分警觉,发现它经常被乱用。

作为一名热衷于搜集样本的“软件植物学家”,我发现这是一个扎手的地带, 首要问题在于不同形式的混杂。 在某个项目中,一位才能很强,经验丰富icegay的项目经理告诉我,作业溯源是一场灾祸,任何改变都需求两倍的时刻来修正读和写模型。 在他这句话中,能够发现作业溯源和CQRS之间或许存在混杂,咱们怎么找出哪个是元凶巨恶? 该项意图技术主管宣称首要问题是许多的异步通讯,这当然是一个已知的杂乱性助推器,但异步通讯不林依轮,原创当提到“作业驱动”时,咱们在说什么?,生长是作业溯源或CQRS的必要组成部分。 总的来说,咱们有必要要留意这些形式在对的当地都很好,反之则很糟糕。 可是当咱们混杂了这些形式时,很难弄清楚哪里是对的当地。

更多精彩洞见,请重视微信大众号:ThoughtWorks洞见

开发 植物 技术
声明:该文观念仅代表作者自己,搜狐号系信息发布渠道,搜狐仅供给信息存储空间效劳。

相关文章