标签归档:架构

Spring Cloud 与 Service Mesh,如何选择?

导读

Spring Cloud 基于Spring Boot开发,提供一套完整的微服务解决方案,具体包括服务注册与发现,配置中心,全链路监控,API网关,熔断器,远程调用框架,工具客户端等选项中立的开源组件,并且可以根据需求对部分组件进行扩展和替换。

Service Mesh,这里以Istio(目前Service Mesh具体落地实现的一种,且呼声最高)为例简要说明其功能。 Istio 有助于降低这些部署的复杂性,并减轻开发团队的压力。它是一个完全开源的服务网格,可以透明地分层到现有的分布式应用程序上。它也是一个平台,包括允许它集成到任何日志记录平台、遥测或策略系统的 API。Istio的多样化功能集使你能够成功高效地运行分布式微服务架构,并提供保护、连接和监控微服务的统一方法。

从上面的简单介绍中,Service Mesh 和 Spring Cloud 实现的功能差不多,那这两种架构应该如何选择呢?

Service Mesh 的优势

2019 年,经过前几年的发展,Service Mesh 在国内开始大面积开花结果,互联网大厂纷纷开始走上实践道路(例如蚂蚁金服的SOFASTACK),也有大部分企业已经开始接触Service Mesh。

可以认为 Service Mesh 将是微服务的未来,是可以替换目前的事实标准 Spring Cloud 的存在,其原因,总结下来,有四个方面:

与 Spring Cloud 功能重叠

来简单看一下他们的功能对比:

功能列表 Spring Cloud Isito
服务注册与发现 支持,基于Eureka,consul等组件,提供server,和Client管理 支持,基于XDS接口获取服务信息,并依赖“虚拟服务路由表”实现服务发现
链路监控 支持,基于Zikpin或者Pinpoint或者Skywalking实现 支持,基于sideCar代理模型,记录网络请求信息实现
API网关 支持,基于zuul或者spring-cloud-gateway实现 支持,基于Ingress gateway以及egress实现
熔断器 支持,基于Hystrix实现 支持,基于声明配置文件,最终转化成路由规则实现
服务路由 支持,基于网关层实现路由转发 支持,基于iptables规则实现
安全策略 支持,基于spring-security组件实现,包括认证,鉴权等,支持通信加密 支持,基于RBAC的权限模型,依赖Kubernetes实现,同时支持通信加密
配置中心 支持,springcloud-config组件实现 不支持
性能监控 支持,基于Spring cloud提供的监控组件收集数据,对接第三方的监控数据存储 支持,基于SideCar代理,记录服务调用性能数据,并通过metrics adapter,导入第三方数据监控工具
日志收集 支持,提供client,对接第三方日志系统,例如ELK 支持,基于SideCar代理,记录日志信息,并通过log adapter,导入第三方日志系统
工具客户端集成 支持,提供消息,总线,部署管道,数据处理等多种工具客户端SDK 不支持
分布式事务 支持,支持不同的分布式事务模式:JTA,TCC,SAGA等,并且提供实现的SDK框架 不支持
其他 …… ……

从上面表格中可以看到,如果从功能层面考虑,Spring Cloud与Service Mesh在服务治理场景下,有相当大量的重叠功能,从这个层面而言,为Spring Cloud向Service Mesh迁移提供了一种潜在的可能性。

服务容器化

在行业当前环境下,还有一个趋势,或者说是现状。越来越多的应用走在了通往应用容器化的道路上,或者在未来,容器化会成为应用部署的标准形态。而且无论哪种容器化运行环境,都天然支撑服务注册发现这一基本要求,这就导致Spring Cloud体系应用上容器的过程中,存在一定的功能重叠,有可能为后期的应用运维带来一定的影响,而Service Mesh恰恰需要依赖容器运行环境,同时弥补了容器环境所欠缺的内容(后续会具体分析)。

术业有专攻

从软件设计角度出发,我们一直在追求松耦合的架构,也希望做到领域专攻。例如业务开发人员希望我只要关心业务逻辑即可,不需要关心链路跟踪,熔断,服务注册发现等支撑工具的服务;而平台支撑开发人员,则希望我的代码中不要包含任何业务相关的内容。而Service Mesh的出现,让这种情况成为可能。

语言壁垒

目前而言Spring Cloud虽然提供了对众多协议的支持,但是受限于Java技术体系。这就要求应用需要在同一种语言下进行开发(这不一定是坏事儿),在某种情况下,不一定适用于一些工作场景。而从微服务设计考虑,不应该受限于某种语言,各个服务应该能够相互独立,大家需要的是遵循通信规范即可。而Service Mesh恰好可以消除服务间的语言壁垒,同时实现服务治理的能力。

