写点什么

服务网格如何推动云与安生 App 开发的转型

  • 2020-05-18
  • 本文字数:1807 字

    阅读完需:约 6 分钟

服务网格如何推动云与安生App开发的转型

Kubernetes 因其许多精巧的功能与先进的理念而具有变革性的力量,其中之一就是出于开发人员的角度而设计的 API 功能。你可以在 Kubernetes 中创建 Deployment 和 Service,而不是诸如机器、磁盘和网络之类的基础架构对象。你依旧使用计算、网络和存储,但是你创建的资源将会和应用程序部署一致。


然而,在容器中的运行进程或者在 Kubernetes 中的 pod 并不是全部。应用程序不仅只有它的运行代码而已,它还由网络通信来定义。这些消息和特性(如拓扑、路由、指标和访问控制)定义了分布式系统及其容器镜像。


因此,显而易见的是——面向应用程序的 API 定义了应用程序的通信,并且这是云原生开发人员经验中很重要的一部分。这些 API 通常被称为 Service Mesh API。Service Mesh API 可以让应用程序开发人员使用开发人员友好的声明式资源来表达分布式应用程序的连接性。至于如何实现应用程序连接的具体细节留给 Service Mesh 的几个项目,如 Consul、Linkerd、Istio(在Rancher 2.3中已正式集成)或 Envoy。


解耦服务网格用户和服务网格实现体现了 Kubernetes 重要的设计原则,即使用声明式 API 的模块化组合和解耦的基础架构层。这一设计原则使得 Kubernetes 由大量通用可插拔 API 组成。例如,云供应商绑定,该绑定使 Kubernetes 可以跨 Azure、AWS、Google 等公有云运行,此外,还能运行 CNI(容器网络接口)、CSI(容器存储接口)和 CRI(容器运行时接口),这些接口通常定义容器如何与计算、网络和存储进行交互。


服务网格中也存在类似的接口,通常称为服务网格接口(SMI),它是为了解决 Service Mesh 标准化问题而由微软牵头引入的。它定义了一组标准通用的 API,为开发人员提供跨不同服务网格技术的互通性。SMI 是一个标准的接口,它能在任何具体的 Service Mesh 产品(如 Istio、Linkerd 或 Consul)之上抽象出一个公共层,屏蔽掉上层应用、工具或生态系统对具体 Service Mesh 项目的实现细节。



将 API 规范与实现分开为整个 Kubernetes 生态系统提供了独一无二的价值,因此在 Service Mesh 中提供同样的规范也能为 Service mesh 技术提供相同的价值。一个通用的标准 API 可以让开发人员构建一个可移植的应用程序——无论是从本地集群迁移到基于云的集群,或者在不同的公有云上进行迁移。而且,一个通用的接口意味着开发人员构建的实用工具可以应用于整个生态中。


当 API 和实现更紧密地绑在一起时,采用一个新的 API(或一组 API)就会成为一个充满挑战的选择。如果一段时间之后发现这一实现不合适,则更改该实现需要继续进行大量的操作,并且需要重新学习各种概念和实现工具,所需成本极高。一个标准化的 API 将改变这一现状,由于用户是从 API 的实现中抽象出来的,因此只需一点改变就可以更换实现。这意味着成功地采用一个网格不一定需要成功地使用某种实现,换言之,使用一种诸如服务网格之类的新技术风险变得更低了。


SMI 的设计理念是成为一个易于理解和实现的 API,因此仅由 4 个概念定义:


  • 路由(Route)定义通过 HTTP 或 TCP 进出应用程序的路径。

  • TrafficTarget 描述了应用程序是否可以在一组特定路由中进行调用(或接收调用)。



  • TrafficSplit 描述了如何根据实验目的在两个及以上的 Kubernetes 服务中拆分流量。



  • TrafficMetrics 描述了用于获取应用程序流量统计数据的通用指标终端。



使用此 API,可以以面向开发人员的方式定义应用程序的面向应用程序的核心结构。


对类似此接口主要考虑将其作为各个 Service Mesh 产品的“最小公分母”,也就是说,这对任何产品都没有用处。这始终是接口 API 所关注的问题。而解决此问题的方法是同时包含供应商特定的注释和随时间演变的规范。我们在这一演进中的灵感来自 OpenGL,尽管通用 API 和特定的图形卡功能之间也存在类似的矛盾, 但 OpenGL 还是取得了成功。在 SMI 中,API 供应商特定的注释会一直存在,并且不会移植。然而,随着时间的推移,将包含最受欢迎的供应商特定的功能,并将其添加到规范中。通过这种方式,此类演进希望确保大多数用户可以通过 SMI API 成功管理其服务网格。


