我们的很多客户都在关注微服务，而我们经常被问到的一个流行问题是“你看到微服务最大的错误是什么？”。 我们已经看到了很多这种架构模式的好东西，但我们也看到了一些反复出现的问题和反模式。 去年，我们的姐妹公司OpenCredo的首席技术官Tareq Abedrabbo创建了一个题为“微软服务的七大罪”的精彩演讲（和博客文章）。 Tareq和我就他发现的反模式进行了一些引人入胜的讨论，这促使我创建了一个衍生产品，结合了Tareq的想法和帮助客户实现基于微服务的架构的经验。

介绍微服务的致命罪（redux）

我很幸运能够在QCon New York和Devoxx UK上发表这个新演讲，我很想分享演示文稿的概述幻灯片，以便开始讨论。 这是我的“七个致命的微服务罪”：

这些反模式究竟是什么？

让我们深入研究这七种反模式并提供更多解释：

1. LUST - 使用最新最好的技术(Using the latest and greatest tech)

在Container Solutions，我们当然不会羞于使用最新和最好的技术 - 事实上，这是我们的理念的核心。但是，我们总是与客户讨论如何使用最合适的技术来实现他们的目标，问题或用例。我们是Docker，Mesos和Terraform等技术的坚定支持者，我们知道它们可以为IT团队带来的价值，但我们努力与组织合作，帮助他们制定战略并推动支持应用程序所需的变革这项创新技术。

2. GLUTTONY - 过多的通信协议（Excessive communication protocols）

在技​​术选择的地方，我们经常会在大型组织中看到很多变化，而对于微服务，这种变化通常可以在通信协议中找到。这种反模式的解决方案是了解你的选择 - HTTP，ProtoBuffs，Thrift，AMQP，MQTT等 - 但是试图标准化使用一个同步和一个异步协议 - “不要金板，但要知道你的选择”

3. GREED - 您所有的服务都属于我们(All your service are belong to us)

“贪婪”的反模式围绕着对引入微服务的组织，人员和文化影响的讨论（暗示 - 这比大多数人欣赏的更大！）。我在OpenCredo博客文章“微服务背后的业务：探索组织，架构和运营挑战”中写了更多关于此的内容

4. SLOTH - 创建分布式但体 (Creating a distributed monolith）

在实现微服务时很容易变得懒惰，只要你不能独立部署服务，你所拥有的就是分布式整体。下面的幻灯片包含几个参考和链接，以避免这种情况进行探索，但核心原则是要注意您的服务边界和API。当我说'留意'时，我真的暗示你的设计和合同必须是可以自动验证和强制执行的！

5. WRATH - 当坏事发生时爆炸(Blowing up when bad things happen)

绝大多数微服务系统将作为分布式系统运行，因此我们必须尊重这一点（作为开发人员和运营商）。作为开发人员，我们需要采取防御性编码，并利用容错模式，例如超时，重试，断路器和隔板。迈克尔·尼加德的优秀“发布它！”一书应该是强制阅读，访问Netflix OSS工具Github存储库也应如此！作为运营商，我们需要接受共享理解和责任的“DevOps”心态，并花费大量时间开发和使用工具来支持我们的角色。 Adrian Cockcroft最近就一些关于监控微服务和容器的挑战提出了一些很好的指示。

6. ENVY - 共享的单域谬误（The shared single domain fallacy)

对于整体而言，开发单个共享域模型的概念通常是一个关键模式，因为这将在整个代码库中使用。但是，通过微服务，“有界上下文”的域驱动设计（DDD）原则已经变得流行，并支持我们正确封装我们的域模型

7.PRIDE - 在瞬间的世界中进行测试（Testing in the world of transience）

使用微服务进行测试很难 - 这只是一个事实。然而，艰难并不意味着不可能，因此我们需要创建新的工具和流程来支持快速变化，动荡和瞬态的测试。在我的演讲中，我引用了Toby Clemson在分享他的“微服务架构中的测试策略”方面所做的出色工作，但仍有许多工作要做。一段时间以来一直在创建微服务的许多组织都在争论测试微服务的唯一有效方法是生产，因为在合成的临时环境中无法预测系统的紧急行为。