从单体到微服务:运用服务网格搬迁 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 的架构

Snap 的服务网格现在运转在 AWS 和 Google Cloud 的七个可用区上,网格上有 300 多个出产环境的服务。

【云栖号在线讲堂】每天都有产品技能专家共享!
课程地址:https://yqh.aliyun.com/zhibo

当即参加社群,与专家面对面,及时了解课程最新动态!
【云栖号在线讲堂 社群】https://c.tb.cn/F3.Z8gvnK

原文发布时刻:2020-05-07
本文作者:A Kulkrani
本文来自:“InfoQ”,了解相关信息能够重视“InfoQ”