Kubernetes 标志着向应用程序和面向开发人员的云 API 转型的开始。而 SMI 是这条道路上重要的下一步。


作者简介

Bredan Burns, 微软杰出工程师(DE)

Bredan Burns 是 Kubernetes 的联合创始人之一,现在是微软的杰出工程师。领导了 Azure Container Service(AKS)、Azure Container Instances、Azure Cloud Shell 和 Azure Resource Manager 的开发工作。


2020-05-18 18:03635

评论

发布
暂无评论
发现更多内容

云原生落地大爆发,企业和开发者如何把握先机?

阿里巴巴云原生

阿里云 云原生 ACK ACK Anywhere

我们找回了泄露的内存

Qunar技术沙龙

DGIOT物联网架构设计

dgiot

物联网 2月月更 2月日更 dgiot dgiot物联网

http请求中的payload

喀拉峻

网络安全

SAE 最佳实践范本:助力视野数科进入云原生“快车道”

阿里巴巴云原生

阿里云 Serverless 云原生 SAE

Serverless 架构开发手册 — “人人都是 Serverless 架构师”先导篇

阿里巴巴云原生

阿里云 Serverless 架构 云原生

一篇文章讲懂prometheus

流沙

云原生 监控 Prometheus

你的数据产品应该是一套解决方案

第519区

数据产品经理 解决方案 数据产品 2月月更

阿里巴巴如何进行测试提效 | 阿里巴巴DevOps实践指南

阿里云云效

阿里云 DevOps 云原生 测试 研发提效

情人节,码了一个程序员专属冰墩墩(内含源码免费获取)

ZEGO即构

前端 html/css 情人节 表白 冬奥会

企业为什么要做应用多活?

阿里巴巴云原生

阿里云 云原生 容灾

今天踩了一个基础坑

编程三昧

JavaScript 2月月更

从冬奥看中国科技(三):数字人的觉醒与进化

脑极体

SSH远程连接命令执行没反应不报错问题解决(-bash: fork: retry: Resource temporarily unavailable.[资源暂时不可用])

山河已无恙

SSH Linxu 2月月更

年轻用户逐渐成为数字营销主流受众,品牌营销方式该如何创新?

易观分析

内容营销

【附赠PPT】 KubeMeet 成都站回顾:让云原生应用交付和管理变得更简单!

阿里巴巴云原生

阿里云 Kubernetes 云原生 活动 开源项目

国内唯一!阿里云容器服务进入 Forrester 领导者象限

阿里巴巴云原生

阿里云 云原生 容器平台

阿里云容器服务差异化 SLO 混部技术实践

阿里巴巴云原生

阿里云 Kubernetes 云原生 混部技术

独家下载!阿里云云原生携 10+ 技术专家带来《云原生与云未来的新可能》

阿里巴巴云原生

阿里云 Kubernetes 云原生 电子书

dart系列之:集合使用最佳实践

程序那些事

flutter dart 程序那些事 2月月更

网络安全kali渗透学习 web渗透入门 如何进行基于Nmap的扫描方式

学神来啦

如何利用 AHAS 保障 Web 服务稳如磐石?

阿里巴巴云原生

阿里云 高可用 云原生 AHAS

买贵不买对?这个情人节,你的礼物选对了吗?

易观分析

情人节 美妆

Spring Boot Serverless 实战 | Serverless 应用的监控与调试

阿里巴巴云原生

阿里云 Serverless 云原生

Java&Go高性能队列之Disruptor性能测试

FunTester

Disruptor 性能测试 高性能 消息队列 FunTester

【网络安全】记一次挖矿病毒的应急响应

H

网络安全 应急响应

运营给产品送的情人节礼物是?

阿里云弹性计算

产品运营 情人节 轻量征文 用户投稿

Spring Boot Serverless 实战系列 | 性能调优

阿里巴巴云原生

阿里云 Serverless 架构 云原生

7*24 小时业务不中断!菜鸟乡村应用多活落地实践

阿里巴巴云原生

阿里云 云原生 实践案例 多活

KubeDL HostNetwork:加速分布式训练通信效率

阿里巴巴云原生

阿里云 云原生 分布式训练 KubeDL

如何快速构建服务发现的高可用能力

阿里巴巴云原生

阿里云 开源 微服务 云原生

服务网格如何推动云与安生App开发的转型_文化 & 方法_Rancher_InfoQ精选文章