我在皇宫，你可能知道，我最近刚从日本东京旅行回来。我从日本同事那里了解到，十月是游览东京的好时机，因为天气非常温和，旺季刚刚过去。我最喜欢的旅游景点是东京天空树，可以看到令人惊叹的360度景色。作为一名游客很有趣，但我去东京的主要原因是在东京的OpenStack峰会上发表演讲。东京OpenStack峰会，我的会议名为"用OpenStack+Docker大规模管理微服务"。正如你所料，我花了很多时间讨论Docker、微服务和软件交付管道。我们都听说过微服务和巨石应用。它们在开发、测试和部署方面各有利弊。目前，就最佳实践而言，形成共识的是从整体架构开始，在将整体架构分解为微服务之前，先对产品进行开发，获得一些业务吸引力和客户。（顺便说一句，要深入了解微服务架构和部署模式，请查看我们的CTO安德斯沃格伦，在最近的does上的精彩演讲15）。在我的演讲中，我进一步详细介绍了这些理论，包括一个现场演示（见下面的录音）。在这篇文章中，我想使用我们的免费版本cloudbeesflow，将一个巨石应用程序分解为微服务的建模。为了说明分解过程，我创建了一个演示应用程序，该应用程序查询天气提要（基于davefp的天气小部件），并显示全球16个城市的温度。对于UI，我创建了一个漂亮的仪表板，可以通过一个Docker容器部署为一个整体。仪表板中的每个小部件都被编写成一个快速的作业，每30秒运行一次，并查询Yahoo天气API来显示结果。我编写了一些Selenium测试，这些测试也运行在Docker中以测试单片应用程序。在CloudBees Flow中建模微服务的管道、应用和部署过程：巨石：这就是CloudBees Flow:CloudBees Flow pipeline model中的软件交付管道是什么样子的：CloudBees Flow app model，这就是直接的、串行的、部署过程的样子：CloudBees Flow部署过程模型微服务分解：接下来，我想展示如何分解这个应用程序，并决定将每个城市划分为自己的微服务。当然，这是一个简单的分解方案，只是为了说明这一点。在实际场景中，您可能会根据数据馈送的类型（即温度、交通警报、基于地理位置的建议）、支持的语言等重新构建微服务。在我的示例中，每个微服务现在都有自己的管道，从源（git存储库）到工件存储库（docker registry）。示例管道：带有容器的微服务要组装所有这些微服务，我创建了一个松散的概念，即JSON输入形式的"应用程序清单"。将微服务作为应用程序部署的一种方式。JSON输入是CloudBees流管道的一个参数。现在，让我们比较一下CloudBees在Microservices表单中的分解后的整体外观：这是应用程序的软件交付管道的样子：CloudBees Flow Microservices管道模型应用程序：CloudBees Flow Microservices应用程序模型部署过程：CloudBees Flow Microservices部署模型通知每个微服务（在我们的例子中是city）可以并行部署，独立于其他服务。随着应用程序的成熟，在这个过程的前两个步骤中仍然有一个串行部署，您很可能也找到了分解这些步骤的方法。OpenStack如何适应：随着应用程序的碎片化，测试变得更加重要，以确保每个微服务没有问题或失败。随着您对环境的需求不断增加，您会发现对微服务的需求会大大增加。OpenStack和Docker能够很好地在测试或部署期间对基础设施进行弹性使用。在继续分解应用程序、添加更多团队成员或添加冗余以满足HA需求时，您可以轻松地添加/删除实例以满足应用程序的需要。看我演讲的录音：如果您有兴趣了解更多信息，您可以观看我的演讲录音，其中还包括一个很酷的产品演示：