用户您好!请先登录!

分类目录云原生应用

Service Mesh中Envoy的那点事

提到Envoy就不得不提Service Mesh,说到Service Mesh就一定要谈及微服务了,那么我们就先放下Envoy,简单了解下微服务、Service Mesh以及Envoy在Service Mesh中处于一个什么样的角色。

过去几年间,架构领域最火的方向非微服务莫属,那么微服务架构到底为我们带来了什么样的好处呢?下面通过一张图说明架构的演进,如下:

伴随着业务规模的变大,微服务的好处显而易见,例如它本身所具备的可扩展性、易维护性、故障和资源隔离性等诸多特性使得产品的生产研发效率大大提高,同时,基于微服务架构设计,研发人员可以构建出原生对于“云”具备超高友好度的系统,让产品的持续集成与发布变得更为便捷。

阅读更多

Envoy源码分析:Dispatcher

Dispatcher

在Envoy的代码中Dispatcher是随处可见的,可以说在Envoy中有着举足轻重的地位,一个Dispatcher就是一个EventLoop,其承担了任务队列、网络事件处理、定时器、信号处理等核心功能。在Envoy threading model这篇文章所提到的EventLoop(Each worker thread runs a “non-blocking” event loop)指的就是这个Dispatcher对象。这个部分的代码相对较独立,和其他模块耦合也比较少,但重要性却不言而喻。下面是与Dispatcher相关的类图,在接下来会对其中的关键概念进行介绍。

Envoy源码分析之Dispatcher

阅读更多

云原生架构设计原则

云原生(Cloud Native)的概念,由来自Pivotal的MattStine于2013年首次提出,被一直延续使用至今。这个概念是Matt Stine根据其多年的架构和咨询经验总结出来的一个思想集合,并得到了社区的不断完善,内容非常多,包括DevOps、持续交付(Continuous Delivery)、微服务(MicroServices)、敏捷基础设施(Agile Infrastructure)和12要素(TheTwelve-Factor App)等几大主题,不但包括根据业务能力对公司进行文化、组织架构的重组与建设,也包括方法论与原则,还有具体的操作工具。采用基于云原生的技术和管理方法,可以更好地把业务生于“云”或迁移到云平台,从而享受“云”的高效和持续的服务能力。

顾名思义,云原生是面向“云”而设计的应用,因此技术部分依赖于在传统云计算的3层概念(基础设施即服务(IaaS)、平台即服务(PaaS)和软件即服务(SaaS)),例如,敏捷的不可变基础设施交付类似于IaaS,用来提供计算网络存储等基础资源,这些资源是可编程且不可变的,直接通过API可以对外提供服务;有些应用通过PaaS服务本来就能组合成不同的业务能力,不一定需要从头开始建设;还有一些软件只需要“云”的资源就能直接运行起来为云用户提供服务,即SaaS能力,用户直接面对的就是原生的应用。

阅读更多

CNCF毕业的分布式追踪系统Jaeger拓扑生成原理

随着互联网架构的流行,越来越多的系统开始走向分布式化、微服务化。如何快速发现和定位分布式系统下的各类性能瓶颈成为了摆在开发者面前的难题。借助分布式追踪系统的调用链路还原能力,开发者可以完整地了解一次请求的执行过程和详细信息。但要真正分析出系统的性能瓶颈往往还需要链路拓扑、应用依赖分析等工具的支持。这些工具使用起来虽然简单,但其背后的原理是什么?本文将带您一起探索。

Jaeger 作为从 CNCF 毕业的第七个项目,已经成为了云原生架构下分布式追踪系统的第一选择。本文将以 Jaeger 为例,介绍基于 Tracing 数据的拓扑关系生成原理,文中使用的版本为1.14。

阅读更多

蚂蚁金服 Service Mesh 深度实践

1. 蚂蚁金服落地情况介绍

发展历程和落地规模

ppt-5.png

Service Mesh 技术在蚂蚁金服的落地,先后经历过如下几个阶段:

  • 技术预研 阶段:2017年底开始调研并探索 Service Mesh 技术,并确定为未来发展方向;
  • 技术探索 阶段:2018年初开始用 Golang 开发 Sidecar SOFAMosn,年中开源基于 Istio 的 SOFAMesh;
  • 小规模落地 阶段:2018年开始内部落地,第一批场景是替代 Java 语言之外的其他语言的客户端 SDK,之后开始内部小范围试点;
  • 规模落地 阶段:2019年上半年,作为蚂蚁金融级云原生架构升级的主要内容之一,逐渐铺开到蚂蚁金服内部的业务应用,并平稳支撑了618大促;
  • 全面大规模落地 阶段:2019年下半年,在蚂蚁金服内部的业务中全面铺开,落地规模非常庞大,而且准备迎接双十一大促;

