德比软件是全球顶级的酒店数据提供商，拥有超过20多万家酒店数据，在全球 14 个可用区里有2000 + 个服务节点,每天处理 10亿 + API 调用，所以对日志处理的需求更是刚需，从Splunk到ELK到KFC，德比软件架构师付学良分享了日志技术演变之路；

前言

大家好，我是德比软件的付学良，今天借助于中生代技术这个平台，给大家分享一下德比软件是怎么样构建自己的日志分析平台的；日程如下：

1

德比软件是为全球酒店集团和渠道分销商提供数据对接服务，目前拥有20万家酒店的数据，我们的客户有全球顶级的分销商，包括Booking，携程，还有一些搜索引擎比如谷歌等等

上面这张图上的每一个点，都是不同的系统，分布在世界不同的地方，而且每个点代表可能是酒店，酒店集团，或者是旅行社等；

德比软件就是链接各个点的那根线，德比软件修了这条路，让他们可以联系起来；

举个例子，大家在携程上面定了一个酒店，传统的模式是这样：

渠道拿到这个订单信息，发个传真给酒店，然后打电话给酒店确认，我这里有一个客人，你帮我处理一下，酒店集团就把客人的信息录入到自己的系统里面；

可以看到，传统的处理方式非常复杂，而且没效率；

德比软件的加入就改变了这种局面，把手动的动作弄成电子化，自动化；

德比软件会跟渠道说，你们给我开放一个API，我们会把订单抓出来，自动的送到酒店里面去；然后跟酒店说，你们的系统可以开放一个API，我们直接把订单送到你们系统里；德比软件就是做这两者之间的一个生意；

2

德比软件是一个比较典型的分布式系统，全球分布都有服务，有2000多个服务节点，日均API调用在十亿次，除了自己的数据中心，大部分的服务部署在AWS上面；

3

这两条日志分别来自于Apache和Tomcat；

都是一个时间戳带一条数据；

一般都是使用Linux系统，常用的方法都是ssh到服务器，然后用一些列的命令去查看，这在德比软件前期，业务量非常小的时候还是比较好用的；

4

不同的环境，比如开发环境，联调环境，正式环境查看日志的权限和方法是不一样的；包括像很多都没有正式环境去查看日志的权限；

同时，两个系统的联调，除了自己的日志需要保存下来，系统交互之间的日职业需要保存下来，我有m酒店和n个渠道，我们要处理的交互量就是m*n；所以这样大量的交互，对于日志来说，也是非常大的需求；

5

还包括存储日志

6

实际上是没有V1的版本，我去这个版本的时间应该是在08年金融危机的时候，德比软件游走在生死边缘；随着后来经济的复苏，我们开始有了一些业务，做了当时这样一个平台；

我们做了一个基于json的RPC接口，一直沿用到现在，比较基本，对Linux的一个基本操作，比如less，cat，tail等做了一个简单的封装；

有时候会一些需求，要求把测试环境的数据导到正式环境；

一般来说，测试环境和正式环境是需要隔离的，程序员是不可以登录到正式的服务器上去的，最简单的方法是在测试环境部署一套，但是我们认为这个没有必要；因为工作人员需要登录到两个不同的服务器去查看，我们希望对他的体验是一致的；

这是一个比较有意思kafka的代理服务器，它会在测试环境里面部署一台机器，然后通过这个机器就可以访问到kafka, 我用Python和Twisted，写了大概150行代码，这里贴了两个比较核心的方法；

我们处理的方式是做端口映射，我们知道kafka的端口是9092，那我们会在kafka的代理服务器上面开8081，8082，8084...一直对应到所有的kafka对应的端口上面去，我们会在客户端请求meta信息的时候，会把整个地址信息全都替换成Twisted对应的端口，最核心的就是把meta信息替换掉；

对于集群这块儿，通过kafka的zookeeper服务，很容易就扩展成集群式的服务，也就是说，发现一个Proxy不够用的时候，就变两个，甚至更多；

虽然说多了一层，可能会影响性能，但是多这一层可以做更多的事情，比如说定制化的安全服务，可以做定制化的统计等，在我们刚开始使用kafka的时候，连一个页面都没有，只是最近才有一个kafka manager的工具可以看一看，

我是使用Python写的，我查过一些资料，我不知大家有没有使用过Golang，据说性能是它的几十倍；

这就是我今天想要给大家分享的所有内容，谢谢大家！