基于Actor模型的CQRS/ES解决方案分享

分享 未结
1 1 0 2
小编 8天前发布
收藏 点赞
来源: 郑承良

2017年加密货币比较流行,我曾有幸在加密货币交易所参与开发工作,为了应对交易系统高性能、高并发、高可用的要求,我们使用基于Actor模型的Orleans技术,采用CQRS/ES架构结合Service Fabric开展了富有挑战性的工作。本文将从不同视角为大家介绍Actor模型、CQRS/ES架构以及Service Fabric在高并发场景中的考量和应用。

话题由三部分组成:

  • Actor模型&Orleans:在编程的层面,从细粒度-由下向上的角度介绍Actor模型;
  • CQRS/ES:在框架的层面,从粗粒度-由上向下的角度介绍Actor模型,说明Orleans技术在架构方面的价值;
  • Service Fabric:从架构部署的角度将上述方案落地上线。

群里的小伙伴技术栈可能多是Java和Go体系,分享的话题主要是C#技术栈,没有语言纷争,彼此相互学习。比如:Scala中,Actor模型框架有akka,CQRS/ES模式与编程语言无关,Service Fabric与Kubernetes是同类平台,可以相互替代,我自己也在学习Kubernetes。

Actor模型&Orleans(细粒度)

共享内存模型

多核处理器出现后,大家常用的并发编程模型是共享内存模型。 

这种编程模型的使用带来了许多痛点,比如:

  • 编程:多线程、锁、并发集合、异步、设计模式(队列、约定顺序、权重)、编译
  • 无力:单系统的无力性:①地理分布型、②容错型
  • 性能:锁,性能会降低
  • 测试:
  • 从坑里爬出来不难,难的是我们不知道自己是不是在坑里(开发调试的时候没有热点可能是正常的)
  • 遇到bug难以重现。有些问题特别是系统规模大了,可能运行几个月才能重现问题
  • 维护:
  • 我们要保证所有对象的同步都是正确的、顺序的获取多个锁。
  • 12个月后换了另外10个程序员仍然按照这个规则维护代码。

简单总结:

  • 并发问题确实存在
  • 共享内存模型正确使用掌握的知识量多
  • 加锁效率就低
  • 存在许多不确定性

Actor模型

Actor模型是一个概念模型,用于处理并发计算。Actor由3部分组成:状态(State)+行为(Behavior)+邮箱(Mailbox),State是指Actor对象的变量信息,存在于Actor之中,Actor之间不共享内存数据,Actor只会在接收到消息后,调用自己的方法改变自己的state,从而避免并发条件下的死锁等问题;Behavior是指Actor的计算行为逻辑;邮箱建立Actor之间的联系,一个Actor发送消息后,接收消息的Actor将消息放入邮箱中等待处理,邮箱内部通过队列实现,消息传递通过异步方式进行。 

Actor是分布式存在的内存状态及单线程计算单元,一个ID对应的Actor只会在集群种存在一个(有状态的 Actor在集群中一个ID只会存在一个实例,无状态的可配置为根据流量存在多个),使用者只需要通过ID就能随时访问不需要关注该Actor在集群的什么位置。单线程计算单元保证了消息的顺序到达,不存在Actor内部状态竞用问题。

举个例子:

多个玩家合作在打Boss,每个玩家都是一个单独的线程,但是Boss的血量需要在多个玩家之间同步。同时这个Boss在多个服务器中都存在,因此每个服务器都有多个玩家会同时打这个服务器里面的Boss。

如果多线程并发请求,默认情况下它只会并发处理。这种情况下可能造成数据冲突。但是Actor是单线程模型,意味着即使多线程来通过Actor ID调用同一个Actor,任何函数调用都是只允许一个线程进行操作。并且同时只能有一个线程在使用一个Actor实例。

Actor模型:Orleans

Actor模型这么好,怎么实现?

可以通过特定的Actor工具或直接使用编程语言实现Actor模型,Erlang语言含有Actor元素,Scala可以通过Akka框架实现Actor编程。C#语言中有两类比较流行,Akka.NET框架和Orleans框架。这次分享内容使用了Orleans框架。

特点:

Erlang和Akka的Actor平台仍然使开发人员负担许多分布式系统的复杂性:关键的挑战是开发管理Actor生命周期的代码,处理分布式竞争、处理故障和恢复Actor以及分布式资源管理等等都很复杂。Orleans简化了许多复杂性。

优点:

  • 降低开发、测试、维护的难度
  • 特殊场景下锁依旧会用到,但频率大大降低,业务代码里甚至不会用到锁
  • 关注并发时,只需要关注多个actor之间的消息流
  • 方便测试
  • 容错
  • 分布式内存

