目前,行业内基于云原生思想的开源项目,重点在于管理、控制微服务以及微服务架构下服务之间的通信问题。它们有效的解决了“服务异构化”、“动态化”、“多协议”场景所带来的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 条评论