转载

为微服务平台探寻适合的抽象。与VAMP创作者Olaf Molenveld的问答

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的一些高级功能也可以应用于不同的容器解决方案，这样也有助于满足用户在多容器云和多调度器方面的需求，借此降低对某个单一容器云或供应商的依赖。