Maples7's Blog

Elixir 作为基于 Erlang/OTP 的年轻语言，拥有良好的并发模型设计，在 Web 场景下对于实现能承载高并发的服务毫无问题。有好事者对比过包括 Phoenix 在内不同的 Web Framework 的性能，可见如果采用 Phoenix/Plug 来实现 Web Server 在性能上不会有太大的问题（代码实现良好的情况下）。所以，本文不会讨论真正的工业生产环境下整个系统的性能状态，因为系统性能受到很多因素的影响，具体编程语言的运行时的执行效率往往不是真正的问题所在，与其考虑编程语言本身的运行时效率，不如探讨系统在具体架构和实现上如何能优化来承载更高的负载来得实际。在生产环境中，我们可以借助 APM 服务来监控系统状态和性能指标。

由于 Elixir 本身是基于 Erlang 的更高层次的抽象，所以直觉上我们会觉得 Elixir 在运行性能上应该比 Erlang 本身要差一些。实际情况是不是这样呢？Elixir 相比于 Erlang 而言，为我们提供了一些可以快速调用的高阶函数库，典型的有 Enum、Stream，提高了日常实现需求的开发效率，可以让代码实现得更清晰且更易维护。而更高的抽象又几乎必然意味着底层的实现逻辑需要更通用健壮，从而也会更复杂。更高的抽象程度似乎天然与更高的运行效率有着内在的矛盾。本文的焦点在 Elixir 代码的运行性能，即对于实现同样的功能，用哪样的 Elixir 实现方式会让代码在运行时跑得更快。

背景介绍

稳定高效的进行数据处理几乎是如今每一家互联网公司都要面临的课题，尤其是对于专注于气象数据研究的我司而言，做数据分析和 ETL 的工作是整个公司业务很重要的一部分。在脱离了原始的「刀耕火种」的时代之后，我们内部一直在使用 Airflow 作为数据处理流程的框架来管理日常的数据流任务。其实我们也调研了很多其他的方案，最后还是选定了看起来相对比较可靠也比较符合我们业务需求的开源项目 Airflow 来做这个事情，虽然在使用的过程中确实也遇到了不少坑。当时这个项目还在 Apache Incubator，目前已经顺利毕业了。

简单介绍一下 Airflow，一般由 WebServer（一套完整的 UI 界面用于随时查看任务的执行状态并可以手动执行一些操作）、Scheduler（用来做任务的调度和管理）、Worker（真正执行任务的部分，可能有很多个）组成。这是一个常见的分布式架构，你只需要把任务流的 DAG 用 Python 代码写好，然后配置好触发条件就可以让它长期运行下去。在实际生产环境中，我们大量使用了 Celery Executor 来把任务动态分布到多个 Worker 上执行。

心知天气作为国内领先的商业气象服务提供商，天气数据 API 产品从公司创立以来就一直扮演着很重要的角色。2009 年 API 产品初次上线，历经十年，我们不断用心迭代，已经为数百家企业客户提供了超过 540 亿次稳定可靠的数据服务。在心知天气官网首页一直跳动的调用量数字就实时展示了整个天气 API 产品的服务状态。目前，心知天气数据 API 的 QPS 在高峰时期已经达到数千的量级，如何承载这样海量的并发请求，使客户能稳定及时的获取到所需数据自然也是心知技术团队一路以来不断探索的主题。

今年的个人状态要比去年好多了，好在心态的逐渐平和。毫无疑问，今年要比去年忙很多，工作和生活都是如此，不过事情也开始越来越聚焦，大概是一种越来越明白自己在做什么以及为什么要这样做的状态。

回到「书单」的正题。在之前的年终书单总结中，我说过一般用 iPad 看电子书，今年引入了一个新设备 —— Kindle PaperWhite 4（官方名称是 “All-new Kindle Paperwhite”），这是目前为止最轻的一款 Kindle。之前我一直不理解用 Kindle 看电子书比用 iPad 看电子书好在哪里 —— 忍受着上世纪电子设备的响应速度，使用着非常有限的功能，就为了墨水屏？不用不知道，在真正使用了 Kindle 之后我发现，所有的「轻薄」、「有限的功能」、「电子墨水屏」等特性，都是为了让你在阅读时更加专注 —— 避免打扰、减少疲劳感。从中我体悟到一个道理，任何细微而又专注于目标的优势都不应该被忽视，它可能是一个产品制胜的关键。Kindle 所有的设计都是为了「阅读」这一场景而设计，尽管 iPad 有着丰富得多的功能，但对于体验敏感的用户来说，在「阅读」这件事情上还是会为了用户体验而买一个 Kindle。细小而专注的优势，很重要，不仅仅适用于电子设备产品，也适用于每一件事、每一个人本身。