选择和迁移

从上文中我们得知 Service Mesh 的各种优势,那么,如何让 Service Mesh 在我们的项目中落地呢?接下来我们分几种情况讨论下

全新的项目

如果是小型项目,轻业务、重流量、需求快速变化,可以参考我之前写的文章轻量型互联网应用架构方式,语言层面选择 Node.js + Mongodb/Mysql.

如果项目属于业务复杂类型,语言层面可以选择 Java with Kotlin。

当然,全新项目,容器化是必须的。

而且如果你的工期紧张,可以考虑渐进式地推进, 先 k8s 后 Service Mesh。

先把项目服务容器话,在 k8s 上部署起来,此时已经能够享受 k8s 带来的一部分服务治理能力了。例如:

  • 服务发现
  • 负载均衡
  • API 网关
  • 服务路由

Istio 基于 k8s,项目有了 k8s 的基础,落地 Istio 也可以顺水渠成。

Spring Cloud 项目的迁移

现存的 Spring Cloud 项目的迁移方案,可以参考这篇文章 服务迁移之路 | Spring Cloud向Service Mesh转变

简单来说就是先把服务容器化,然后逐步用 Service Mesh 替换 Spring Cloud 的功能。

其他语言项目的迁移

和上面的方案大同小异,前提条件都是先把服务容器话。

参考文章

服务迁移之路 | Spring Cloud向Service Mesh转变

轻量型互联网应用架构方式

轻量型互联网应用架构方式

轻量型 Web 架构模式

前言

说到互联网应用架构,就绕不开微服务,当下(2019)最热门的微服务架构体系应该还是 Spring Cloud 和 Dubbo,阿里也推出了自己的 Spring Cloud 实现 Spring Cloud Alibaba。这类框架围绕微服务体系提供了大而全的功能,包括服务发现、治理、流量监控、配置管理等,让人向往。

但是其缺点也是比较明显:

  • 限定于 Java 体系,其他编程语言无法享受这个体系
  • 侵入应用,几乎每个 Java 应用都挂载一堆 Spring 相关的 jar 包

所以目前社区发展的新方向是:云原生。

其中的翘楚便是 istio,基于 kubernetes 的 sidecar 模式,把 Sprint Cloud 做的大部分工作下沉到基础应用层面,让应用层无感。
有了 Istio 之后,微服务应用实现了大减负,所以我重新思考了对于小型互联网公司来说,当下最适合的架构模式应该是什么

Web 架构模式

适用场景:小型互联网公司,业务多而小,追求开发效率。
解决方案:把重复工作隐藏起来,让应用层轻量快跑

具体有两个方向
基础架构层面:使用 Kubernetes 和 Istio,提供微服务所需要的功能支持
应用层面:针对 Nodejs 后端编程领域,提供一个最佳实额

整体架构图:

基础架构实践

目前还没有足够的时间完成落地实践,只能说一下理论规划。
现在是云时代,所以直接用 Kubernetes 来做应用编排就可以了。
后期可以落地 Istio,就可以保证微服务们稳定运行。

容器编排

Kubernetes

日志收集

  • 在 k8s 集成 elk
  • 输入日志到阿里云 nas

应用观测

Istio 提供 Grafana 请求分析、 Jaeger链路追踪、告警等

流量控制

  • 权限校验
  • 加密
  • 熔断限流

Web 应用架构

在应用层,我最终选择是使用 Node.js 语言来做主要的业务开发。

使用 Koa + 自研框架。

语言的选择,为什么是 Node.js

主要原因是我目前所在团队技术栈在 Node 积累比较多。

其次原因是有了 typescript 之后,使用 node 编写后端应用变得更加可维护了,而且 node 小而快(开发效率快,当然IO密集型的应用运行效率也不差)非常适合微服务场景。

最后,Node 的上手难度真的很低。

当然要使用其他语言也是可以的,如果有着复杂业务逻辑,可以使用 Kotlin + Spring Boot 这组套件,但不包括 Spring Cloud

Kotlin 能完美复用 JVM 生态,也可以避免 Java 语言的一些繁琐的写法,甚至后期还可以用上 Kotlin 的协程,来替代 Java 目前的多线程并发模型。

当然,本文讨论的是 Web 应用架构,如果你的应用是数据处理方面,本文无法提供任何帮助。而在 Web 领域,Python 和 PHP 对比起 Node,其实并没有优势,所以就不考虑了。

