计算机

Istio流量管理之流量转移

在日常的持续部署中,我们一般使用滚动升级的方式来进行微服务升级。若使用Kubernetes容器编排平台进行微服务滚动升级,其一般通过控制实例数的方式来实现。将旧版本下线,将新版本启动,新实例健康检查通过后,统一将流量打到新版本。 而使用Istio,不用控制实例数,且可以更细粒度的控制流量打到各个版本的百分比,从而实现按比例将流量逐渐迁移到新版本来实现升级。 下面使用Bookinfo样例看一下Istio的流量转移如何使用。我们知道reviews有三个版本,假定我们想从v1版本升级到v3版本。(关于Istio的安装及Bookinfo样例的部署,请参看上文“Istio安装使用”) 首先,配置默认的Destination Rule。

阅读更多

Istio流量管理之故障注入

在微服务架构中,若一个服务不可用,会不会导致调用其API的上游服务也不可用,上游服务有没有针对该种情形做容错处理,这对应用的整体可用性来说是很关键的。Istio可以在对微服务无侵入的情况下来模拟其发生故障,以帮助我们测试应用整体的容错能力。 Istio主要使用Virtual Service提供两种故障注入能力:响应延迟与服务中止。 响应延迟 用来模拟被调用服务在高负载情况下造成响应延迟。

阅读更多

Istio流量管理之请求路由

在上文“Istio安装使用”中,我们对Istio进行了安装,并对Bookinfo样例进行了部署测试。本文接着上文,对Istio流量管理中的请求路由进行概念学习及样例测试。 我们知道,Istio通过Envoy数据面拦截了所有服务实例的进出流量。这样基于Istio服务网格即可以实现诸多常规方式难以实现的流量管理策略,诸如灰度发布,A/B测试,按比率分流等。 Istio主要提供两个通过YAML配置的自定义资源来实现流量管理:Virtual Service及Destination Rule。这样即做到流量管理与上游请求服务及下游被请求服务解耦。Virtual Service主要用来配置流量如何流动(即定义符合哪些规则的流量打到哪些服务子集上),而Destination Rule则主要用来定义具体的服务子集。

阅读更多

API Gateway与Service Mesh有什么不同?

一般的认为是:API Gateway用来处理南北向流量,Service Mesh用来处理东西向流量。这样的区分方式并不准确。下面会递进式分析两者的使用场景及异同点,以期通过本文可以明白何时使用API Gateway,何时使用Service Mesh?

阅读更多

为什么Istio重回单体架构?

随着应用规模的不断扩大,单体架构已不能承载企业越来越多的业务需求,微服务架构随之兴起。微服务给我们带来诸多益处的同时也带来诸多挑战,其根源即是复杂性的提升。为了解决微服务带来的诸多问题,其中便催生了服务网格的流行。但2020年初,业内最知名的服务网格实现Istio却反其道而行之,由微服务架构重回单体架构,其原因是什么呢?可能是一个契机,让我们重新审思微服务架构带来的好处及问题。 1 微服务架构有什么优势? 将一个复杂的单体应用切分为按领域细分的微服务后,可以让团队聚焦所关注的领域,做到相互独立,彼此不受影响。其带来的优势主要有: 彼此独立交付,快速迭代 各自解耦的微服务,可以让彼此间有明确的边界,各自可以采用不同的语言或技术栈,基于轻量协议(HTTP,RPC等)进行交互。每个微服务可以拥有自己的生命周期,无须相互协调或等待,做到彼此独立交付,相互不受影响。因粒度小,迭代快,从总体看,可以做到并行开发,流水线式产出。

阅读更多