Flash----一种VirtualActor模式的分布式有状态系统原型

首先, 这个Flash不是我们在浏览器用的Flash这种技术, 而是:

动作缓慢, 车速极快------闪电(Flash).

18年的某一个周末, 即兴用Python写了一个Virtual Actor模式的demo, 起了一个名字叫Flash, 是因为速度快如闪电------做framework快, 通过framework写逻辑快.

所以大言不惭, 叫Flash, https://github.com/egmkang/flash. 第一个版本是asyncio写的, 但是编写的过程中发现一旦少写一点东西(async/await), bug会很难找. 这一点和C#是不太一样的, 所以第一个版本可以跑之后, 花了一点时间把asyncio的代码换成了gevent.

这边主要来说说当时的想法, 以后未来如果要做类似的东西, 该如何选择. (README里面的东西可能和实现没多少关系......懒, 所以也不打算更改README, 错了就错了)

当时为了实现一个去中心化, 可以横向扩容, 可以故障迁移的有状态framework. (很显然我对无状态的东西一点兴趣都没有:-D)

所有有几个关键点, 这边简单介绍一下(因为代码不一定能跑起来, 但是思想可以):

1) RPC

　这边没有使用第三方RPC库, 而是选择自己实现看了一个. 在Python这种语言里面, 实现一个RPC还是比较简单的, 所需要的例如future/promise, 序列化库, 协程, 还是就是Python是动态语言, 所以造一个Proxy对象比较简单(C#里面是DispatchProxy).

future/promise选择了gevent.event.AsyncResult.

序列化库选择了pickle, 序列化这边做法实际上是有一点问题的, 第一个就是pickle效率较低, 数据比较大; 第二个就是RpcRequest/RpcResponse协议的设计不对, 因为Python的args是没有经过序列化直接塞到RpcRequest里面的, 所以没看出来有啥问题, 但是如果是其他语言这样就行不通了. 所以比较科学的做法还是brpc那种, 包分成三部分: 包头, meta, data. 其中meta用来形容data数据和请求的元数据, 这样的话, args数据就不会被encode两次. python里面可以这么搞不代表其他语言也可以这么搞.

Proxy对象的话, 是自己造的. 在rpc_proxy.py里面, 通过重写__call__元方法, 实现比较复杂的功能. C#的DispatchProxy也能实现这种功能, 而且功能更强大, 类型还是安全的, Python里面做不到类型安全. 不支持动态代码生成的语言做这个都不太好做, 例如golang/c++等.

哦, 还有就是网络库里面一定要注意send和sendall这两种东西的区别, 对于用户来讲sendall代码容易编写, 但是用send实现就需要注意一下返回值, 否则可能发了一半数据, 然后对面收到的流是断的.

2) 服务发现

元数据存在etcd里面.

每个进程拉起来的时候, 通过uuid生成一个唯一的id, 当做ServerID, 然后组成一个MachineInfo, 然后就开启了一个update_machine_member_info的死循环, 去etcd里面不停的去更新自己的信息(有一个5s的CD).

然后再开启一个get_members_info死循环去不停的刀etcd里面pull最新的membership信息, 然后再保存到内存中.

这样在MemberShipManager里面就可以不停的add_machine, remove_machine.

这样做的话, 只需要经过几个TTL, 集群的所有节点就能感知到成员的变更; 成员和etcd失联, 那么就应该自己退出(Flash里面没做).

3) 对象的定位

上面说了, 集群内的节点对其他节点的感知实际上是靠定时pull etcd信息来获得的, 那么新加入的节点, 就不能立马提供服务, 否则集群元数据是不一致的. 例如5s间隔去pull, 那么3个interval之后, 其他节点大概率是能感知到节点的变更. 所以等一段时间再路由新的请求到新增服务器, 可以做到更好的一致性.

然后, MachineInfo内有服务器的负载信息, 那么:

0> 先到进程内缓存区寻找对象的位置, 看看最近是否有人请求过, 如果目标服务器健康(保持心跳), 那么直接返回

1> 先去到etcd里面查询对象的位置是否存在, 如果存在, 并且machine健康, 那么直接返回(并缓存)

2> 对对象上分布式锁(通过etcd), 然后再做步骤1>, 还未找到对象的位置, 那么获取到可以提供相应服务的machine列表, 通过负载权重, 随机出来一个新的服务器, 然后保存etcd, 保存进程缓存, 返回

很明显, 对象的定位是通过客户端侧+带权重的Random来做的. 这只是一种选择, 完成一个功能有很多选择.

4) 故障迁移

对象的定位有一个检测目标服务器是否健康的过程, 实际上就是目标服务器是否最近向etcd更新过自己的心跳, 如果更新过那么认为健康, 否则就是不健康.

那么, 当目标服务器不健康的时候, 就会触发对象的再定位, 从而实现故障的迁移.

5) 可重入性

互联网的服务不存在这个问题, 是因为互联网的无状态服务, 不存在排队等候处理请求的过程.

但是在有状态服务里面, 往往会对同一个用户(或者其他单位)的请求进行排队. 那么试想一下, 排队处理A的请求, A又调用了B, B又调用了A. A的请求没有返回之前是不能处理其他的请求的, 所以这时候就死锁了. 所以有状态的Actor服务必须要处理这种情况.

这时候需要引入一点点代码, 来看看RpcRequest的数据结构, 里面吗包含了一个request_id, 但是在request_id之前有一个host. 实际上就是这俩数据, 决定了rpc请求的可重入性.

class RpcRequest:
    def __init__(self):
        self.clear()

    def clear(self):
        self.host = ""
        if _global_id_generator is not None:
            self.request_id = _global_id_generator.NextId()
        else:
            self.request_id = 0
        self.entity_type = 0
        self.entity_id = 0
        self.method = ""
        self.args = ()
        self.kwargs = dict()

思考一下, Actor请求的一个请求是谁发出的? 肯定是外界系统产生的第一个请求, 那么这个请求没有完成之前, 是不能处理其他请求的. 而中间的请求实际上都不是源头. 所以我们只需要在源头上面标记唯一ID, 中间传染的路径上面都用源头的唯一ID, 所以系统里面有一个ActorContext的概念, 就是在保存这个信息. Dispatch的过程也就变得比较简单:

    if entity.context().running is False:
        gevent.spawn(lambda: _dispatch_entity_method_loop(entity))

    if entity.context().host == request.host and entity.context().request_id <= request.request_id:
        gevent.spawn(lambda: _dispatch_entity_method_anyway(entity, conn, request, response, method))
        return
    entity.context().send_message((conn, request, response, method))

如果对象的loop不在运行就拉起来, 如果现在正在处理的请求和当前需要被Dispatch的请求源自一个请求, 那么直接开启一个协程去处理, 否则就塞进MailBox等候处理.

从而实现了可重入性.

Flash, 麻雀虽小五脏俱全, 实现不是很精良, 但是作为一个原型, 其目的已经达到. 可以对其实现进行反思, 组合出来更合理的分布式有状态服务系统.

世人都说Python的性能差, 但是这个原型系统一秒可以跨进程进行1.5~2.2Wqps, 已经非常优秀了. 有没有算过自己的系统到底要承载多少请求, Python真的就是系统的瓶颈?

参考:

0) Flash (https://github.com/egmkang/flash)

1)Orleans (https://dotnet.github.io/orleans/)

2) gevent (http://www.gevent.org/)