挽救水深火热中的你——好用的分布式应用开发小工具

本文是数人云“分布式架构的开源组件大选”Meetup的实录分享。分享嘉宾是来自数人云的资深架构师春明。这次的分享带来一些好用的分布式小工具——gRPC、Raft、Actor,如何利用它们更好地做分布式应用开发,快来一睹为快吧!

今天的话题是一款基于Mesos的开发组件。数人云最近研发了一款分布式方面的应用,Mesos调度器的Framework——Swan。这次演讲与大家分享一下数人云用到的一些分布式小工具,以及一些开发上面的最佳实践。

gRPC——分布式RPC的库

gRPC是一款RPC的框架,类似于CS的程序或者是P2P的程序,gRPC非常有帮助。gRPC由两个部分组成,一是协议、定义部分,用Protobuf来做协议的定义;第二是它的通信,目前采用HTTP2,没有采用TCP或者UDP。

gRPC的优点

gRPC有几个优点:

  • 第一,在服务定义方面很简单,可以很轻松地搭建出一个RPC的调度或者是P2P相互之间调度的框架。
  • 第二, gRPC是语言无关、平台无关的,它有很多种不同的实现。如果写好一个Protobuf协议定义,可以轻松地去生成不同语言的协议框架。
  • 第三,它支持双向的流的调用,在做一个分布式系统或者是相互调用的系统时,如果有流的概念是比较容易的。

在使用Protobuf做协议通信之前,许多人倾向于采用一些XML,JSON去定义消息的格式,或者在C语言里面定义struct或java class去定一个协议,它们都有一个缺点,即不能在跨语言之间形成一个非常统一的序列化反序列化。所以Protobuf的出现定义一种消息格式,可以生成不同的语言,使用者再写一个针对不同语言的库去序列化或者反序列化这种结构。

下面为大家展示一个Protobuf的例子,上图中required表明这个字段是必须的,optional表示这个字段可有可无(新的语法在Protobuf3的 optional已经被去掉了)。里面没有体现的是repeated,repeated特别适合把数组放在这里。这个结构只是单层的,Person里面只有string和int32,它实际上还支持自定义的数据结构,把自定义的数据结构嵌起来。大Field后面的1、2、3数字,很难在其他语言里面见到这种写法,但在Protobuf很关键,它根据string占多少、int32占多少,以及这些索引定位字段。

一个游戏Server的例子

接下来我用亲身经历向大家展示在做网络应用时,gRPC使用之前和之后的差别。这个工具虽小,但是对大家的开发非常有帮助。

开发一个CS结构应用或者是P2P的应用,如果有相互之间的请求调用或者是方法调用,首先会考虑几件事情,第一件事是网络通信,选择TCP、UDP还是HTTP,在传输上采用什么协议,XML还是JSON等等。根据每个项目会有不同的选择,比如HTTP更倾向于非常简单的请求应答的场景,一些流的应用更多考虑TCP或者UDP的应用。在很多游戏里面,比如端游UDP采用得比较多,为了更高的性能,能容忍UDP产生的一些乱序的问题或者其它的问题。而传输协议的选择,也有很多选择方面的平衡。

2012年我参与了一款游戏后端的设计,采用的一个技术栈是Protobuf在TCP上的传输,语言和框架是NodeJS,当时没有gRPC非常痛苦。这种类型的游戏特点是许多玩家在同一个屏幕里,不同的玩家有不同的操作,上面很多AI不断的移动、不断的掉落或者是打斗。要把所有的客户端怪物的移动或者是人的移动都传输到后端平台,在另外一个玩家的屏幕上反馈出来,它的特点是移动的包和心跳的包多且频繁,占据了超过50%以上的流量。这一类包体积特别小,只要说明哪一个AI大致在什么位置。另一个特点是心跳包特别频繁,为了保证反馈尽量实时,所以心跳包基本在50毫秒或30毫秒。

当时选择TCP+Protobuf这种形式。如上图所示,首先把一个AI移动的包写成一个Protobuf,然后把它一个一个排在TCP的管道上。要写入这个包有多长,接着序列化之后的Protobuf包放在后面,接下来是第二个包,第三个包,依次排下去。在接收端从内核里拿到TCP的包,它与在发送端的发的包大小未必一致,因为内核会等待用户空间的包足够大再一起发出去,这是Nagle协议决定的。所以这时候在接收端要处理这种场景,把多个TCP的包黏起来。比如期望20个比特,第一个TCP包只来了15个比特,另外5个比特在下一个TCP的包,要把这些TCP的包黏起来,所以这些小细节都是没有用框架的时候需考虑到的。

