从单体到微服务：使用服务网格迁移 Snap 的架构

经过两年的架构演进，Snap 从单体迁移到了云托管的微服务，这使得计算成本降低了 65%，同时减少了冗余并提升了客户的可靠性，所有的这些迁移都满足了安全性和隐私合规性的需求。

面向服务架构为工程师提供了可扩展性和所有权。开源的边缘（edge）代理Envoy是核心的构建块，能够为服务间通信创建一致的层。内部的 Web 应用 Switchboard 构成了 Snap服务网格的控制平面，它为服务的所有者提供了一个地方来管理他们的服务依赖。

在过去的两年间，云基础设施不断演化，Snap 已经从Google App Engine中的单体应用转变成了Kubernetes中的微服务，其中 Kubernetes 可以跨 Amazon Web Services 和 Google Cloud。

从零开始实现基于微服务的系统时，会面临一些挑战，包括对现有底层基础设施的考虑，如网络拓扑、认证、云资源供应、部署、日志和监控、流量路由、限速以及 staging 与生产环境。

正如Snap的工程博客中所描述的，为了找到一个可行的方案，他们也考虑了 Snapchatters 当前的经验。文中也指出，他们没有一个专门的团队，因此没有时间实现这项计划。

Snap 没有从头开始，而是决定使用开源的边缘代理服务 Envoy，实现其服务网格设计模式。

Envoy 提供了很多特性，比如支持 gRPC 和 HTTP/2、客户端负载均衡、可插拔的过滤器、借助一组动态管理API（如xDS）所实现的数据平面和控制平面的清晰分离。随着 AWS 和 Google Cloud 都提供了可用的 Envoy，于是 Envoy 就成为了 Snap 中服务与服务间的通信层。在 Snap，每个 Envoy 代理都连接一个自定义的控制平面，通过 xDS API 接收服务发现和详细的流量管理配置。

在使用服务网格的过程中，很重要的一点就是解决 Envoy 中关于移动客户端通信的问题。除此之外，当在 AWS 和 Google Cloud 上同时运行时，工程师要站在安全的角度管理他们的 Envoy 配置。

由此，形成了 Snap 服务网格。Snap 有一个名为 Switchboard 的内部 Web 应用，它担任 Snap 服务唯一的控制平面，这样服务的所有者就可以管理他们的服务依赖了。

Switchboard 配置的核心是它的服务。每个服务都有一个协议和基本的元数据，如所有者、email 列表和描述。这些服务所组成的集群可以位于任意的云供应商、可用区或环境中。Switchboard 服务有它们的依赖和消费者，也就是其他的 Switchboard 服务。如果 Snap 当时把整个系统的 API 接口全部暴露给工程团队的话，那么将会有大量配置，从而导致管理上的困难。

Switchboard 的配置变更是存储在 DynamoDB 中的。服务网格上的 Envoy 代理通过一个双向的 gRPC 流连接至 xDS 控制平面。当某个服务的 Envoy 配置生成时，控制平面会发送更新后的配置给一小部分 Envoy 代理，并且在测定它们的健康状况之后，才将变更提交至整个网格。

与此同时，服务的所有者可以直接通过 Switchboard 供应和管理 Kubernetes 集群，还可以通过金丝雀发布、健康检查端点和分区滚动更新生成 spinnaker 管道。

为了将暴露给互联网的服务数量降至最低，Snap 为其微服务设计了一个共享的、内部的、分区的网络。将会有一个 API 网关暴露到互联网上，这样的话，没有外部流量可以直接与内部网络进行通信。

这个 API 网关上运行的 Envoy 镜像和微服务上运行的 Envoy 镜像是一样的，连接到相同的控制面板。除此之外，还有自定义的 Envoy 过滤器，用来处理 Snapchat 的认证模式以及限速和负载 shedding 功能。

统一的 Snap 服务网格架构图如下所示：

Snap 的服务网格目前运行在 AWS 和 Google Cloud 的七个可用区上，网格上有 300 多个生产环境的服务。

原文链接：

Monolith to Microservices: Migrating Snap’s Architecture Using a Service Mesh