缺点:

  • 也会出现死锁(调用顺序原因)
  • 多个actor不共享状态,通过消息传递,每次调用都是一次网络请求,不太适合实施细粒度的并行
  • 编程思维需要转变

第一小节总结:上面内容由下往上,从代码层面细粒度层面表达了采用Actor模型的好处或原因。

CQRS/ES(架构层面)

从1000万用户并发修改用户资料的假设场景开始

  1. 每次修改操作耗时200ms,每秒5个操作
  2. MySQL连接数在5K,分10个库
  3. 5 *5k *10=25万TPS
  4. 1000万/25万=40s

在秒杀场景中,由于对乐观锁/悲观锁的使用,推测系统响应时间更复杂。

使用Actor解决高并发的性能问题

1000万用户,一个用户一个Actor,1000万个内存对象。 

200万件SKU,一件SKU一个Actor,200万个内存对象。

  • 平均一个SKU承担1000万/200万=5个请求
  • 1000万对数据库的读写压力变成了200万
  • 1000万的读写是同步的,200万的数据库压力是异步的
  • 异步落盘时可以采用批量操作

总结:

由于1000万+用户的请求根据购物意愿分散到200万个商品SKU上:每个内存领域对象都强制串行执行用户请求,避免了竞争争抢;内存领域对象上扣库存操作处理时间极快,基本没可能出现请求阻塞情况。

从架构层面彻底解决高并发争抢的性能问题。理论模型,TPS>100万+……

EventSourcing:内存对象高可用保障

Actor是分布式存在的内存状态及单线程计算单元,采用EventSourcing只记录状态变化引发的事件,事件落盘时只有Add操作,上述设计中很依赖Actor中State,事件溯源提高性能的同时,可以用来保证内存数据的高可用。 

CQRS

上面1000万并发场景的内容来自网友分享的PPT,与我们实际项目思路一致,就拿来与大家分享这个过程,下图是我们交易所项目中的架构图: 

开源版本架构图: 

开源项目GitHub:https://github.com/RayTale/Ray

第二小节总结:由上往下,架构层面粗粒度层面表达了采用Actor模型的好处或原因。

Service Fabric

系统开发完成后Actor要组成集群,系统在集群中部署,实现高性能、高可用、可伸缩的要求。部署阶段可以选择Service Fabric或者Kubernetes,目的是降低分布式系统部署、管理的难度,同时满足弹性伸缩。

交易所项目可以采用Service Fabric部署,也可以采用Kubernetes,当时Kubernetes还没这么流行,我们采用了Service Fabric,Service Fabric 是一款微软开源的分布式系统平台,可方便用户轻松打包、部署和管理可缩放的可靠微服务和容器。开发人员和管理员不需解决复杂的基础结构问题,只需专注于实现苛刻的任务关键型工作负荷,即那些可缩放、可靠且易于管理的工作负荷。支持Windows与Linux部署,Windows上的部署文档齐全,但在Linux上官方资料没有。现在推荐Kubernetes。

第三小节总结:

  • 借助Service Fabric或Kubernetes实现低成本运维、构建集群的目的。
  • 建立分布式系统的两种最佳实践:
  • 进程级别:容器+运维工具(Kubernetes/Service Fabric)
  • 线程级别:Actor+运维工具(Kubernetes/Service Fabric)

参考:

ES/CQRS部分内容参考:《领域模型 + 内存计算 + 微服务的协奏曲:乾坤(演讲稿)》2017年互联网应用架构实战峰会。


Q&A

Q:单点故障后,正在处理的cache数据如何处理的,例如,http、tcp请求……毕竟涉及到钱? 

A:Actor有激活和失活的生命周期,激活的时候使用快照和Events来恢复最新内存状态。Actor框架保证系统中同一个key只会存在同一个Actor,当单点故障后,Actor会在其它节点重建并恢复最新状态。


Q:数据落地得策略是什么?还是说就是直接落地?

A:event数据直接落地;用于支持查询的数据,是Handler消费event后异步落库。


Q:Grain Persistence使用Relational Storage容量和速度会不会是瓶颈?

A:Grain Persistence存的是Grain的快照和event,event是只增的,速度没有出现瓶颈,而且开源版本测试中PostgreSQL性能优于MongoDB,在存储中针对这两个方面做了优化:比如分表、归档处理、快照处理、批量处理。


Q:Orleans中,持久化事件时,是否有支持并发冲突的检测,是如何实现的?

A:Orleans不支持;工作中,在事件持久化时做了这方面的工作,方式是根据版本号。


回帖
  • 消灭零回复