ruffylangzi
作者ruffylangzi2019-07-23 15:07
软件架构设计师, 博云

Ambassador,云原生应用的“门神”

字数 1199阅读 1363评论 0赞 3

目前,行业内基于云原生思想的开源项目,重点在于管理、控制微服务以及微服务架构下服务之间的通信问题。它们有效的解决了“服务异构化”、“动态化”、“多协议”场景所带来的east/west流量的管控问题,而针对north/south的流量控制仅仅提供了ingress/egress做流量入口,出口的管理。

为了解决云原生环境下的north/south流量控制问题,Ambassador开始走入大家的视线。Ambassador是一个网关,其中以Enovy作为具体策略的执行者,Ambassador抽象到控制平面,下发一些的网关控制指令。具体架构如下所示:


从架构图能够清晰的看到,Ambassador以Enovy基础扩展而来, 实现思路上同样采取“控制平面”、数据平面想分离的设计思想 。在容器生态环境下,无论是对kubernetes的traefik,还是istio下的Ingress-gateway都是强有力的扩展。

Ambassador有哪些特性呢?

异构化服务支撑

云原生架构下各个服务要求只要遵循相同的通信规范即可,因此不再强调语言,架构等一致性问题。Ambassador恰好能够有效的把请求流量导入到异构下的各个服务,并且完成服务的请求的管理控制。

支持基于各个服务的配置,更能够进一步实现“超时”,“速率限制”,“身份验证策略”等网关级别的细粒度控制。

能够支持不同层级的通信协议,L7协议包括HTTP、HTTP/2、grpc、trpc-web、websocket,L4协议TCP。

动态服务

服务更新会导致应用程序不断变化。Ambassador能够友好的支撑云原生应用的动态特性,具备如下特性:

  • 允许在生产测试,支持不同的灰度发布策略
  • 细化可观察性指标,有力管控服务行为
  • 配置信息的无感之变更,不会对最终用户产生影响

分散工作流程

云原生的应用下,允许不同的服务开发针对其自身的服务进行优化。

Ambassador为了满足这个特性,能够允许各个开发团队自身维护自己的服务,并且独立接入和使用Ambassador的配置信息,一改之前网关层统一配置变更思路,从而避免影响其他运行服务。

Ambassador部署

Ambassador提供了多种不同的部署方式来满足用户需求。包括kubernetes yaml部署,helm部署,docker image部署以及docker compose部署等。既可以作为独立的程序运行提供网关能力,同样能够与kubernetes,istio等云原生的框架集成,来充当入口流量的管理者。

以docker image部署说明Ambassador的部署配置。

查看Ambassador日志,确定运行情况。

基于docker image启动时,ambassador采用默认的config配置信息完成初始化工作。

访问Ambassador:

初始化默认用户名admin,密码admin。 能够正常的看到访问页面


如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

3

添加新评论0 条评论

Ctrl+Enter 发表

作者其他文章

相关文章

相关问题

相关资料

X社区推广