阅读更多

Google Container Tools: Skaffold

Skaffold is a command line tool that facilitates continuous development for Kubernetes applications. You can iterate on your application source code locally then deploy to local or remote Kubernetes clusters. Skaffold handles the workflow for building, pushing and deploying your application. It also provides building blocks and describe customizations for a CI/CD pipeline.

20个月测试,40次迭代,这款谷歌Kubernetes自动化开源工具通用了

Features

  • Fast local Kubernetes Development
    • optimized source-to-k8s – Skaffold detects changes in your source code and handles the pipeline to buildpush, and deploy your application automatically with policy based image tagging and highly optimized, fast local workflows
    • continuous feedback – Skaffold automatically manages logging and port-forwarding
  • Skaffold projects work everywhere
    • share with other developers – Skaffold is the easiest way to share your project with the world: git clone and skaffold run
    • context aware – use Skaffold profiles, user level config, environment variables and flags to describe differences in environments
    • CI/CD building blocks – use skaffold run end-to-end or just part of skaffold stages from build to deployment in your CI/CD system
  • skaffold.yaml – a single pluggable, declarative configuration for your project
    • skaffold init – Skaffold discovers your files and generates its own config file
    • multi-component apps – Skaffold supports applications consisting of multiple components
    • bring your own tools – Skaffold has a pluggable architecture to allow for different implementations of the stages
  • Lightweight
    • client-side only – Skaffold does not require maintaining a cluster-side component, so there is no overhead or maintenance burden to your cluster.
    • minimal pipeline – Skaffold provides an opinionated, minimal pipeline to keep things simple

Installing Skaffold

Stable binary

For the latest stable release download and place it in your PATH:

https://storage.googleapis.com/skaffold/releases/latest/skaffold-linux-amd64

Run these commands to download and place the binary in your /usr/local/bin folder:

curl -Lo skaffold https://storage.googleapis.com/skaffold/releases/latest/skaffold-linux-amd64
chmod +x skaffold
sudo mv skaffold /usr/local/bin

Latest bleeding edge binary

For the latest bleeding edge build, download and place it in your PATH:

https://storage.googleapis.com/skaffold/builds/latest/skaffold-linux-amd64

Run these commands to download and place the binary in your /usr/local/bin folder:

curl -Lo skaffold https://storage.googleapis.com/skaffold/builds/latest/skaffold-linux-amd64
chmod +x skaffold
sudo mv skaffold /usr/local/bin

 

A Glance at Skaffold Workflow and Architecture

Skaffold simplifies your development workflow by organizing common development stages into one simple command. Every time you run skaffold dev, the system

  1. Collects and watches your source code for changes
  2. Syncs files directly to pods if user marks them as syncable
  3. Builds artifacts from the source code
  4. Tests the built artifacts using container-structure-tests
  5. Tags the artifacts
  6. Pushes the artifacts
  7. Deploys the artifacts
  8. Monitors the deployed artifacts
  9. Cleans up deployed artifacts on exit (Ctrl+C)

What’s more, the pluggable architecture is central to Skaffold’s design, allowing you to use the tool you prefer in each stage. Also, Skaffold’s profiles feature grants you the freedom to switch tools as you see fit depending on the context.

For example, if you are coding on a local machine, you can configure Skaffold to build artifacts with local Docker daemon and deploy them to minikube using kubectl, the Kubernetes command-line interface and when you finalize your design, you can switch to the production profile and start building with Google Cloud Build and deploy with Helm.

Skaffold supports the following tools:

  • Build
    • Dockerfile locally
    • Dockerfile in-cluster (kaniko)
    • Dockerfile on cloud (Google Cloud Build)
    • Bazel locally
    • Jib Maven/Gradle locally
  • Test
    • with container-structure-test
  • Tag
    • tag by git commit
    • tag by current date&time
    • tag by environment variables based template
  • Push
    • don’t push – keep the image on the local daemon
    • push to registry
  • Deploy
    • Kubernetes Command-Line Interface (kubectl)
    • Helm
    • kustomize

