微网关与服务啮合

标签: 微服务 微服务 ServiceMesh 转载 | 发表时间:2018-03-11 14:11 | 作者:
出处:http://blog.didispace.com/

技术雷达:现在越来越多的大型组织在向更加自组织的团队结构转型,这些团队拥有并运营自己的微服务,但他们如何在不依赖集中式托管的基础架构下,确保服务之间必要的一致性与兼容性呢?为了确保服务之间的有效协作,即使是自组织的微服务也需要与一些组织标准对齐。服务啮合(SERVICE MESH)在服务发现、安全、跟踪、监控与故障处理方面提供了一致性,且不需要像API网关或ESB这样的共享资产。服务啮合的一个典型实现包含轻量级反向代理进程,这些进程可能伴随每个服务进程一起被部署在单独的容器中。反向代理会和服务注册表、身份提供者和日志聚合器等进行通信。通过该代理的共享实现(而非共享的运行时实例),我们可以获得服务的互操作性和可观测性。一段时间以来,我们一直主张去中心化的微服务管理方法,也很高兴看到服务啮合这种一致性模式的出现。随着linkerd和Istio等开源项目的成熟,服务啮合的实现将更加容易。

新瓶旧酒还是厚积薄发?

对于持续关注云服务架构设计最新发展趋势的同学来说,刚过去的2017年,最火的词莫过于 CNCF了,这是一个专注于“云原生”(Cloud Native)的基金会,由众多战斗在云服务一线的公司(包括了谷歌、AWS、阿里云等等)组建而来,旨在推进云原生的架构标准化与最佳实践的普及。

而在最近一期的 技术雷达中,“云原生”(Cloud Native)和 “微服务”(Microservices)也引出了许多相关的技术,随着 Kubernetes、Docker 等一众容器管理工具的普及,我们也看到在容器的内部,微服务的架构设计也发生着一些变化,其中“服务啮合”(Service Mesh)就成为了大家关注的热点。

那么这些变化到底是新瓶旧酒,还是厚积薄发?我们不妨先从一个更耳熟能详的架构——“网关”(Gateway)谈起。

网关(Gateway)的作用

作为微服务工具链中的元老,“网关”(Gateway) 的引入为微服务API提供统一的入口和平台,不同的服务可以得到一致的管理。使用网关的架构可以减少企业大量的重复开发。甚至有一些通用的逻辑也可以使用网关来承载(如Zuul、Enovy、OpenResty等)。

不论初心为何,这些网关们随着时光流转,功能也变得越来越丰富,网关可以负责解决不同服务的服务注册发现、负载均衡、配额流控、监控日志、缓存加速、配置分离、安全管控、跟踪审计等问题。这一系列的功能,我们可以大致分为两类:“数据面”和“控制面”。

数据面(Data Plane)负责在 数据包粒度上进行筛选和处理

  • 路由转发
  • 负载均衡
  • 安全通信
  • 缓存加速
  • 认证鉴权
  • 日志审计
  • 健康检查
  • 熔断限流

控制面(Control Plane)负责在 服务粒度上进行统筹和管理

  • 注册发现
  • 配置管控
  • 弹性伸缩
  • 统筹遥测
  • 容错自愈
  • 策略执行
  • 证书签发

这一系列的功能,就是网关面临的问题域。在了解问题域之后,让我们回归本篇的主题:继承了“网关”(Gateway)衣钵的“微网关”(MicroGateway)和“服务啮合”(Service Mesh),它们到底是什么?

什么是微网关?

随着微服务的普及,传统的中心化网关变得越来越厚重,由于与中心化节点通信,带来了大量网络、IO开销以及单点问题,往往无法满足我们对于实时性、高可用的要求。另外越来越多的自治化需求,与原有集权式微服务治理方法之间,也产生出许多冲突矛盾。因此,与微服务化相适应的,可以 本地化、分布式部署的微网关(MicroGateway)也逐渐涌现出来。

什么是服务啮合?

服务啮合(Service Mesh)是一种为了保证“服务到服务”的安全、快速和可靠的通信而产生的基础架构层, 区别于应用层、通信层的一种新的云原生上下文内的抽象层。如果你正在构建云原生的应用程序,在微服务拓扑结构日益复杂的今天,服务啮合层的提出,可以帮助开发者将服务的交互通信问题与微服务内部的业务问题隔离开来,专注于各自的领域。

演进中的微网关与服务啮合

当我们了解到微网关与服务啮合的作用之后,就可以一起来看一下微网关与服务啮合架构是如何一步步设计出来的。

低侵入性组件(Low-Invasive Component)

最初的服务间互访,常常由于业务尚不清晰,给标准化带来了障碍。因此我们常常见到一些由领域专家提供的低侵入性的组件,为服务的开发者提供抽象的规范,使其能轻松获得定制化能力。

