心知天气数据 API 产品的高并发实践
心知天气作为国内领先的商业气象服务提供商，天气数据 API 产品从公司创立以来就一直扮演着很重要的角色。2009 年 API 产品初次上线，历经十年，我们不断用心迭代，已经为数百家企业客户提供了超过 540 亿次稳定可靠的数据服务。在心知天气官网首页一直跳动的调用量数字就实时展示了整个天气 API 产品的服务状态。目前，心知天气数据 API 的 QPS 在高峰时期已经达到数千的量级，如何承载这样海量的并发请求，使客户能稳定及时的获取到所需数据自然也是心知技术团队一路以来不断探索的主题。
访问量特点
天气数据的基本属性和客户本身的业务需求决定了客户来如何调用我们的数据接口。对于部分使用我们数据进行数据展示的 2C 业务的客户而言，访问量潮汐跟人的行为规律有着明显的相关性，这大致表现为白天比晚上并发量更高；而对于部分使用天气数据做数据分析和研究或者其他需要批量请求天气数据的客户而言，他们大多会选择在整点时刻来批量请求不同的数据，所以整点时刻往往会有突发的高峰访问量。
在叠加了不同客户需求的总体 API 服务的访问量，可以看出以下几个特点：
- 以「天」为单位周期性明显
- 每天零点时刻并发量会激增
- 整点和半点时刻存在高并发小周期
只有了解了我们客户的需求特点，才能设计出更合适的技术架构来应对随之而来的挑战。
石器时代
在创业初期，「云计算」的理念开始兴起，创始团队在斟酌优劣之后，选择将整个系统构建于云服务提供商阿里云之上，如此一来心知天气团队也不必自己再手工搭建和管理需要的硬件资源，这对于创业公司而言是一个不错的选择。和大多数早期创业公司一样，囿于资源和技术积累，最早我们也是将 API 服务实例直接部署在阿里云 ECS 之上，对外通过负载均衡 SLB 提供统一的 API 入口。
随着心知天气数据服务体验的不断完善，客户数量也不断增多，API 服务所需要承载的流量也持续上涨。由于我们已经构建了上述这样的基础架构体系，在并发量最高的时期，我们需要手工维护高达 40 台左右的 ECS。而每个 ECS 上有自己独立但不完全一致的运行环境，不管是应对访问量突变还是部署新的版本，都无法做到比较快速的响应和执行。
在这个阶段，我们产品的 API 数据和逻辑都还比较简单，所有关于用户信息处理、位置服务和数据处理的逻辑都揉杂在一个单体服务中，最终部署时也是一个一个独立的单体式架构通过 SLB 共同对外提供服务。
青铜时代
随着心知天气数据种类的不断增多，数据处理和 API 服务的逻辑也变得各不相同，比如城市级数据和公里级网格数据就有着完全不一样的处理和取数逻辑。在这种情况下，基于程序的可维护性考虑，我们很快决定根据数据处理逻辑的不同将数据服务拆分为几个不同的微服务，各自对外提供不同的天气数据 API。而为了复用取数之前的权限校验、访问量和各种日志统计的逻辑，我们开始引入网关系统。
API 网关最重要的是性能和稳定性要足够好，所有的 API 请求都需要经过网关。在通过网关的校验之后，数据服务负责获取需要的天气数据，其结果再通过网关返回给外部用户。如此一来，不同的几个数据服务退化成无状态的纯数据服务，即每个数据服务节点不再考虑任何与用户相关的逻辑，只是简单的根据请求条件将所有处理好的数据从存储系统中取出后返回，网关作为唯一的请求入口来统一处理所有的权限校验和访问量、日志的各种统计。
基于开源的网关系统 Kong，我们使用 Lua 进行了大量的二次定制开发，从而形成了心知天气自己的一套网关体系。这套系统不仅满足网关基本的路由逻辑，还能更好的处理和我们自身业务深度耦合的用户权限校验、访问量统计以及以用户为核心的日志记录。Kong 天生也是支持集群的，所以在理论上我们可以无限横向扩展网关的处理能力。
在这样的架构之下，心知天气的 API 服务很好的遵循了「单一职责」的原则，使得我们的代码维护和版本更新都能以更快速且代价更小的方式进行。但另一方面，我们还是需要手工维护大量的 ECS 集群，甚至由于天气数据服务的多样化，手工维护多个不同种类服务的集群将面对更繁重的挑战。不过，由于我们将服务进行了更好的拆分和分层，变成了一个个更小的微服务，使得我们能把它们进行更好的分布式部署，进而可以横向扩展来提高整个服务集群处理并发请求的能力。这一阶段既是我们成功向微服务架构的转变阶段，也可以看作是我们迈向更现代的后端架构的过渡阶段。
黄金时代
Cloud-Native 的概念是 2015 年被首次提出的，随后就获得了技术社区的大量关注。顺着之前架构演进的思路，我们很快开始用 Cloud-Native 的理念来武装整个后端系统架构。在去年，我们正式开始用 Docker 和 Kubernetes 来改造和管理我们所有对外的线上服务，这些架构设计同时也与阿里云提供的云服务深度结合。
从网关到数据服务，目前我们都已经完成了容器化的改造，并且所有服务都使用 Kubernetes 来编排和管理，这意味着我们真正统一了各个服务的运行时环境，从而可以快速复制出新的服务节点。借助 Kubernetes，我们现在可以做到容器级别的自动伸缩，在并发量高的时候服务节点能够自动横向扩展以提高整个集群的并发处理能力，进而可以给用户提供更加优质稳定的天气数据 API 服务。
不仅如此，基于 Cloud-Native 的理念，我们还统一了各个服务的 CI（持续集成） 流程，优化了 DevOps 的体验，做到所有服务的标准化和归一化 —— 从此以往，万物皆容器。这对于今后产品的持续高效迭代和改进，也是有重大意义的。
总结
心知数据 API 产品历经十年，其后端架构也逐渐从传统的企业应用的开发模式转变为现代的 Cloud-Native 应用的开发模式，不仅极大的解放了团队的产品开发效率，而且能对外提供更加优质稳定的数据服务。心知天气从创立之初就带着鲜明的互联网风格，我们崇尚极客文化，技术团队也将继续带着勇于探索和敢于挑战的极客精神，用更好的技术与更优质的产品，为我们的客户提供更具价值的产品。