architecture

Besides the above steps, skaffold also automatically manages the following utilities for you:

  • forwards container ports to your local machine using kubectl port-forward
  • aggregates all the logs from the deployed pods

Documentation

Documentation for latest release: https://skaffold.dev

Documentation for latest build: https://skaffold-latest.firebaseapp.com

 

蚂蚁金服万级规模 K8s 集群管理系统如何设计

Kubernetes 以其超前的设计理念和优秀的技术架构,在容器编排领域拔得头筹。越来越多的公司开始在生产环境部署实践 Kubernetes,在阿里巴巴和蚂蚁金服 Kubernetes 已被大规模用于生产环境。Kubernetes 的出现使得广大开发同学也能运维复杂的分布式系统,它大幅降低了容器化应用部署的门槛,但运维和管理一个生产级的高可用 Kubernetes 集群仍十分困难。本文将分享蚂蚁金服是如何有效可靠地管理大规模 Kubernetes 集群的,并会详细介绍集群管理系统核心组件的设计。

系统概览

Kubernetes 集群管理系统需要具备便捷的集群生命周期管理能力,完成集群的创建、升级和工作节点的管理。在大规模场景下,集群变更的可控性直接关系到集群的稳定性,因此管理系统可监控、可灰度、可回滚的能力是系统设计的重点之一。除此之外,超大规模集群中,节点数量已经达到 10K 量级,节点硬件故障、组件异常等问题会常态出现。面向大规模集群的管理系统在设计之初就需要充分考虑这些异常场景,并能够从这些异常场景中自恢复。

阅读更多

什么是Serverless架构?

Serverless(无服务器架构)是指服务端逻辑由开发者实现,运行在无状态的计算容器中,由事件触发,完全被第三方管理,其业务层面的状态则存储在数据库或其他介质中。

Serverless 是云原生技术发展的高级阶段,可以使开发者更聚焦在业务逻辑,而减少对基础设施的关注。

Serverless 在云原生技术中的地位

下图来自谷歌云平台官网,是对云计算的一个很好的分层概括,其中 serverless 就是构建在虚拟机和容器之上的一层,与应用本身的关系更加密切。

阅读更多

基于Istio的灰度发布测试

灰度发布(又名金丝雀发布)介绍

当应用上线以后,运维面临的一大挑战是如何能够在不影响已上线业务的情况下进行升级。做过产品的同学都清楚,不管在发布前做过多么完备的自动化和人工测试,在发布后都会出现或多或少的故障。根据墨菲定律,可能会出错的版本发布一定会出错。

“ANYTHING THAN CAN GO WRONG WILL GO WRONG”

—— MURPHY’S LAW

因此我们不能寄希望于在线下测试时发现所有潜在故障。在无法百分百避免版本升级故障的情况下,需要通过一种方式进行可控的版本发布,把故障影响控制在可以接受的范围内,并可以快速回退。

可以通过灰度发布(又名金丝雀发布)来实现业务从老版本到新版本的平滑过渡,并避免升级过程中出现的问题对用户造成的影响。

阅读更多

Steering Kubernetes to an application-centric future

Kubernetes is the cloud’s breakout success story. It’s gone from nothing to the application development equivalent of a superstar in only a few years, a rapid growth that’s left developers looking for better ways to build and manage Kubernetes-hosted applications.

There have been plenty of workarounds and extensions. Tools such as Helm make it easy to deploy resources to clusters, whereas CNAB (Cloud Native Application Bundle) wraps up applications and all their dependencies ready for deployment. At a lower level, services such as Draft help design and build basic services. You can build code and deploy it using familiar containers, and you can quickly assemble elements into Kubernetes applications. You can even automate management with Azure Kubernetes Services.

阅读更多

The Evolution of Architecture from SOA , to Microservice and to Cloud Native Application

进入 21 世纪以来,我们见证了企业分布式应用架构从 SOA (Service-oriented Architecture),到微服务架构,再到云原生应用架构的演化。我们先从我们熟悉的物理守恒定律说起:

  • 第一,企业 IT 系统的复杂性(熵)符合热力学第二定律。随着时间的推演,业务的变化,企业 IT 系统的复杂度会越来越高;
  • 第二,在计算机交互设计中有一个著名的复杂性守恒定律[1]。应用交互的复杂性不会消失,只会换一种方式存在。这个原理也同样适用于软件架构。引入新的软件架构,不会降低IT系统的整体复杂性。

