Magnetic.io 打造了一个名为 VAMP (Very Awesome Microservices Platform,超赞的微服务平台)的开源微服务部署平台,该平台为开发、A/B 测试、金丝雀发布(Canary releasing)、自动缩放,以及集成式度量指标和事件引擎提供了一种“平台中立的微服务 DSL”。
目前 VAMP 可以部署在Apache Mesos/Mesosphere Marathon、Mesosphere 的DC/OS 或Docker Swarm 基础之上,VAMP 微服务部署中包含:用于描述单一服务和依赖项的静态构件种子(Breed),用于描述种子如何在运行时(通常定义为集群)中工作以及种子该具备哪些属性的蓝图(Blueprint),用于运行蓝图的部署(Deployment),以及针对入站流量的端口和出站流量的路由定义静态路由端点的网关(Gateway)。
路由为同一集群内不同服务之间的流量路由定义了一系列规则,在创建规则时,可通过流量百分比形式为流量指定权重,并针对特定流量设置一个或多个筛选器条件,或者也可以用流量百分比形式为其设置与条件筛选器相匹配的筛选器强度(Filter strength)。
该平台可收集并汇总度量指标和事件,同时可指定相应的服务级别协议(SLA)和升级(Escalation),例如可以实现容量的自动缩放。此外还可以定义“工作流”,工作流类似于“菜谱”,可以用组的形式为运行中的系统及其部署创建一系列自动变更。这样即可在微服务平台内实现反馈环路,例如部署、度量并回应。
InfoQ 最近与 magnetic.io(正是这家公司开发了 VAMP)的 CEO 兼共同创始人 Olaf Molenveld 谈到了如何寻找最适合的微服务平台抽象,容器技术的发展计划,以及平台即服务(PaaS)等内容。
InfoQ:嗨 Olaf,感谢加入今天的 InfoQ 讨论。您能否介绍一下 VAMP 微服务平台?
Molenveld:谢谢!VAMP 是一种开源解决方案,能够为基于容器和微服务的系统提供简便易用的金丝雀测试和发布功能。此外它还提供了强大的工作流功能,例如自动缩放之后进行恰当的排空(Drain)。
我们看到有越来越多的组织为了解决缩放和上市时间方面遇到的挑战而快速接受了类似( Docker )容器、微服务、API、大数据,以及持续交付等技术。这些技术每一个都能带来明显的收益,但为了能真正从中释放潜在的业务价值,必须将这些不同组件配合在一起使用才能提供适合 LEAN、敏捷,以及 Scrum 等方法论的 _ 持续改进的反馈环路 _。
为了从持续集成 / 交付进化为持续改进的环路,必须使用某种实验性系统作为“安全网”,并用这样的系统将 IT 和业务紧密连接在一起。诸如 Netflix 、AirBnB 以及 Facebook 等大获成功的互联网公司已经证明了 _ 金丝雀模式 _ 是一种实施此类安全网,让业务和 IT 合作交付业务价值的好方法,例如用实验性的方法更频繁地将新版本软件发布给符合特定条件的少部分访客,借此度量技术 _ 和 _ 业务绩效,并在必要时进行改善和修复,随后进行纵向扩展,而这一切都能用一种持续的过程进行。
直到最近,要实施类似这样的金丝雀模式依然是一项复杂并且昂贵的工作。VAMP 的目标是通过提供开源解决方案使得用户能够简单直接地执行金丝雀测试和发布。
我们早在 2014 年就与位于阿姆斯特丹的一个由有经验的工程师和架构师组成的团队一起着手开发 VAMP,目前全球从金融到媒体,从电子商务到 SaaS,以及软硬件制造商等不同行业都有组织正在使用或评估 VAMP。
InfoQ:目前有很多新兴的微服务平台。面对众多类似产品,VAMP 的定位是什么,针对如何为平台选择合适的抽象,您是否有什么想法或者建议?
Molenveld:VAMP 本身并不是一个完整的微服务 / 容器类 PaaS/ 堆栈,而只是专注于专门为通用微服务 / 容器堆栈提供高层次的金丝雀测试 / 发布和自动缩放功能。VAMP 能与很多容器和微服务平台集成,例如 Mesosphere 的 Open DC/OS 、 Apache Mesos / Mesosphere Marathon 、 Docker Swarm 以及(很快即将支持的) Kubernetes ,当然还有诸如 Cisco 的 Mantl 、 CapGemini 的 Apollo ,或 Rancher Labs 的 Rancher 等堆栈,以及诸如 MS Azure Container Service 等容器云,这些容器的编排程序都能与 VAMP 进行集成。
目前市面上的容器和微服务平台无法提供 VAMP 这种面向业务的金丝雀测试 / 发布功能,但却能提供技术上更为简单的负载平衡和“滚动升级”功能。习惯于使用诸如“Visual Website Optimizer”和“Optimizely”等 A/B 测试工具的用户会希望通过金丝雀测试功能帮助他们实现很多目标,例如为 Android 设备上所有使用 Chrome 的英国访客中的 2.5% 提供新版软件。如果不对当前的容器 / 微服务堆栈进行大量调整和手工操作,是无法实现这种颗粒度的控制的。VAMP 能够与这些容器轻松集成并增添这种高级功能。
另外由于 VAMP 使得软件的金丝雀测试 / 发布工作变得更简单,因此随着访客数量的变化,当软件的负载增加后还有必要让你的服务 / 容器能够自动缩放。VAMP 内建的服务级别协议(SLA)和升级(Escalation)工作流可以根据预定义的度量指标,例如响应时间或每秒请求数自动对容器进行扩容或缩容。
VAMP 可以将整个集群的度量指标进行汇总(毕竟你可能并不关心集群中某一实例的运行状况而只关心集群中的实例整体),同时可以确保缩容后的服务能恰当地排空,并能照顾到粘滞会话(Sticky-session)和存活时间(Time-to-live)问题。然而自动缩放仅仅是度量指标驱动的优化工作流的实现之一。VAMP 的工作流引擎和度量指标以及事件 API 使得用户可以轻松地创建各种类型的自定义事件以及度量指标驱动的优化工作流,例如“日出而作日落而息(Follow-the-sun)”、“装箱(bin-packing)”、“云爆发(cloud bursting)”、成本 / 性能优化,以及“灯火管制(brown-out)”场景。
简而言之,为了提供持续改进的反馈环路,必须具备能对服务 / 容器的部署和缩放、可编程的路由 / 负载平衡,以及大数据度量指标汇总这三个反馈环路的主要领域进行编排的系统。我们认为 VAMP 可以满足这样的要求。
为了实现我们需要的抽象级别,VAMP 在“容器云”的基础上提供了高层次的金丝雀和优化工作流功能,你可以将其称之为“容器 -PaaS”或 CaaS。VAMP 核心的可编程路由和负载平衡功能(例如将符合特定条件的某一百分比的流量路由至不同版本的软件)也能独立于容器单独使用。但当你了解到 VAMP 的实时动态自动缩放功能,以及我们目前所使用的容器和容器管理器自身的缩放功能后就会知道,这些场景需要这样的容器。
InfoQ:VAMP 支持在 Docker 和 Apache Mesos 上运行,很快还将支持 Kubernetes 和 Docker Swarm。一开始您为什么选择 Docker 和 Mesos 平台?
Molenveld:在我们从 2014 年开始设计和开发 VAMP 时,当时最成熟的容器集群管理器和编排技术就是 Mesos,最普遍的容器则是 Docker。因此一开始选择这两个平台进行集成是很合理的。随着 Docker 逐渐成熟,我们开始支持 Docker Swarm 作为集群管理器也就显得比较合理,况且 Docker 和 Docker Swarm 共享了同一套 API,对我们来说就显得更方便。
最近 Kubernetes 的使用率大幅激增,展现出极大的潜力。我们会持续增加与使用率高,前景好的容器平台的集成。同时我们还会与很多公司合作,以加载项的形式提供 VAMP 集成功能,例如其中一家公司目前正在进行 Rancher 与 VAMP 的集成。
InfoQ:调度(Scheduling)技术目前在容器领域很热门。您对这个技术的未来发展看法如何?自优化微服务体系结构是否有可能根据需求进行缩放并实现自身的安排?
Molenveld:是的,我们对调度技术的兴趣很大,这也是系统优化中很重要的一环。在我们专注于实现持续改进的反馈环路同时,也有必要通过不同功能帮助用户打造自优化的系统。最常见也最知名的优化工作流之一恰巧就是自动缩放,但自动缩放只是度量指标驱动的持续优化工作流的一个例子。
VAMP 可以对持续改进环路的三个核心领域(部署编排和缩放,可编程的路由,度量指标 / 大数据汇总)进行编排,同时可以很容易地创建并交付其他优化工作流。例如“日出而作日落而息”场景(白天资源扩容,夜间资源缩容)、装箱问题(优化基础结构的利用率),以及灯火管制反馈环路(使用流量调节技术将整个系统的速度降低到某一可接受的程度以避免彻底中断)。
所以没错,我们坚信负责确保整个系统顺利运行的团队迟早需要更专注于为业务和技术性能定义高层面的带宽和规则,这样的系统可以通过这些规则和边界确保成本和性能之间实现最优平衡,让团队更加专注于业务和客户价值的交付。当然这是一个实时的过程,系统也将持续进行自我监控、度量纠正 / 改进。
深度学习和 AI 将成为这些系统密不可分的组件,通过处理生成的海量数据可以学习、模拟、改善整个系统的性能。
当然这需要在开发、运维,以及业务之间进行比以往更深入的合作。但一些很聪明的公司已经在这样做了,我们期待着这一领域能够取得巨大的成果,而我们的希望就寄托在 VAMP 身上。
InfoQ:在某些程度上 VAMP 有些类似于 PaaS 平台,例如 Cloud Foundry 和 Rancher Labs 的 Rancher。您是否觉得 VAMP 会进化为一个完整的 PaaS 产品?
Molenveld:目前还不会。当我们于 2014 年着手这个项目时,我们的侧重点较为普遍,并且当时也很难预测容器和微服务解决方案在“寒武纪大爆炸”之后会有怎样的发展。目前整个市场已经变得更为清晰,我们也更了解自己的发展重心和附加值在哪里。VAMP 并不是 PaaS 或容器平台的代替品或竞争对手,而是当你需要使用金丝雀和优化工作流这样的工作模式时的一个强大补充。
我们能与使用率最大的容器管理器集成,VAMP 的一些高级功能也可以应用于不同的容器解决方案,这样也有助于满足用户在多容器云和多调度器方面的需求,借此降低对某个单一容器云或供应商的依赖。
InfoQ:读者如果想体验 VAMP 或对其做出自己的贡献,此时的最佳方式是什么?
我们提供了一个自包含的快速上手程序包,该程序包可以从我们的网站 http://vamp.io 下载,借此用一条命令就可以安装所有必要组件。另外我们还提供了上手教程,可以让大家通过上手实验体验金丝雀功能的强大之处。
对于使用全新开源 Mesosphere Open DC/OS 的人,VAMP 也可作为 DC/OS 通用程序包使用,你可以从 DC/OS 的仪表盘快速安装 VAMP。
如果喜欢这个产品,希望对 VAMP 进行改进或做出自己的贡献,我们欢迎大家以任何形式与我们合作!我们的开源项目已经发布到 Github ,此外还通过 Gitter 为大家提供实时聊天和帮助。当然,大家也可以给我们发邮件:info@magnetic.io 或 olaf@magnetic.io。
InfoQ:再次感谢您接受 InfoQ 的采访。您还有其他事情想与我们的读者分享吗?
Molenveld:感谢您为我提供的这次机会以及提出的好问题!我们真心认为容器、微服务,以及持续改进反馈环路的使用可以让我们更上一层楼,让团队更好地专注于为现实世界中的业务和客户提供价值,让所有参与者都能从中获益。
我们非常希望通过合作促成这样的愿景,如果您想加入我们的团队,想通过提供更新更酷的功能,想完善我们的代码,或想将 VAMP 与您自己的平台集成并提供金丝雀和优化功能,我很乐意跟您聊聊!另外我们也很乐于帮助组织借助 VAMP 实现金丝雀和优化工作流的强大威力。欢迎大家随时联系我们!
有关 VAMP 微服务平台的更多信息请参阅 vamp.io 网站或 VAMP GitHub 代码库。
查看英文原文: Searching for the Right Abstraction in a Microservice Platform. Q&A with VAMP creator Olaf Molenveld
评论