img

组件可以更好地规范问题,并且尽可能地将组件封装为简单的接口,早期的服务发现常常通过该类方式实现,例如 Eureka 套件通过引入 Client 来获得完整的如报告、监控、熔断等能力。

我们在一些 IAM (Identity Access Management)的服务设计中采用了这种模式,为各个业务服务提供了一致的认证鉴权接口, 由领域专家驱动,设计规范化的调用模式。由于该类组件尽可能设计为低侵入性的接口,因此微服务团队也可以更加便利地根据不同场景取舍是否使用该组件提供的功能,例如通过配置文件加 feature toogle 简单地在开发环境中关闭认证鉴权的功能,以加快开发进程。

反向代理(Reverse Proxy)

随着服务成熟度的提高,我们可以发现一些常见的非业务强相关的逻辑,可以从原有的服务中剥离出来,通过反向代理统一进行过滤处理。

img

反向代理,可以为微服务处理请求的前后环节增添通用逻辑,例如 apigee 提供的 API proxy 封装,通过反向代理模式为原有的服务添加 PreFlow、PostFlow, 解决请求生命周期前后常见的问题,例如检查配额和记录调用频度,对 CORS 等 Http Header 的添加和消费,这些功能有些类似于传统的 Filter 模型,但是却可以独立部署。

反向代理可以提供更高的可用性,并帮助微服务开发者从这些常见细节中解脱出来。

侧车模式(Sidecar Pattern)

准确来说,侧车模式(Sidecar Pattern)本身并非微网关或者服务啮合技术独有,它只是一种特定的软件模块共生关系。侧车模式可以是一个反向代理,也可以作为一个服务存在。

img

作为反向代理使用的Sidecar进程可以过滤请求与返回内容,实现如安全通信、认证鉴权、服务端/客户端负载均衡、自动路由等功能。

img

作为服务使用的Sidecar进程可以为主服务提供额外能力,实现分布式缓存同步、配置文件拉取、日志搜集等功能。

侧车模式常见于分布式缓存和安全基础设施网关,通过与微服务进程共同启停的服务或容器,可以更方便地与微服务一并调度,享受微服务管理平台本身提供的服务发现、注册、配置、扩容能力。 通过共享生命周期,在简单部署和灵活应用中寻找一个平衡

我们在微服务框架 Jhipster 提供的基础能力中,可以直接通过注解使用 Hazelcast 的分布式缓存,正是通过 Sidecar 模式实现的,拥有共生的分布式缓存实例后,可轻松实现服务接口的缓存,而分布式缓存自身的同步策略等问题都被封装在 Sidecar 进程中,无需开发者花费大量时间重新开发和调试。Sidecar也可以用于实现例如OAuth等安全相关的守护服务,帮助微服务处理业务界限外的专项问题。

原生的基础设施(Native Infrastructure)

服务啮合带来的最大的不同就是原生无感知,通过侧车模式部署的反向代理,与一些容器系统级的配置结合,更彻底地解决微服务在数据面与管理面的能力一致性问题。

服务啮合框架 Istio 提供了 Istio-Initializer 和 istioctl 工具,你可以在Kubernetes的容器整备过程中,注入所需的配置和 Envoy 容器, 将Sidecar Proxy、Sidecar Service注册为容器集群中的原生服务,可以在享受弹性部署的同时,享受数据面和控制面协同提供的标准化能力。无痛地加入Istio提供的功能,如 iptables 代理转发、双向TLS认证、限流策略、日志收集等等。

img

图片来自:http://t.cn/RETWzGV

我们在设计服务啮合层时也可以考虑使用更原生的服务组织与部署策略,例如将微服务容器注册为系统服务、通过控制流对容器进行编排、尽可能与微服务共享生命周期和运行环境来提高可用性与性能等等。

从现在开始,拥抱微服务的云原生生态

既是新瓶旧酒,又是厚积薄发,云原生趋势下的微服务也在不断的演进,逐渐变成我们最初希望的“会呼吸”的模样。我们建议您考虑在一些适用的场景,尤其是微服务化的架构设计中,考虑使用微网关与服务啮合,并总结最佳实践与我们交流。

让我们一起期待云原生生态下的微服务,为数字化时代提供更多的想象力。

相关 [网关 服务] 推荐:

http api服务网关

- - 互联网 - ITeye博客
http服务网关系统是一个对http服务进行治理的系统,通过该系统可以对调用方进行身份认证、服务授权许可(许可调用方使用某个http服务)、服务鉴权(是否能调用http服务)、请求流控、失败恢复、调用度量数据统计分析、服务依赖视图等. 整个系统架构如下图,分为三大部分:api网关、网关控制台、度量数据采集分析(这个未在图中体现).