Web 框架如何选

Node 的 Web 框架还挺多的,我比较熟悉的有:

  • Sails.js 大而全,甚至有自己的 orm, node 世界的 ruby on rails
  • Express 基础 web 框架
  • Koa 更基础的 web 框架,甚至两 body-parse 都不自带
  • Thinkjs Thinkphp 吧
  • Egg 阿里出品,挺受欢迎的
  • NestJS node 世界的 Spring MVC

我公司早期使用 sails,看中其集成的丰富功能,但是后期 sails 的成长速度跟不上社区,对一些新特性 Generator 等不能及时兼容,而且太笨重了。

所以团队在 17 年左右转型选择了 Koa,然后自己组装实践各个基础功能,这个做法的好处是高度自定义,非常契合公司发展需要。

社区优秀的框架们

在 17 年之后,相继涌现一些优秀框架,像 egg 和 nestjs,当时我们并没有采用他们。

Egg 本身是优秀的框架,但是它是为中台打造的,但我公司需要用 Node 完成本来是 Java 做的事情,我们会用 Node 做比较重的业务,Egg 在这方便并不适合,例如没有模块划分的概念。

比起 Egg ,NestJS 就更适合我们,当时看它的文档就能感受出来,NestJS 的作者们是真的拿这个框架来做后端业务的,文档里讲到了我们日常碰到的很多痛点:

  • 模块划分
  • 循环引用
  • OpenAPI
  • IOC 依赖注入
  • CRUD

当时感觉像是找到了真爱,但是实践过后,发现一些问题:

  • 编码规范:NestJS 有自己的一套规范,而且它封装得足够多,基本上无法修改这套规范,只能妥协。
  • 集成测试:我们在早期使用 Koa 的过程中,沉淀了一套集成测试方案,特别是对 mongodb,我们做了一些工具可以自动注入和清除测试数据,要在 NestJs 实现这个功能,需要有足够的时间对其改造

基于上面两个原因,NestJS 并没有在团队推广开来。

自研的方向

社区的框架既然不合适,那就博采众长,自己组装一套框架出来,所以我最近捣鼓出了 @akajs, 预期说这个东西是框架,更准确的说法是,Kalengo团队的Node后端开发最近实践集合。就是把后端常用的东西集合打包起来,包含:

  • IOC 依赖注入
  • 注解式路由
  • CRUD 我们很多项目非常简单,重复的 CRUD 工作必须简化
  • Mongoose + Typescript 封装
  • Redis + Redlock 封装
  • 集成测试支持
  • 常用 Util,如日期数字处理等
  • 请求参数校验和全局异常处理

此外还有些最佳实践

  • OpenAPI 文档自动生成
  • Docker 支持
  • UML 设计
  • 模块划分

这些我们则通过项目模板来提供。

有了这套工具,后端可以更加轻量和统一,开发可以短时间内搭建起一个完备的后端服务。

总结

这套架构方式,不论是基础架构层面,还是应用层面,都是通过抽离通用的功能,把服务治理的东西抽出下沉到 Istio,把后端通用的工具和实践抽出放在 @akajs 和项目模板中,以此来简化上层应用。

这样一线的后端开发,可以专注于业务逻辑的实现,不必在为基础设施烦恼。毕竟小公司要生存,“快”是很重要的。

未来已来:云原生 Cloud Native

前言

自 2013 年容器(虚拟)技术(Docker)成熟后,后端的架构方式进入快速迭代的阶段,出现了很多新兴概念:

  • 微服务
  • k8s
  • Serverless
  • IaaS:基础设施服务,Infrastructure-as-a-service
  • PaaS:平台服务,Platform-as-a-service
  • SaaS:软件服务,Software-as-a-service
  • Cloud Native: 云原生
  • Service Mesh

后端架构的变迁和云计算的发展密切相关,架构其实在不断地适应云计算,特别是云原生,被誉为未来架构,在 2019 年,云原生落地方案 Service Mesh 在国内外全面开花,我认为,未来已来。

接下来,我们将:

  • 梳理后端架构演化史,回顾后端架构发展历程;
  • 回顾云服务发展历程,探讨云原生概念;
  • 梳理云原生实现方案 Service Mesh 的发展历程;
  • 介绍 Service Mesh 的代表 Istio 的亮眼功能;

后端架构演化史

集中式架构

