从Python迁移到Go，性能提高了10倍；微软Azure Event Hubs单月处理交易超1万亿次
向世界各地的企业和组织提供文本分析服务。随着公司的发展，他们每天处理的文本段数量从5亿增加到10亿，其中包括Tweet、新闻文章、博客评论、用户反馈等。大规模的文本分析非常困难，因为很少会出现两段文本完全相同的情况，所以无法利用缓存来提高效率。不过，它可以将大段的文本分成多个句子，然后并发分析每个句子。近日，Repustate官方博客发表了一篇，介绍其API的演进过程。
Repustate API的第一个版本是用Django编写的。他们构建了一个原型，并以此为基础推出了他们的服务。但每个Django请求/响应周期的开销太大。随着API访问量增加，可靠性问题凸显，使用Amazon服务的成本也大大增加。于是，他们开始寻找一种Python代替方案，并选择了。Flask几乎是现成的API，而且是轻量级的。不过，他们稍后又发现了。他们非常喜欢这个框架，因为它使用进行了优化，速度比Django要快许多，而且它还遵循简洁REST原则。事实证明，Falcon是一个很好的补救方案。Repustate的平均响应时间缩短了，故障和支持问题的数量也降下来了。
但即便如此，Repustate的性能仍然不能满足日益增长的需求。尤其是并发，一直是Python的痛处。而且，他们用的是Python 2.7，还没有使用Python 3中的包。但实际上，即使用了，也还是要担心的问题。并且，Falcon无法实现自托管部署。Python无法像Java或C那样打包，然后分发。而他们的许多客户需要在自己的网络中运行Repustate，他们只能为这些客户提供一个部署了整个技术栈的虚拟应用。该虚拟应用既可以用于VMware，也可以用于Virtual Box。这是个可行的方案，但很笨重，而且更新和支持困难。所以，他们希望能够仅仅提供一个可以安装的二进制文件。
之所以选择Go，是因为Go满足了他们所有的要求：
比Python快
可以编译成单个的二进制文件
可以部署到任何操作系统
容易实现并发
而且，Go测试套件的布局看上去比他们的测试要简单。测试函数头很容易迁移。例如，将def test_my_function():转换成func TestMyFunction(t *testing.T) {，通过简单的替换就可以完成。此外，go routines和channels非常易于使用，使得并发文本分析很容易实现。
整个迁移过程耗时3个月，感兴趣的读者可以查看他们的。下面是他们的迁移成果：
API平均响应时间由100ms降至10ms；
所需EC2实例的数量减少了85%；
由于Go可以编译成一个单独的二进制文件，而Go 1.5让交叉编译变得很容易，所以他们现在能够提供一个Repustate自托管版本；
由于Python和Go相似，所以他们能够快速重建单元测试。
另外，由于重新过了一遍Python代码，他们还做了许多与性能无关的改进。因此，该文指出：
如果时间允许，回过头来看看旧有的代码总是好的。你也许会惊讶，它怎么会那么差。
微软Azure上消息服务系统Event Hubs在六月份每天大约处理150 TB的数据和300亿条消息，或者说每秒处理375000条消息，这些数据是微软Azure Service Bus产品团队的。
Azure Event Hubs是微软Azure公有云上发布/订阅消息的注入引擎。Event Hubs使用AMQP作为基础协议，并允许同其它的AMQP 1.0库和代理（broker）进行互操作。这项基于云的服务在2014年11月份发布了通用版本之后，于今年的8月份到达处理交易量的顶峰，即每天可以处理600亿次交易。
开发者可以通过REST API、.NET SDK或者Apache Qpid客户端库来访问Event Hubs服务。除了这些，一个基于Proton创建的C语言的SDK也规划于近期提供。
为了更好地了解这个里程碑事件的意义，以及微软此项业务后续发展的方向，InfoQ接触并采访了微软的高级项目经理Dan Rosanova。
InfoQ: 对于运行如此大规模的消息平台来说，什么方面的问题是最具挑战的？
Dan: 最大的挑战是你要跟上需求，我们经常要经历周与周间两位数的处理量增长，所以我们需要持续不断增加系统容量。我们在系统容量上线和确定它们能被很好使用之间保持了一定距离。只有在这些都完成之后，我们才能确定人们已经理解如何有效地使用我们的服务。同时，我们还在持续不断的学习和改进。
InfoQ:你们是如何提供这种大规模的消息处理平台并与其它竞争对手一较高下呢？
Dan: 当前云上消息系统的竞争格局非常有趣，这里面有一些知名企业，如Amazon，谷歌也刚刚完成发布/订阅系统的beta版本测试。另外还有一些不是那么出名的公司正在做一些创新性的事情，这些事情和大公司做的事情完全不同。在大公司中，我们在消息服务上实际走了一个完全不同的方向，因为机遇或者设计原因，我们的系统可以很好地应对不同的业务。我们可以自信地说我们有着市场上最富特性的PaaS消息系统，即我们的Service Bus。任何有传统企业消息系统背景的人在使用Service Bus时都将会感受到轻松自如。
InfoQ:在哪些行业的解决方案中可以应用Azure Service Bus消息系统呢？
Dan: Service Bus消息系统可以应用在众多行业的商业解决方案中，包括零售、航空、汽车、交通管理、制造、银行、保险和能源。在微软内部，那些需求量最高的业务也都在使用Service Bus，比如Office365、Dynamics CRM和那些引起轰动的游戏，如Halo。
InfoQ:那么这个系统接下来还会有哪些令人期待并能使用户受益的能力呢？
Dan: 我们刚刚了Azure Service Bus Premium Messaging的公开预览版本。这个服务提供了所有Service Bus消息系统的特性，它提供了Queues（队列服务）和Topics（主题服务），并结合资源隔离来保证更加一致和可重复的性能。实际上，这意味着你可以通过所有性能的提升和对IaaS的控制来得到Paas的所有益处。它还可以使我们相比在共享环境下面提供更高规模的消息处理能力。我们会在内部持续地改进我们的服务并定期增加新的特性。我们的目标是确保我们的服务可以解决多样化用户基础的需求。
▣ 版权归属InfoQ，禁止私自抄袭转载。
回复关键词：React | 架构师 | 运维 | 云 | 开源 | 物联网 | Kubernetes | 架构 | 人工智能 | Kafka | Docker | Netty | CoreOS | QCon | Github | Swift | 敏捷 | 语言 | 程序员
投稿可勾搭：
邮箱：editors@cn.infoq.com
合作QQ：1073600161