最常用的做法是把内核上来的一些小Protobuf的包拷贝到程序里面,然后做解析、做相应的处理。这时又带来一个问题,需要频繁地去内存申请小的内存空间来存储从内核里流过来的包,程序在不停地申请,申请一段空间然后再释放一段空间,对GC来说非常有挑战。这时需要考虑一些其它的技术,比如预先申请,在heap里申请空间预留着,尽可能重用。

自从有了gRPC以后,就不再需要去考虑上面这些细节。

gRPC Demo举例

上图展示如何通过gRPC搭建一个CS的程序。前两个message,第一步是发一个request,第二个是response,核心的定义一个gRPC的service在下面。可以看到有rpc的关键字,比如数人云举办会议,想要Apply,参数是MeetupRequest,希望返回值是MeetupResponse。

接下来Protobuf Definition会生成几个部分代码,第一部分,前两段消息结构定义,Go语言会生成两个Go的struct,同时还有一些struct对应的方法。另外,service部分会生成两个代码,一个是server端代码,server需要有一个handler去处理apply的请求,在Client端会发出这个要求。

protoc是一个小工具,能把一个Protobuf的定义转化成不同语言。它支持了非常多的语言,比如Java、PHP、C++、.net等等,它同时支持一些plugin,plugin能解析比如上一步RPC的那个关键字,同时生成一些server框架性的代码。
这是request和response生成以后的Go的代码,刚才那步定义了两个结构体。 Protobuf其相当于协议的定义了,它支持从别的地方import,即能达到一定的重用。一旦能够重用,就可以组合成非常多有意思的东西。

这是Protobuf生成了Client端的代码。核心是apply的方法,它接受了context,context是Golang常见的概念,对一些IO的调用或者是数据库的调用,它可以传一些value进来或者说是从外面cancel处理。

然后看第二个参数,在协议定义里的request。它期望response是一个meetup response,里面做的事情是gRPC调用了server端一个RPC的地址。从这里可以看出来是HTTP的请求,第二点应该是一个Path。这是server生成的一段小的代码, Meetupserver其实是接口,这就提供了一些实现上的扩展性,只要实现apply的方法。

这段例子是server端的小例子, Meetup实现了apply的方法,于是它实现了上一步见到的MeetupServer的接口。最下面的第五行,关键是把写的一个小server注册上,很像一个HTTP的handler。最终搭建了简单的、根据protobuf的定义生成一个小server。

上图是一段client的程序, gRPC很常见,最常见的是net.dial,相当于客户端去连服务端,再返回来连一个connection。后面的参数其实可变长的,这里面有很多选项,可以参考一下文档。

以上演示了一个最简单的gRPC调用小工具,工具虽小,但是可以节省大量的时间。

Raft——分布式Consensus的算法

为什么选择Raft

数人云在做Swan的时候,希望它是高可用的。很多人对Ratf的翻译是“分布式系统一致性”算法,“一致性”并不太精准,一致性对应另外一个词就是consistency。 而Raft是consensus,几个节点通过某种协议达到了一致性,大家对Raft协议本身想了解更多的话,这里两个地址,第一个是Raft的一个论文,第二个是GitHub上Raft动画演示,详细的展示Raft的选举和log replicates步骤。

https://raft.github.io/raft.pdf
https://raft.github.io/

Raft帮助解决什么问题呢?比如它一部分的服务倒掉了,不会影响整个的服务。众所周知的CAP原则,作为分布系统来说,从用户的角度来看,第一个原则尽可能是一致性,比如说先写一次,紧接着去读它,希望它的结果是我们期望的;第二个是可靠性;第三个Partition tolerance,一部分服务异常,不要影响整个的服务。大家在写分布式的时候尽量满足这3个原则。

写分布式核心的时候程序在一个节点或者是多个节点上执行,实际上是有状态的state machine,尽可能保证对state machine一致性,如果不能保证一致性的话,尽可能保证它的最终一致性。如何保证一致性?state machine通过log entry,把log entry apply到多机的state machine上来,以此保证一致性。

Raft的功能特点

Raft的feature,第一是在整个集群或者集群是一部分能选出一个leader;第二个功能是复制log并且保证log的复制过程中是安全的有序的;第三,如果在新加入节点到一个集群时,非常多日志需要同步到新的节点,它有日志压缩的feature。