集中式架构又叫单体式架构,在Web2.0模式并未大规模兴起时十分流行。后来,基于Web应用的B/S(Browser/Server)架构逐渐取代了基于桌面应用的C/S(Client/Server)架构。B/S架构的后端系统大都采用集中式架构,它当时以优雅的分层设计,统一了服务器后端的开发领域。

集中式应用分为标准的3层架构模型:数据访问层M、服务层V和逻辑控制层C。每个层之间既可以共享领域模型对象,也可以进行更加细致的拆分。

其缺点是

  • 编译时间过长;
  • 回归测试周期过长;
  • 开发效率降低等;
  • 不利于更新技术框架

分布式系统架构

对于互联网应用规模的迅速增长,集中式架构并无法做到无限制的提升系统的吞吐量,而分布式系统架构在理论上为吞吐量的上升提供了无限扩展的可能。因此,用于搭建互联网应用的服务器也渐渐地放弃了昂贵的小型机,转而采用大量的廉价PC服务器。

容器技术新纪元 Docker

分布式架构的概念很早就出现,阻碍其落地的最大问题是容器技术不成熟,应用程序在云平台运行,仍然需要为不同的开发语言安装相应的运行时环境。虽然自动化运维工具可以降低环境搭建的复杂度,但仍然不能从根本上解决环境的问题。

Docker的出现成为了软件开发行业新的分水岭;容器技术的成熟,也标志技术新纪元的开启。Docker让开发工程师可以将他们的应用和依赖封装到一个可移植的容器中。就像当年智能手机的出现改变了整个手机行业的游戏规则一样,Docker也大有席卷整个软件行业,并且进而改变行业游戏规则的趋势。通过集装箱式的封装,开发和运维都以标准化的方式发布的应用,异构语言不再是桎梏团队的枷锁。

在 Docker 之后,微服务得以流行开来

微服务架构

微服务架构风格是一种将一个单一应用程序开发为一组小型服务的方法,每个服务运行在自己的进程中,服务间通信采用轻量级通信机制(通常用HTTP资源API)。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理,服务可用不同的语言开发,使用不同的数据存储技术。

微服务优势

  • 可扩展
  • 可升级
  • 易维护
  • 故障和资源的隔离

微服务的问题

但是,世界上没有完美无缺的事物,微服务也是一样。著名软件大师,被认为是十大软件架构师之一的 Chris Richardson 曾一针见血地指出:“微服务应用是分布式系统,由此会带来固有的复杂性。开发者需要在 RPC 或者消息传递之间选择并完成进程间通讯机制。此外,他们必须写代码来处理消息传递中速度过慢或者不可用等局部失效问题。”

在微服务架构中,一般要处理以下几类问题:

  • 服务治理:弹性伸缩,故障隔离
  • 流量控制:路由,熔断,限速
  • 应用观测:指标度量、链式追踪

解决方案 Spring Cloud(Netflix OSS)

这是一个典型的微服务架构图

Spring Cloud 体系提供了服务发现、负载均衡、失效转移、动态扩容、数据分片、调用链路监控等分布式系统的核心功能,一度成为微服务的最佳实践。

Spring Cloud 的问题

如果开始构建微服务的方法,肯定容易被 Netflix OSS/Java/Spring/SpringCloud 所吸引。但是要知道你不是Netflix,也不需要直接使用 AWS EC2,使得应用程序变得很复杂。如今使用 docker 和采用 memos/kubernetes 是明智之举,它们已经具备大量的分布式系统特性。在应用层进行分层,是因为 netflix 5年前面临的问题,而不得不这样做(可以说如果那时有了kubernetes,netflix OSS栈会大不相同)。

因此,建议谨慎选择,按需选择,避免给应用程序带来不必要的复杂度。

的确 SpringCloud 方案看起来很美好,但是它具有非常强的侵入性,应用代码中会包含大量的 SpringCloud 模块,而且对其他编程语言也不友好。

Kubernetes

Kubernetes 出现就是为了解决 SpringCloud 的问题,不侵入应用层,在容器层解决问题。

Kubernetes 起源

Kubernetes最初源于谷歌内部的Borg,提供了面向应用的容器集群部署和管理系统。

Kubernetes的目标旨在消除编排物理/虚拟计算,网络和存储基础设施的负担,并使应用程序运营商和开发人员完全将重点放在以容器为中心的原语上进行自助运营。

Kubernetes 也提供稳定、兼容的基础(平台),用于构建定制化的 workflows 和更高级的自动化任务。 Kubernetes 具备完善的集群管理能力,包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建负载均衡器、故障发现和自我修复能力、服务滚动升级和在线扩容、可扩展的资源自动调度机制、多粒度的资源配额管理能力

