在最近的一次连续讨论（c9d9）视频播客中，专家小组成员讨论了Docker和微服务的规模。我们的专家小组成员包括：Dynatrace的技术策略师Andreas Grabber、Karux LLC的首席架构师Chris Haddad和固定.io；Esko Luontola，程序员和交互设计师；Phil Dougherty，集装箱船首席执行官；以及我们自己的Anders Wallgren和Sam Fall。在这一集中，小组成员讨论了微服务和容器的好处、它们的一些挑战以及在大型Docker化基础设施上构建、部署和运行微服务的最佳实践。继续阅读他们的见解！Docker和微服务——为什么？在开发人员方面，使用容器和microservices@orfjackal\c9d9更容易生成确定性的构建https://t.co/LOzBPUDCDvpic.twitter.com/IFVQDTeBld-CloudBees（@electricloud）2017年3月14日优点：容器使您能够指向一个运行时可执行文件，并将其追溯到特定的#Git tags@cobiacomm |#c9d9pic.twitter.com/LlRfJoWZOw-CloudBees（@electricloud）2017年3月14日如果您不从体系结构上考虑微服务，那么容器是扩展这些类型部署的一种经济高效的方法pic.twitter.com/bEsWGR99Fg-CloudBees（@electricloud）2017年3月14日#Docker的好处：维护时间减少，开发人员的时间减少，这意味着有更多的时间进行创新-Andreas Grabber#c9d9@Dynatracepic.twitter.com/9sD3QmzqVH-CloudBees（@electricloud）2017年3月14日Dougherty谈到了微服务和Docker兼容性，"当你将一个整体分解成小型的、可组合的服务时，Docker会派上用场。为什么？因为您可能有许多不同的团队都在处理单个服务。能够将它们打包并在团队、开发团队中共享它们，将它们组合在一起，并且能够轻松地处理它们是非常重要的。如果你打算不断地部署较小的服务，而不是每六个月推出一个庞大的整体，那么你需要一种方法来轻松实现这一点，并拥有不可变的构件，以便轻松地推出和部署。所以，它们真的是携手并进，让微服务更容易推出。"费尔补充道："不变性的因素，我认为这是一个很多人都会同意的。如果你想在整个管道中实现对等或忠诚，这一点很重要。‘它在我的环境中起作用了’之类的争论基本上消失了。"Grabber在微服务和Docker上插嘴说，"说到流水线速度，我们大量使用Docker进行测试，为了加速我们的管道——通过并行执行测试，通过能够测试单个服务，隔离，通常在每次签入时。我认为这很好，向左移动，尽早发现问题。我认为Docker是个很好的推动者。如果您构建一个微服务体系结构，是或否，那么显然会带来另一个好处。但我相信Docker本身在这种情况下已经非常有益。"当谈到Docker和微服务之间的协同作用时，Haddad补充道，"如果你真的要改变你的数字业务，你需要真正采取自上而下的方法。定义你的域，然后容器使你能够指向一个运行时可执行文件，甚至更好的是，把它追溯到特定的git标记，这样我就可以快速地将新特性合并到这个放置在容器中的域对象中。十字路口就在那里。你可以把两者合并起来，也可以把它们分开。容器不等于微服务，但总有办法把它们拼凑在一起，天然的花生酱和果冻或者两者之间有协同作用。"莱利补充了对文化方面的见解，"这也归结于文化，团队合作，不必担心每个人都完全同步。大多数敏捷环境只是一个非常快速的瀑布。也许我见过的10个敏捷环境中就有一个是真正的敏捷。所以，当我们向上移动时，你知道，你不能指望每个人都能按时完成工作。因此，特别是微服务，让您可以做一些我们都说过但尚未完全实现的酷事。"Luontola专注于开发方面的影响，"如果你的系统是一个数据库或其他一些外部数据依赖，只要一个命令，你就可以运行开发环境——这就像，好吧，这里有一些其他团队，如果他们在Docker上运行，就会产生应用程序。但即使是在这些简单的项目中，你只需要一个数据库和一些东西。即使在那里，Docker也是个好处。我也有一些开源项目，我正在维护，其中一个项目叫做Retrolambda。我对Java5、6、7、8和9运行测试。因此，当我只需要一个容器就可以设置所有环境时，这很不错。"Wallgren强调了容器的成本效益，他补充道："在某些方面，这几乎是一个必要的响应，以降低在给定硬件上运行服务的开销。一旦你开始研究它，在某个地方仍然有一个CPU。不管你有多没有服务器，你也不是没有CPU。我会坚持下去的。如果你不从架构上做，如果你开始做微服务，那么在某个时候，你的首席财务官或首席执行官会走进你的办公室，说：‘嘿，我们怎么会有这么多昂贵的虚拟机？我们能用便宜点的吗？"容器，你知道的，确实是唯一一个在部署方面更便宜的方法。从成本或资源利用的角度来看，这也是一个相当大的问题。显然，在一定程度上。"挑战——测试、安全、监控。。当集装箱数量激增时，你必须准备好在scale@cobiacomm c9d9进行测试和监控pic.twitter.com/3o91O3gelk-CloudBees（@electricloud）2017年3月14日能够将数据聚合在一起以形成可操作的见解是一个挑战@phildougherty | c9d9#microservices#Dockerpic.twitter.com/7iCX8q5QG5-CloudBees（@electricloud）2017年3月14日相关性是关键，因此，当最终用户遇到问题时，我知道从何处开始@anders_wallgren'c9d9微服务pic.twitter.com/QhO1odZlV8-CloudBees（@electricloud）2017年3月14日不要从微服务开始，先从一个整体和一个代码库开始，然后从那里拆分@orfjackal c9d9容器pic.twitter.com/BCxidPLLfx-CloudBees（@electricloud）2017年3月14日格拉伯纳对监控进行了个人描述，"我认为，很明显，监控已经让我们看到了很大的变化。不仅是监视Docker容器的方式，我们如何进入其中，还包括我们如何处理数据以及如何理解容器之间的依赖关系。不仅从物理角度看，他们住在哪里，他们如何需要彼此的资源，还包括生活在那里的服务，它们如何进行端到端的通信，以及它们最终如何影响最重要的——使用服务基础的最终用户。这就是我们要解决的问题。"Haddad还利用了个人经验，"当容器数量激增时，必须准备好大规模应用测试、安全和监视。一个服务器和一个位置，或者一个虚拟机和一个位置，然后说：‘我想监视这一件事，我要伸手去拉那台机器获取所有的信息，所有的日志文件。’一个客户，他们的脑子就爆炸了。他们认为这是僵尸启示录，因为他们传统的监控工具是基于一种"伸出手，拉关系，拉关系"的心态。他们根本不知道这些容器在哪里。您不知道日志的数量，因此需要将日志推送到中央聚合器服务。"Riley在监控对话中补充道："当您开始在应用程序中部署服务，并且在不同的区域部署相同的服务时，即使每个区域只有少量的服务，问题是，它会变得很大，但并不是新问题。这一点都不新鲜。我的意思是，由于规模和数量的原因，这是一件大事，但我们有解决这个问题的工具。我认为，有些组织正陷入这样一个陷阱，即期望他们获得的工具，他们的监控工具只是为了突然带来魔力，而我认为这是使用人工智能这个术语的风险之一……你不只是为了构建仪表板而构建仪表盘。您可以构建仪表板以某种方式使用它。从某些方面来说，这是一个信息体系结构问题，从你的私人回购开始。我认为抱怨监视的组织都是那些拥有雪花配置和雪花图像的组织，他们不会把容器当作不可变的。能见度很早就开始了。这就是我的观点。我认为这是一个可以解决的办法。这是件大事。我知道有三家全新的供应商正在进行容器本机微服务本地监控。所以你知道市场在那里。"关于微服务的建议，至少从两年前就开始了。所以，先从一个整体开始，然后，如果你有最多10个人在同一个代码库中工作，那么开发起来会更快更容易。然后开始加速，你就需要开始做所有这些监控和网络工作，以及所有的重试。我听到的建议是测试您的系统对所有这些故障的恢复能力如何等等，使它能够随机复制消息或丢弃消息，并且您的系统应该能够安然无恙地生存下来。Dougherty进一步深入了解了安全性的重要性，"另一个问题是当涉及到容器的各个层时。。。幸运的是，我们有很多创业公司已经出来了，Docker自己也做了很多wo