现代软件架构的核心任务之一就是定义基础设施与应用的边界,合理切分复杂性,减少应用开发者需要面对的复杂性。换句话说,就是让开发者专注在核心价值创新上,而把一些问题交给更合适的人和系统来解决。

阅读更多

学习一下美团集群调度系统HULK的技术演进

本文根据美团基础架构部/弹性策略团队负责人涂扬在2019 QCon(全球软件开发大会)上的演讲内容整理而成。本文涉及到的Kubernetes集群管理技术,美团相关的技术实践可参考此前发布的相关文章。

HULK是美团的容器集群管理平台。在HULK之前,美团的在线服务大部分部署都是在VM上,在此期间,我们遇到了很大的挑战,主要包括以下两点:

  • 环境配置信息不一致:部分业务线下验证正常,但线上验证却不正常。
  • 业务扩容流程长:从申请机器、资源审核到服务部署,需要5分钟才能完成。

因为美团很多业务都具有明显的高低峰特性,大家一般会根据最高峰的流量情况来部署机器资源,然而在业务低峰期的时候,往往用不了那么多的资源。在这种背景下,我们希望打造一个容器集群管理平台来解决上述的痛点问题,于是HULK项目就应运而生了。

阅读更多

Service Mesh与Istio

微服务架构的演进

作为一种架构模式,微服务将复杂系统切分为数十乃至上百个小服务,每个服务负责实现一个独立的业务逻辑。这些小服务易于被小型的软件工程师团队所理解和修改,并带来了语言和框架选择灵活性,缩短应用开发上线时间,可根据不同的工作负载和资源要求对服务进行独立缩扩容等优势。

另一方面,当应用被拆分为多个微服务进程后,进程内的方法调用变成了了进程间的远程调用。引入了对大量服务的连接、管理和监控的复杂性。

浅谈微服务架构中的基础设施:Service Mesh与Istio

该变化带来了分布式系统的一系列问题,例如:

阅读更多

Istio的分层架构

Istio是ServiceMesh的产品化落地:

  1. 它帮助微服务之间建立连接,帮助研发团队更好的管理与监控微服务,并使得系统架构更加安全
  2. 帮助微服务分层解耦,解耦后的proxy层能够更加专注于提供基础架构能力,例如:
    • 服务发现(discovery)
    • 负载均衡(load balancing)
    • 故障恢复(failure recovery)
    • 服务度量(metrics)
    • 服务监控(monitoring)
    • A/B测试(A/B testing)
    • 灰度发布(canary rollouts)
    • 限流限速(rate limiting)
    • 访问控制(access control)
    • 身份认证(end-to-end authentication) 等功能。
  3. 它使得业务工程团队与基础架构团队都更加高效的工作,各自专注于自己的工作,更好的彼此赋能

今天来说一下Istio的核心架构设计

阅读更多

Prometheus – 云原生时代的监控平台

一、简介

Kubernetes自从2012年开源以来便以不可阻挡之势成为容器领域调度和编排的领头羊,Kubernetes是Google Borg系统的开源实现,于此对应Prometheus则是Google BorgMon的开源实现。Prometheus是由SoundCloud开发的开源监控报警系统和时序列数据库。从字面上理解,Prometheus由两个部分组成,一个是监控报警系统,另一个是自带的时序数据库(TSDB)。

2016年,由Google发起的Linux基金会旗下的原生云基金会(Cloud Native Computing Foundation)将Prometheus纳入其第二大开源项目。Prometheus在开源社区也十分活跃,在GitHub上拥有两万多Star,并且系统每隔一两周就会有一个小版本的更新。

阅读更多

开源的Prometheus

Prometheus是开源的系统监控报警框架。【代码开源地址: https://github.com/prometheus/prometheus】

它启发于 Google 的 borgmon 监控系统,由工作在 SoundCloud 的 google 前员工在 2012 年创建,作为社区开源项目进行开发,并于 2015 年正式发布。2016 年,Prometheus 正式加入 Cloud Native Computing Foundation,成为受欢迎度仅次于 Kubernetes 的项目。