Kubernetes 还提供完善的管理工具,涵盖开发、部署测试、运维监控等各个环节。

Service Mesh

Service Mesh 是对 Kubernetes 的增强,提供了更多的能力。

2018年9月1日,Bilgin Ibryam 在 InfoQ 发表了一篇文章 Microservices in a Post-Kubernetes Era,中文版见后 Kubernetes 时代的微服务(译文有些错误,仅供参考)。

文中作者的观点是:在后 Kubernetes 时代,服务网格(Service Mesh)技术已完全取代了使用软件库实现网络运维(例如 Hystrix 断路器)的方式。

如果说 Kubernetes 对 Spring Cloud 开了第一枪,那么 Service Mesh 就是 Spring Cloud 的终结者。

总结

最后我们用一个流程图来描述后端架构的发展历程

每个关键节点的大概时间表

架构/技术 时间/年份
集中式架构 ~
分布式架构 ~
Docker 2013
微服务 2014
Spring Cloud 2014
Kubernetes 成熟 2017
Service Mesh 2017

可以看出,微服务生态这里,Spring Cloud 为代表的这条路已经后继无人了,未来属于 Service Mesh 。
Service Mesh 经过2年的发展,目前 Service Mesh 已经足够成熟,已经有生产落地的案例,我们接下来就看看 Service Mesh,在此之前,我们要先理解一个概念,云原生。

云原生 Cloud Native

如何理解“云原生”?之所以将这个话题放在前面,是因为,这是对云原生概念的最基本的理解,而这会直接影响到后续的所有认知。

注意:以下云原生的内容将全部引用敖小剑的 畅谈云原生(上):云原生应用应该是什么样子? 这篇文章,图画得太好了。

云原生的定义一直在发展,每个人对云原生的理解都可能不同,就如莎士比亚所说:一千个人眼中有一千个哈姆雷特。

2018 年 CNCF (Cloud Native Computing Foundation)更新了云原生的定义。

这是新定义中描述的代表技术,其中容器和微服务两项在不同时期的不同定义中都有出现,而服务网格这个在 2017 年才开始被社区接纳的新热点技术被非常醒目的列出来,和微服务并列,而不是我们通常认为的服务网格只是微服务在实施时的一种新的方式。

那我们该如何理解云原生呢?我们尝试一下,将 Cloud Native 这个词汇拆开来理解,先看看什么是 Cloud。

什么是云 Cloud

快速回顾一下云计算的历史,来帮助我们对云有个更感性的认识。

云计算的出现和虚拟化技术的发展和成熟密切相关,2000 年前后 x86 的虚拟机技术成熟后,云计算逐渐发展起来。

基于虚拟机技术,陆续出现了 IaaS/PaaS/FaaS 等形态,以及他们的开源版本。

2013 年 docker 出现,容器技术成熟,然后围绕容器编排一场大战,最后在 2017 年底,kubernetes 胜出。2015 年 CNCF 成立,并在近年形成了 cloud native 生态。

在这个过程中,云的形态一直变化,可以看到:供应商提供的功能越来越多,而客户或者说应用需要自己管理的功能越来越少。


架构也在一直适应云计算的变化

什么是原生 Native

在回顾完云计算的历史之后,我们对 Cloud 有更深的认识,接着继续看一下:什么是 Native?
字典的解释是:与生俱来的。
那 Cloud 和 native 和在一起,又该如何理解?

这里我们抛出一个我们自己的理解:云原生代表着原生为云设计。详细的解释是:应用原生被设计为在云上以最佳方式运行,充分发挥云的优势。

这个理解有点空泛,但是考虑到云原生的定义和特征在这些年间不停的变化,以及完全可以预料到的在未来的必然变化,我觉得,对云原生的理解似乎也只能回到云原生的出发点,而不是如何具体实现。

Cloud Native 是道,Service Mesh 是术

那在这么一个云原生理解的背景下,我再来介绍一下我对云原生应用的设想,也就是我觉得云原生应用应该是什么样子。

在云原生之前,底层平台负责向上提供基本运行资源。而应用需要满足业务需求和非业务需求,为了更好的代码复用,通用型好的非业务需求的实现往往会以类库和开发框架的方式提供,另外在 SOA/ 微服务时代部分功能会以后端服务的方式存在,这样在应用中就被简化为对其客户端的调用代码。

然后应用将这些功能,连同自身的业务实现代码,一起打包。

