SendGrid是如何扩展它的邮件传送系统的

SendGrid 是一个基于云的电子邮件服务，它的后端架构从小型Postfix演变为托管在自有数据中心以及公共云上的系统。使用 Go 语言重写服务，逐步迁移到AWS，使用基于Ceph的分布式队列，团队因此每月可以处理超过400亿封电子邮件。

SendGrid的初始架构由边缘节点组成，这些边缘节点通过HTTP和SMTP API摄取用户请求，并将它们发送到基于磁盘的队列中。这些请求在到达实际发送电子邮件的邮件传输代理（MTA）之前，会先经过一系列处理器。这种架构的潜在缺点——处理延迟以及由于节点故障导致的数据丢失——让工程团队转向使用由分布式文件系统提供支持的基于拉的模型。随着AWS基础设施的采用，他们更多地使用AWS的托管服务。InfoQ采访了SendGrid首席软件工程师Seth Ammons，了解到更多的信息。

他们在演化系统方面做了很多工作，包括使用Go语言和 Python 重写了很多系统、迁移到AWS托管服务、使用分布式队列，并采用日志聚合和监控系统来实现可见性。分布式队列系统是一种由Ceph提供支持的定制解决方案。 Ceph 是一个开源的存储平台，通过复制实现内置的容错机制。Ammons表示，SendGrid目前在自有数据中心运行Ceph，他们“正处于评估这些AWS工作负载的早期阶段”，因此将在未来面临HA方面的挑战。

SendGrid的监控系统由Graphite（作为指标收集引擎）和Grafana（作为查看指标的前端）组成。他们使用 工具 将它们推送到Kafka和Splunk来实现日志聚合。Pagerduty负责基于来自Splunk Alerts和 Sensu 检查的事件发送警报。Graphite存在规模问题，那么SendGrid是否面临伸缩性问题？Ammons说：

我们遇到了一些与伸缩Graphite有关的问题。我们首先想到的是调整保留策略，并确保能够正确地聚合指标。我们采取的其他措施包括用更高性能的carbon-c-relay替换carbon_relay。度量指标通过carbon-c-relay服务器池前面的负载均衡器进入管道，这些服务器可以在后端存储出现问题的情况下将指标保存在内存中。我们还在后端存储服务器池中复制指标并对它们进行分片。

SendGrid在测试方面面临的挑战随着架构演变而加剧。因为变更导致的生产中断可能会导致电子邮件丢失，因此团队的目标是提高单元测试和集成测试的全面性。由于电子邮件可传递性是成功的关键指标，SendGrid的系统集成测试会验证端到端的可传递性。由于存在大量的电子邮件客户端，而且每个客户端都有许多不断变化的版本，因此保持测试更新是一项巨大的挑战。Ammons阐述了他们解决这个问题的策略：

我的团队专注于 SMTP状态码 ，我们对错误代码和错误消息文本进行了扩展。由于这些响应会随着时间的推移而发生变化，因此我们成立了一个可交付性顾问团队，以确保我们能够以最有效的方式处理电子邮件。该团队密切监控主要收件箱的响应趋势，并维护了一个响应表，用于映射处理这些响应的规则。在处理来自收件箱的响应时，MTA代码将引用这个表。

他们的单元集成测试使用了Docker。开发环境也使用了Docker，其中 Docker 的compose文件被用于管理所需的整个容器集和依赖项。然而，该团队“目前处于容器采用的过渡状态”，Ammons说：

对于遗留应用程序，我们在开发和CI过程中使用了Docker。在大多数情况下，我们的CI系统会基于容器化的环境生成工件，这些工件可用作要部署的RPM。我们在自己的数据中心运行新服务，并开始使用Kubernetes作为容器编配器。声明式的配置更为简单，一些团队已开始利用Helm来管理在数据中心或环境之间的配置变化。我们正处于评估如何在AWS中解决这些问题的早期阶段。

大量的应用程序指标和日志记录以及基于这两者的警报减轻了dev和prod之间的差异所带来的挑战。对于配置管理，SendGrid的遗留代码使用由Chef管理的环境变量——团队已经使用了很长时间——以及他们的配置库。代码部署通常需要经过审查、签名、合并到Github的过程，然后将二进制文件推送到他们的仓库服务器，然后再推送到生产环境。

查看英文原文： How SendGrid Scales Its Email Delivery Systems