作为新一代的监控框架,Prometheus 具有以下特点:

  • 强大的多维度数据模型:
  1. 时间序列数据通过 metric 名和键值对来区分。
  2. 所有的 metrics 都可以设置任意的多维标签。
  3. 数据模型更随意,不需要刻意设置为以点分隔的字符串。
  4. 可以对数据模型进行聚合,切割和切片操作。
  5. 支持双精度浮点类型,标签可以设为全 unicode。
  • 灵活而强大的查询语句(PromQL):在同一个查询语句,可以对多个 metrics 进行乘法、加法、连接、取分数位等操作。
  • 易于管理: Prometheus server 是一个单独的二进制文件,可直接在本地工作,不依赖于分布式存储。
  • 高效:平均每个采样点仅占 3.5 bytes,且一个 Prometheus server 可以处理数百万的 metrics。
  • 使用 pull 模式采集时间序列数据,这样不仅有利于本机测试而且可以避免有问题的服务器推送坏的 metrics。
  • 可以采用 push gateway 的方式把时间序列数据推送至 Prometheus server 端。
  • 可以通过服务发现或者静态配置去获取监控的 targets。
  • 有多种可视化图形界面。
  • 易于伸缩。

需要指出的是,由于数据采集可能会有丢失,所以 Prometheus 不适用对采集数据要 100% 准确的情形。但如果用于记录时间序列数据,Prometheus 具有很大的查询优势,此外,Prometheus 适用于微服务的体系架构。

阅读更多

最受欢迎的9个顶级云原生开源项目

很有可能自己的下半个人生技术生涯就从Service Mesh开始了。趁早不趁晚,熟悉一下云原生计算基金会上的这些项目。

随着使用容器开发应用程序的实践越来越流行,云本地应用程序也在不断增加。根据定义:

“云原生技术用于开发应用程序,这些应用程序使用封装在容器中的服务构建,部署为微服务,并通过敏捷的DevOps流程和持续交付工作流在弹性基础设施上进行管理。”

该描述包括四个元素,这些元素与云原生应用程序是一体的:

  1. 容器
  2. 微服务
  3. DevOps
  4. 持续集成和持续交付(CI/CD)

尽管这些技术有着非常独特的历史,但它们相互补充得很好,并在短时间内导致云原生应用程序和工具集的指数级增长。这张云原生计算基金会(CNCF)的信息图表显示了云原生应用生态系统的大小和广度。

2019年最受欢迎的9个顶级云原生开源项目

云原生计算基金会项目图

阅读更多

为什么 Serverless 比其他软件开发方法更具优势?

本文定义并解释了 Serverless 与其他应用程序架构的不同之处,然后“证明”了 Serverless 应用程序架构在实施得当的情况下会优于非 Serverless 架构。最后总结了很多经验法则,帮助架构师和开发人员实现 Serverless。

关键要点

  • Serverless 应用程序不涉及操作服务器,并且应用程序的运行时间完全委托给了服务提供者。
  • Serviceful Serverless 应用程序是一种尽可能利用第三方服务实现后端功能的应用程序。
  • Serviceful Serverless 应用程序的主要优点是,与其他方式构建的应用程序相比,它们需要的后端代码数量要少很多。
  • 更少的代码意味着更少的技术债务,更好和更一致的持续软件开发速度,并为普通开发人员提供更好的可维护性。
  • 基础设施即服务的兴起引发了一种新的软件开发最佳实践(“云原生”),Serverless 也是如此。你不可能将云原生应用程序迁移到功能即服务(FaaS)平台,并期望它们会获得最好的设计。

大多数关于 Serverless 应用程序的文章都没有提供足够的细节来解释为什么 Serverless 比其他软件开发方法更具优势,或者在解释为什么 Serverless 比非 Serverless 解决方案更好时显得有点杂乱无章。本文解释了 Serverless 与其他应用程序架构的不同之处,然后“证明”了 Serverless 应用程序架构在实施得当的情况下会优于非 Serverless 架构。最后总结了很多经验法则,帮助架构师和开发人员实现 Serverless。本文对作者在 QCon NY 2018 和 Serverlessconf SF 2018 大会上提出的概念和示例进行了扩展。

我们在优化什么?

阅读更多

到底什么是Kubernetes Pod?

【译】What are Kubernetes Pods Anyway?

最近看到了一条关于Kubernetes Pods的推特,来自了不起的Amy Codes(我真的希望这是她的真名):

到底什么是Kubernetes Pod?

虽然不是100%准确(容器并不是一个真正的东西。我们将在稍后讨论这个东东)不过它确实指出了一个令人惊奇的事实。看来确实有必要探讨一下pod和容器到底是什么。