微网关与服务啮合

- - 程序猿DD
技术雷达:现在越来越多的大型组织在向更加自组织的团队结构转型,这些团队拥有并运营自己的微服务,但他们如何在不依赖集中式托管的基础架构下,确保服务之间必要的一致性与兼容性呢. 为了确保服务之间的有效协作,即使是自组织的微服务也需要与一些组织标准对齐. 服务啮合(SERVICE MESH)在服务发现、安全、跟踪、监控与故障处理方面提供了一致性,且不需要像API网关或ESB这样的共享资产.

怎么用API网关构建微服务|架构

- - 企业架构 - ITeye博客
转于http://www.tuicool.com/articles/bMnEbmv. 当选择将应用程序构建为一组微服务时,需要确定应用程序客户端如何与微服务交互. 在单体应用程序中,只有一组(通常是重复的、负载均衡的)端点. 然而,在微服务架构中,每个微服务都会暴露一组通常是细粒度的端点. 在本文中,我们将讨论一下这对客户端与应用程序之间的通信有什么影响,并提出一种使用API网关的方法.

spring-cloud服务网关中的Timeout设置

- - ImportNew
大家在初次使用spring-cloud的gateway的时候,肯定会被里面各种的Timeout搞得晕头转向. hytrix有设置,ribbon也有. 我们一开始也是乱设一桶,Github上各种项目里也没几个设置正确的. 对Timeout的研究源于一次log中的warning. The Hystrix timeout of 60000 ms for the command “foo” is set lower than the combination of the Ribbon read and connect timeout, 200000ms..

XMPP——xmpp客户端、服务器、网关以及地址和消息格式详解

- - CSDN博客推荐文章
接着上一篇文章继续学习和总结. XMPP 系统的一个设计标准是必须支持简单的客户端. 事实上,XMPP 系统架构对客户端只有很少的几个限制. 一个XMPP 客户端必须支持的功能有:. 通过 TCP 套接字与XMPP 服务器进行通信;. 解析组织好的 XML 信息包;. 至于对客户端为何要求如此简单,概括来说就是,xmpp把相关更多功能实现都放在了服务器端去实现和处理,这样使得客户端相对解放出来.

来自京东、宅急送对微服务编排、API网关、持续集成的实践分享(下)

- - 企业架构 - ITeye博客
架构师小组交流会:每期选一个时下最热门的技术话题进行实践经验分享. 微服务架构以其高度的弹性、灵活性和效率的巨大提升,快速受到各领域架构师和技术决策者的关注. 它的基本理念是将一个肥大的系统拆分成若干小的服务组件,组件之间的通讯采用轻量的协议完成. 我们本期小组交流会来探讨一下,现在互联网公司的微服务实践情况.

来自京东、唯品会对微服务编排、API网关、持续集成的实践分享(上)

- - 企业架构 - ITeye博客
架构师小组交流会:每期选一个时下最热门的技术话题进行实践经验分享. 微服务架构以其高度的弹性、灵活性和效率的巨大提升,快速受到各领域架构师和技术决策者的关注. 它的基本理念是将一个肥大的系统拆分成若干小的服务组件,组件之间的通讯采用轻量的协议完成. 我们本期小组交流会来探讨一下,现在互联网公司的微服务实践情况.

京东京麦:微服务架构下的高可用网关与容错实践(有彩蛋)

- -
本文根据DBAplus社群第130期线上分享整理而成,. 从事京麦平台的架构设计与开发工作. 熟悉各种开源软件架构,在Web开发,架构优化上有较丰富的实战经历. 有多年在NIO领域的设计、开发经验,对HTTP、TCP长连接技术有深入研究与领悟,目前主要致力于移动与PC平台网关技术的优化与实现. 个人公众号:程序架道(xindongbook17).

服务禁语

- tiancaicai - 白板报
前几天在一个公交汽车站拍到了一张规定,里面规定了服务禁语和礼貌用语,看了大乐. 3、乘车高峰车厢内拥挤时,禁语:“快往里走,站在前面又没有钞票检. ”文明语:“请尽量往里走,照顾没有上车的乘客”. 4、车子抛锚,禁语:“车子抛锚没有办法,人都要生毛病的,车子坏了也正常. ”文明语:“对不起,车子出现故障修一下,请大家理解.

服务熔断

- - CSDN博客推荐文章
服务熔断也称服务隔离,来自于Michael Nygard 的《Release It》中的CircuitBreaker应用模式,Martin Fowler在博文 CircuitBreaker中对此设计进行了比较详细说明. 本文认为服务熔断是服务降级的措施. 服务熔断对服务提供了proxy,防止服务不可能时,出现串联故障(cascading failure),导致雪崩效应.