采用Kubernetes时API网关面临的两个很重要的挑战
云栖号资讯:【点击查看更多行业资讯】
在这里您可以找到不同行业的第一手的上云资讯,还在等什么,快来!
KUBERNETES和边缘计算,扩展边缘管理并支持多种需求
使用微服务模式构建应用程序并将这些服务部署到Kubernetes上已成为当今运行云原生应用程序的实际方法。 在微服务架构中,单个应用程序被分解为多个微服务。 每个微服务均由一个小团队拥有,该团队有权并负责为特定的微服务做出正确的决策。
这种职责通常从用户请求到达的系统边缘开始,一直到服务的业务逻辑,再到相关的消息传递和数据存储架构。
Edge和Kubernetes入口
最终用户需要访问微服务。 内部微服务和最终用户之间的边界称为边缘。 为了使最终用户访问内部应用程序,流量需要越过边缘。 在Kubernetes中,流量使用一种称为入口的软件穿越边缘。
将API网关与在Kubernetes上运行的基于微服务的应用程序集成时,您必须考虑两个主要挑战:
- 如何扩展对100多种服务和相关API的管理; 和
- 网关如何支持通常跨整个边缘堆栈的广泛的微服务体系结构,协议和配置。
API网关:微服务的联络点
API网关是如何管理,保护和呈现API的核心。 它作为软件组件(或一系列组件)部署在虚拟机上或Kubernetes中,并充当系统的单个入口点。 API网关的主要职责是使用户能够可靠,安全地访问多个API,微服务和后端系统。
微服务和Kubernetes提供了实现灵活性。 例如,一个团队可以选择在系统的边缘(内部服务和最终用户之间的边界)公开基于容器的微服务,作为一组基于HTTP的REST API。 另一个团队可能会选择Protobufs和gRPC。 有实时流需求的团队可以通过WebSocket API公开其微服务。 Kubernetes中部署的任何API网关都必须支持所有这些协议。
每个团队不仅可以自由做出这些选择,而且对后果负责。 这通常转化为"您构建,运行"。 尽管并非每个组织都完全赞同这种工作方式,但是每个微服务团队都需要能够理解,诊断和配置处理每个服务以及每个用户对应用程序的请求的各个方面。 与应用程序和API相关的运行时要求的多样性意味着,每个团队都将使用边缘堆栈中的所有层,例如,动态请求处理,WAF和任何缓存实现。
微服务的开发范例(独立,授权和负责的团队)为使用API网关,Kubernetes入口和边缘的微服务团队带来了一系列新挑战。
在本文中,我们确定了边缘的两个重要挑战:管理独立的微服务以及访问全面的边缘堆栈。
挑战1:扩展边缘管理
随着部署的微服务数量的增加,管理边缘的挑战也越来越多
在微服务架构中,工程师将管理更多的服务和应用程序。 每个团队都需要能够独立管理他们的服务,以使发布与其他团队的计划脱钩。 在边缘公开应用程序的传统方法通常是通过集中的操作或平台团队来完成的。 但是,当组织拥有数百个微服务时,一个运维团队无法扩展以处理必要的变更量。
需要在边缘修改配置的典型更改:
- 正在部署的服务的新版本。
- 修改端点,路由指令或关联的后端服务。
- 身份验证和授权服务的更改。
- 修改非功能性需求,例如速率限制,超时,重试模式和断路。
- 用户对新功能的测试,例如,为一小部分Beta测试用户启用功能。
采用基于微服务的体系结构将导致发行数量显著增加。 这种增加只会加剧边缘管理方面的挑战,并增加集中式操作方法的压力。
挑战2:支持各种范围的边缘要求
微服务在边缘引入了许多新问题
微服务架构实现了架构灵活性。 应用程序开发人员利用这种灵活性来选择最适合服务特定要求的编程语言和体系结构。 无论架构如何,边缘都需要支持需要向用户公开的广泛功能。 这扩展了API网关的传统角色,并且与边缘整合工具需求相关的一些挑战包括:
- 熟练地路由各种协议的能力。 常见协议包括HTTP / 1.1,HTTP / 2,WebSocket,gRPC,gRPC-Web和TCP。
- 提供任何特定服务所需的完整边缘功能集合,范围从流量管理到可观察性再到身份验证等等。
- 为应用程序开发人员在自助服务模型中公开这些功能。
鼓励微服务团队实施的多样性使工程师可以选择"适合工作的工具"。 但是,基础平台的整合提供了许多好处。 与其允许开发人员构建定制的实现以提供额外的协议支持或安全处理,不如让其在边缘具有预先批准的"自助"选项,从而使他们可以选择最合适的选项,从而更加易于管理和扩展。 功能组合。
摘要
随着组织采用Kubernetes并转向基于微服务的体系结构,最终用户与内部微服务之间的边界出现了一系列新的挑战。 因此,系统的"边缘"以及相关技术(例如API网关)是采用微服务时的重点。 微服务的组织模型驱动着边缘的这些新挑战,在这种模型中,独立团队有权并负责为微服务制定正确的体系结构和实施决策。
管理系统边缘一直很复杂。 添加具有多种体系结构的更多服务只会增加对边缘的需求。 平台团队必须相应地设计,选择和实现其API网关和边缘工具。
【云栖号在线课堂】每天都有产品技术专家分享!
课程地址:https://yqh.aliyun.com/live立即加入社群,与专家面对面,及时了解课程最新动态!
【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8gvnK
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
总结:一些关于 CPU 的基本知识
云栖号资讯:【点击查看更多行业资讯】在这里您可以找到不同行业的第一手的上云资讯,还在等什么,快来! CPU是计算机的大脑。1、程序的运行过程,实际上是程序涉及到的、未涉及到的一大堆的指令的执行过程。当程序要执行的部分被装载到内存后,CPU要从内存中取出指令,然后指令解码(以便知道类型和操作数,简单的理解为CPU要知道这是什么指令),然后执行该指令。再然后取下一个指令、解码、执行,以此类推直到程序退出。 2、这个取指、解码、执行三个过程构成一个CPU的基本周期。 3、每个CPU都有一套自己可以执行的专门的指令集(注意,这部分指令是CPU提供的,CPU-Z软件可查看)。正是因为不同CPU架构的指令集不同,使得x86处理器不能执行ARM程序,ARM程序也不能执行x86程序。(Intel和AMD都使用x86指令集,手机绝大多数使用ARM指令集)。注:指令集的软硬件层次之分:硬件指令集是硬件层次上由CPU自身提供的可执行的指令集合。软件指令集是指语言程序库所提供的指令,只要安装了该语言的程序库,指令就可以执行。 4、由于CPU访问内存以得到指令或数据的时间要比执行指令花费的时间长很多,因此在CP...
- 下一篇
UC Flutter技术实践分享
摘要:UC于19年开始探索Flutter技术,并在同年年底进行规模化落地。规模化落地Flutter核心要解决的三类问题分别是工程构建体系的搭建,性能优化和动态性支持。本次分享将由阿里巴巴UC事业部无线开发专家刘森森为大家详细介绍UC在规模化落地Flutter过程中解决的问题,及其思考过程。 演讲嘉宾简介:阿里巴巴UC事业部无线开发专家——刘森森(花名:森尼)。14年加入UC,长期在UC信息流团队负责信息流业务的技术工作,近一年投入到创新产品的研发中,负责Flutter技术在创新产品的应用与实践。以下内容根据演讲视频http://mudu.tv/watch/5624777以及PPT整理而成。 本次分享主要围绕以下五个方面: 一、Flutter在UC落地的情况 二、工程体系构建
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Hadoop3单机部署,实现最简伪集群
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- Linux系统CentOS6、CentOS7手动修改IP地址
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- CentOS8安装Docker,最新的服务器搭配容器使用
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- Windows10,CentOS7,CentOS8安装Nodejs环境
- SpringBoot2全家桶,快速入门学习开发网站教程
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- CentOS7安装Docker,走上虚拟化容器引擎之路