经过两年的架构演进，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

创作场景

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