关于Pods,Kubernetes文档提供了对Pods最好、最完整的解释,但它是用非常一般的意义编写的,使用了很多术语。但我还是建议你好好读读它,因为它比我能写的解释更好、更正确。为官方文档打call!!

是容器,也不是容器

许多人已经知道Linux“容器”并不是真实存在的。Linux中没有所谓的“容器”。众所周知,容器使用了Linux内核中的两个特性(命名空间和cgroups)来执行的普通进程。命名空间允许我们为进程提供一个“视图”,该视图将所有内容隐藏在这些命名空间之外,从而为进程提供自己的运行环境。这使得进程无法看到或干扰其他进程。

阅读更多

Kubernetes引入pod的概念,为何不直接操作Docker容器

首先要明确一个概念,Kubernetes并不是只支持Docker这一个容器运行,我们知道Kubernetes通过CRI这个抽象层,支持除Docker之外的其他容器运行,比如rkt甚至支持客户自定义的容器运行。因此,借助CRI这个抽象层,使得Kubernetes不依赖于底层某一种具体的容器运行时实现技术,而是直接操作pod,pod内部再管理多个业务上紧密相关的用户业务容器,这种架构便于Kubernetes做扩展。这是第一个原因。

为什么Kubernetes要引入pod的概念,而不直接操作Docker容器

阅读更多

Kubernetes 集群架构与高可用解析

基本工作过程

Kubernetes 的核心工作过程:

  1. 资源对象:Node、Pod、Service、Replication Controller 等都可以看作一种资源对象
  2. 操作:通过使用 kubectl 工具,执行增删改查
  3. 存储:对象的目标状态预设状态),保存在 etcd 中持久化储存;
  4. 自动控制:跟踪、对比 etcd 中存储的目标状态与资源的当前状态,对差异资源纠偏,自动控制集群状态。

Kubernetes 实际是:高度自动化的资源控制系统,将其管理的一切抽象为资源对象,大到服务器 Node 节点,小到服务实例 Pod。

阅读更多

最简单的Kubernetes描述

什么是Kubernetes?

Kubernetes(k8s)是自动化容器操作的开源平台,这些操作包括部署,调度和节点集群间扩展。如果你曾经用过Docker容器技术部署容器,那么可以将Docker看成Kubernetes内部使用的低级别组件。Kubernetes不仅仅支持Docker,还支持Rocket,这是另一种容器技术。

使用Kubernetes可以:

  • 自动化容器的部署和复制
  • 随时扩展或收缩容器规模
  • 将容器组织成组,并且提供容器间的负载均衡
  • 很容易地升级应用程序容器的新版本
  • 提供容器弹性,如果容器失效就替换它,等等…

实际上,使用Kubernetes只需一个部署文件,使用一条命令就可以部署多层容器(前端,后台等)的完整集群:

$ kubectl create -f single-config-file.yaml

kubectl是和Kubernetes API交互的命令行程序。现在介绍一些核心概念。

阅读更多

Istio 基础知识

一、Istio概念

使用云平台可以为组织提供丰富的好处。然而,不可否认的是,采用云可能会给 DevOps 团队带来压力。开发人员必须使用微服务以满足应用的可移植性,同时运营商管理了极其庞大的混合和多云部署。Istio 允许您连接、保护、控制和观测服务。

在较高的层次上,Istio 有助于降低这些部署的复杂性,并减轻开发团队的压力。它是一个完全开源的服务网格,可以透明地分层到现有的分布式应用程序上。它也是一个平台,包括允许它集成到任何日志记录平台、遥测或策略系统的 API。Istio 的多样化功能集使您能够成功高效地运行分布式微服务架构,并提供保护、连接和监控微服务的统一方法。

什么是服务网格?

在从单体应用程序向分布式微服务架构的转型过程中,开发人员和运维人员面临诸多挑战,使用 Istio 可以解决这些问题。

服务网格(Service Mesh)这个术语通常用于描述构成这些应用程序的微服务网络以及应用之间的交互。随着规模和复杂性的增长,服务网格越来越难以理解和管理。它的需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及通常更加复杂的运维需求,例如 A/B 测试、金丝雀发布、限流、访问控制和端到端认证等。

Istio 提供了一个完整的解决方案,通过为整个服务网格提供行为洞察和操作控制来满足微服务应用程序的多样化需求。

阅读更多


1 2