容器、服务网格和API网关:从边缘开始

2019-04-18 浏览量:143

Docker 和 Kubernetes 为代表的容器技术炙手可热,熟知这一技术领域的用户,一定都知道下一个热点:Service Mesh,它承诺将微服务之间的内部网络通信均一化,并解决一系列监控、故障隔离等通用非功能性需求。底层的代理服务器技术是 Service Mesh 的立身之本,这种技术在 Service Mesh 之外,还能以 API 网关的形式在边缘为业务系统提供一系列的增强。

虽说 Service Mesh 的爆发之势让人误以为罗马是一日建成的,事实上,在这一热点浮出水面之前,包括 VerizoneBday以及 Facebook 在内的很多组织已经在应用后来被我们称之为 Service Mesh 的技术了。这些早期应用 Service Mesh 的组织之一就是 Lyft,这是一家年收入超过十亿美元的美国网约车巨头。Lyft 还是开源软件 Envoy Proxy 的诞生地,Envoy 在 Service Mesh 世界中举足轻重,Kubernetes 原生的 Istio 控制面 和 Ambassador API 网关 也都建筑在 Lyft 的基础之上。

SOA 网络的烦恼

Matt Klein 是 Envoy Proxy 的作者之一,他去年的一次谈话中说到,SOA(面向服务的架构)和微服务网络是“混乱的庞然大物”。身处其中的每个应用都输出了不同的统计和日志,整个服务堆栈如何处理请求生成响应的过程也是无法跟踪的,在这样的情况下进行 Debug 的巨大难度也就可以想象了。同时对类似负载均衡器、缓存以及网络拓扑这样的基础设施组件的监控能力也是很有限的。

他觉得:“这很痛苦,我认为多数公司都赞同 SOA(微服务)是个可见趋势,在这一趋势的践行过程中会收获很多,但是其中也满是痛苦。主要的痛苦来源就是 Debug”。

对于大规模组织来说,分布式 Web 应用的可靠性和高可用支持是一个核心挑战。这种挑战的应对方式中,普遍包含包含重试、超时、频率控制和熔断等功能逻辑的各种实现。很多系统,不论开源与否,都会使用锁定特定语言(甚至锁定框架)的形式来实现这种方案,这就意味着开发人员也同时被进行锁定。Klein 和他在 Lyft 的团队认为,一定有更好的办法。最终 Envoy 项目诞生了。

外部干预:边缘代理的优势

2016 年 9 月 以开源形式发布了 Envoy Proxy,Klein 和 Lyft 工程师团队一夕成名,但这并非一蹴而就,Lyft 架构从最初的混合 SOA 架构起步,花费了四年,突破层层险阻升级为服务网格治理之下的微服务体系。2017 年的微服务实践者虚拟峰会上,Klein 讲述了向服务网格进行技术迁移的过程中面对基本需求和相关挑战,及其商业价值。

Klein 的第一次艰苦取胜是“从边缘代理开始”的。微服务为基础的 Web 应用需要在边缘提供反向代理,一方面可以防止暴露内部业务服务接口(会违反松耦合原则),另一方面,暴露大量服务也意味着大量的独立 URI 以及 RPC 端点,这会消耗大量的运维资源。现存的云所提供的边缘代理服务器或者网关都不很好,不同产品呈现给工程师的是不同的、易混淆的工作界面。Klein 倡议在边缘实现一个现代化的代理服务,在其中提供改进的监控、负载均衡以及动态路由能力,以此来产生商业价值。工程师团队理解和掌握了边缘代理的运维之后,就可以向内部团队进行推广,最终形成内部的服务网格了。

边缘进化:从代理到 API 网关

AppDirect 是一个端到端提供云端产品和服务管理的商业平台,预计年收入 5000 万美元。在 AppDirect 最近的博客 Evolution of the AppDirect Kubernetes Network Infrastructure 中,他们着重介绍了和 Lyft 类似的经历。云技术和 Kubernetes 之类的编排平台带来的不只是有规模、弹性之类的好处,还因为与生俱来的易变和动态特性,提出了新的挑战:微服务构建的商业功能如何合适的在公共端点上提供服务?

AppDirect 工程师团队采用了一种可靠的方法来应对挑战,首先把配置的核心部分(例如暴露的服务端口)静态化,然后在每个应用之前部署负载均衡器。接下来的迭代就是使用 HashiCorp 的分布式键值库 Consul 结合支持热重载的 HAProxy 反向代理来提供更好的动态管理能力。团队的终极目标是用更丰富功能的 API 网关来提供更丰富的功能。

文中说到:“API 网关的目标是在不变更已公开 API 的访问性的情况下(这种不经变更的可访问性也包含了旧有的 URL 以及友商的定制域名等),通过注入和替换的方式逐个实现转换过程。”

在对一系列的开源和商业产品进行评估之后,AppDirect 团队选择了构建在 Envoy proxy 之上的 Kubernetes 原生的 Ambassador API 网关产品:

“构建于我们了解和喜爱的 Kubernetes API 之上的 Ambassador,是一个轻量、稳定以及没有外部数据库依赖的产品。Ambassador 很独特,使用 Kubernetes 对象标注功能来定义路由配置(也就是以此实现 Envoy 数据面的控制平面)”——团队博客如是说。

虽然 AppDirect 还没有完全实现内部通信的网格化,但是已经感受到了 Envoy Proxy 这样的技术所带来的好处,更学到了在产品中应用这些技术的能力。

星火燎原

服务网格技术的实现和迁移过程才刚刚开始,但是已经可以肯定,这一技术弥合了 Kubernetes 这样的现代容器化平台中应用之间的鸿沟。服务网格带来的,包括频率控制、断路器以及监控性等在内的所有好处,都可以从服务边缘开始享用。如果想要对这一技术进行进一步的探索和学习,在系统边缘开始,农村包围城市是一种行之有效的策略。这种策略无需全面部署,就能迅速的在监控、弹性等方面展示出特有的商业价值。

 

本文转载自:http://www.servicemesher.com/blog/containers-service-mesh-and-api-gateways-it-starts-at-the-edge/

上一篇:数据治理怎么做?这篇万字长文终于讲清楚了!

下一篇:谈谈微服务中的 API 网关(API Gateway)

为什么选择龙石数据?