Raft目前很多实现,各种语言都有不同的实现,第一个是被认为最广泛的go-raft实现,第二个是Consul的实现,第三个是Etcd的实现。Etcd的实现是go-raft的基础之上完成的。我们最终选的是Etcd Raft的实现。原因如下:第一非常流行,声称目前使用人数最多的也最稳定,它做过很多的优化,代码很多处理非常优雅;第二是因为它的算法部分和周边松耦合,算法的使用者可以实现自己的存储模式和传输上的协议;第三用户群体广泛,SwarmKit, Etcd本身,以及PingCap的TIPV等等。

Raft使用举例

举几个使用Raft的例子。第一个例子由Etcd提供(https://github.com/coreos/etcd/tree/master/contrib/raftexample ),第二个是SwarmKit的实现(https://github.com/docker/swarmkit/tree/master/manager/state )。

上图展示如何启动一个Raft node的例子,可以看一下关键逻辑是怎么处理的,有些数据是如何存在Ratf cluster并且让它持久化的。第一行说明需要一个storage,Raft算法层面和存储的层面是分离的。从第二行设置启动一个Raft node的一些配置,electionTick表示Raft做选举时Interval是多少。 接下来第三个参数是从Raft一个leader节点到心跳节点,第三个存储,第四个、第五个限制了消息传递,最后一个是如何raft node的节点。第二个参数说明在启动一个集群的时候,另外两个节点ID是多少。Ratf能在运行时添加一个节点。用SwarmKit做的话,可以添加无限多的节点,并且可以把一个node的节点promote成manager节点,在SwarmKit里 manager节点就是参与Raft选举节点,也就是可以在运行时增删一个集群的节点。

上图是一段伪代码,模拟的是一个ratf node起来之后需要做哪些相应的处理。比较关键的是s.node ready,每个term,ready会提供一些数据,包括rd state当前的节点是什么样的状态,第二个说明里面有哪些log entry没有在persist里,需要persist掉。第三个是snapshot,raft的log compaction,做一些log的压缩。send做的操作是从一个节点到其他节点发送数据。对于for循环,rd committed entries是整个的关键,message可以apply到State Machine里。node.advance节点可以进行下一步的操作。

这条语句表明如何把自己的data去放到raft cluster做存储,这个数据其实没有真正的存储,只是异步第一步。

刚才讲到raft cluster在运行时可以增删这个节点,confChange的结构可以有几大类型,节点要增加,移除或者有变化,某节点的增删信息放到cluster进而通知其他的节点。

Actor模式和事件驱动

分布式系统最复杂的部分不在于选择协议、传输,或是哪一个小工具,而是写一段大型的异步、分布式的代码,如何组织代码就需要一个指导来构建架构,这部分我们参考了actor。

过去写代码很多人倾向于写一个网络服务的代码,数据包来了就解包,然后放到不同的线程中,在这个过程中,更多是不停地修改一些共享的存储,如果是面向对象,在object的外面修改field或者通过方法修改它,调来调去发现有点混乱,尤其是更多的人投入进来的时候,大家不知道如何去协调通信,也不知道是否存在锁的问题,非常麻烦。

什么是actor?写一个数据包,封装了一个golang的goroutine或者Erlang的的process,这本身是一段代码,数据也放在那里,通过一个mailbox,以此达到操作数据在不同的object,尽可能的减少互相修改field,减少锁的问题,每个actor接收到发送到自身的消息,做出相应反应。此外actor把数据和operation放在一起,尽量和其他的actor做隔离。

Erlang 的OTP里面的gen-server是actor典型应用之一。这里展示了一个最简单的gen-server。里面最核心的是后面接口部分, call和 cast,call是发一个同步的请求,cast是发一个异步请求。同步的请求是希望actor给 response,cast是发一个message不需要response。

数人云开源项目

下面介绍数人云两个开源项目,分别是容器管理面板Crane和Mesos调度器Swan。Crane是数人云做的Docker UI的项目,如果大家用过Docker UCP,Shipyard都可以考虑一下Crane,除了Docker集群的UI以外,还有Registry集成、账号相关的功能以及周边的feature。数人云之前用了很长时间的Marathon,后来扩展方面有些困难,于是有了Swan的诞生,把一些代理功能、proxy功能、DNS的功能、一容器一IP的需求等都放在了Swan里面,欢迎大家去提一些意见。

https://github.com/Dataman-Cloud/crane
https://github.com/Dataman-Cloud/swan

今天就给大家介绍到这儿,谢谢大家。