随着越来越多的企业进入数字化转型的深水区，传统业务场景大规模整合并转型成数字化业务平台以后，企业对系统平台的性能要求也越来越高，尤其是企业的核心业务更需要稳定，强壮的系统来支持，如何确保系统平台的健壮，成为了企业业务系统设计中非常关键的一个核心。
一般来说架构一个高性能的系统平台主要考虑的几个点：
1. 硬件: 包括CPU，内存，硬盘
2. 基础设施：网络，CDN
3. 部署架构：负载均衡，分布式运算，容器及虚拟化，服务编排
4.软件架构，这里集中讨论下如何从软件架构角度来如何来解决系统的高并发挑战，但即使如此也可以有很多点可以探讨，包括目前传统企业级应用里面已经使用的比较成熟的一些方案：
1. 使用中间件实现数据交互异步化以及数据缓存
2. 选择更强大的编程语言
3. 优化算法和数据结构，通过性能测试和监控找出瓶颈；减少系统调用和上下文切换
4. 数据库调优
5. 微服务架构替换传统Web架构
等等等等
但是以上列出的还是相对比较“陈旧的”架构设计，今天主要介绍一些更为新的软件架构设计，三部分组成：
- Actor模型和Tarant：在编程的层面，从细粒度-由下向上的角度介绍Actor模型；
- CQRS/ES：在框架的层面，介绍CQRS和ES连个设计架构
- 由上向下角度介绍如何结合Actor模型把CQRS和ES结合一起进行落地
本文的所涉及的编程内容主要是Nodejs技术栈，在这里没有语言纷争，彼此相互学习。比如：Scala中，Actor模型框架有akka, dotNet有Orleans模型架构。
Actor模型和Tarant
共享内存模型
多核处理器出现后，大家常用的并发编程模型是共享内存模型，比如一个常见的Java多线程应用是这样工作的
这种编程模型的使用带来了许多痛点，比如：
编程：多线程、锁、并发集合、异步、设计模式（队列、约定顺序、权重）、编译
无力：单系统的无力性：①地理分布型、②容错型
性能：锁，性能会降低
测试：
从坑里爬出来不难，难的是我们不知道自己是不是在坑里（开发调试的时候没有热点可能是正常的）
遇到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模型：Tarant
Actor模型这么好，怎么实现？
可以通过特定的Actor工具或直接使用编程语言实现Actor模型，Erlang语言含有Actor元素，Scala可以通过Akka框架实现Actor编程。这次使用了Node的Tarant框架。
特点：
Erlang和Akka的Actor平台仍然使开发人员负担许多分布式系统的复杂性：关键的挑战是开发管理Actor生命周期的代码，处理分布式竞争、处理故障和恢复Actor以及分布式资源管理等等都很复杂。Tarant简化了许多复杂性。
优点：
- 降低开发、测试、维护的难度
- 特殊场景下锁依旧会用到，但频率大大降低，业务代码里甚至不会用到锁
- 关注并发时，只需要关注多个actor之间的消息流
- 方便测试
- 容错
- 分布式内存
缺点：
- 也会出现死锁（调用顺序原因）
- 多个actor不共享状态，通过消息传递，每次调用都是一次网络请求，不太适合实施细粒度的并行
- 编程思维需要转变
看一下下面这个图，你就知道如何正确使用一个Actor模型
CQRS/ES（架构层面）
从1000万用户并发修改用户资料的假设场景开始
每次修改操作耗时200ms，每秒5个操作
MySQL连接数在5K，分10个库
5 *5k *10=25万TPS
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万并发场景的内容来自Github的PPT，与我们实际项目思路一致，就拿来与大家分享这个过程，下图是我们项目中的架构图：
开源版本架构图：
开源项目GitHub：https://github.com/RayTale/Ray
总结：由上往下，架构层面粗粒度层面表达了采用Actor模型的好处或原因。