而云的出现,可以在提供各种资源之外,还提供各种能力,从而帮助应用,使得应用可以专注于业务需求的实现。
非业务需求相关的功能都被移到云,或者说基础设施中去了,以及下沉到基础设施的中间件。

以服务间通讯为例:需要实现上面列举的各种功能。

SDK 的思路:在应用层添加一个胖客户端,在这个客户端中实现各种功能。

Service Mesh 的思路,体现在将 SDK 客户端的功能剥离出来,放到 Sidecar 中。就是把更多的事情下沉,下沉到基础设施中。

在用户看来,应用长这样:

云原生是我们的目标,Service Mesh 交出了自己的答卷,接下来我们可以回到 Service Mesh 这里了。

Service Mesh

其中文译名是服务网格,这个词最早使用由开发Linkerd的Buoyant公司提出,并在内部使用。

定义

服务网格的基本构成

纷争 2017

2017 年年底,当非侵入式的 Service Mesh 技术终于从萌芽到走向了成熟,当 Istio/Conduit 横空出世,人们才惊觉:微服务并非只有侵入式一种玩法,更不是 Spring Cloud 的独角戏!

解读 2017 之 Service Mesh:群雄逐鹿烽烟起

文章总结一下:
创业公司 Buoyant 的产品 Linkerd 开局拿下一血;
Envoy 默默耕耘;
从 Google 和 IBM 联手推出 Istio,Linkerd 急转直下;
2017 年底 Buoyant 推出 Conduit 背水一战;
Nginmesh 与 Kong 低调参与;

百家争鸣 2018

2018 年,Service Mesh 又多了哪些内容呢?在 2018 年,Service Mesh 在国内大热,有多家公司推出自己的 Service Mesh 产品和方案,Service Mesh 更加热闹了。
详细见这篇文章 下一代微服务!Service Mesh 2018 年度总结

文章总结一下:
Service Mesh 在国内大热,有多家公司加入战场;
Istio 发布1.0,成为最受欢迎的 Service Mesh 项目,获得多方支持;
Envoy 继续稳扎稳打,Envoy 被 Istio 直接采用为数据平面,有望成为数据平面标准;
Linkerd1.x 陷入困境,Conduit 小步快跑,但响应平平,Buoyant 公司决定合并产品线,Linkerd1.x + Conduit = Linkerd2.0;
更多的公司参与 Service Mesh,国外有 Nginx、Consul、Kong、AWS等,国内有蚂蚁金服、新浪微博、华为,阿里 Dubbo,腾讯等;

持续发展 2019

2019 将会听到更多 Service Mesh 的声音,请关注Service Mesh 中文社区

Istio

前文讲到 Istio 是当前最受欢迎的 Service Mesh 框架,一句话定义 Istio:一个用来连接、管理和保护微服务的开放平台。
它能给我们的微服务提供哪些功能呢?

连接

  • 动态路由
  • 超时重试
  • 熔断
  • 故障注入

详细见官网介绍

保护

安全问题一开始就要做好,在 Istio 实现安全通讯是非常方便的。

Istio 支持双向 TLS 加密

见官方文档

控制

速率限制
黑白名单

见官方文档

观测

  • 指标度量:每秒请求数,Prometheus 与 Grafana
    使用 Grafana 观测流量情况

  • 分布式追踪:Jaeger 或 Zipkin
    快速观测调用链路

  • 日志:非应用日志

  • 网格可视化
    快速理清服务的关系

总结

虚拟化技术推动这云计算技术的变革,顺带也影响了后端架构的演进,目前我们身处云时代,将会有更多的元原生应用出现,Istio 作为其中的佼佼者,值得你投入一份精力了解一下。

学习资料/指引

Service Mesh 中文社区 上面提供了丰富的学习资料。

搭建 Kubernetes 集群会比较麻烦,推荐几种方式。主要原因是很多镜像需要翻墙才能下载。

  1. Docker Desktop 自带的 Kubernetes 集群
  2. 使用 Rancher2.0 搭建 Kubernetes 集群
  3. 在 Google Cloud 上直接开集群,可以领 300 美金的体验金,需要翻墙

不推荐 MiniKube,翻墙和代理问题非常难搞。
再附上 Docker 设置代理的方式

在线体验 Istio

参考资料

kubernetes-handbook

istio-handbook

微服务学习笔记

畅谈云原生(上):云原生应用应该是什么样子?

Service Mesh:下一代微服务?

从架构到组件,深挖istio如何连接、管理和保护微服务2.0?