是时候进行“微服务检查”了吗？

如果您打算对当前的微服务实现进行自己的检查，则绝对应该阅读本篇文章了。

您的公司将从微服务实施审核中受益吗？

我们的许多客户当前正在使用基于“微服务”的架构来实现应用程序。我们越来越多地从公司迁移到微服务的过程中听到他们的声音，他们需要我们的帮助来验证和改进其当前解决方案。这些“微服务检查”项目揭示了一些有趣的模式，并且由于我们具有在广泛行业中工作的经验（并且在查看项目时也有“新鲜的眼睛”），因此我们经常能够与团队一起工作以进行重大改进，并为将来的改进制定战略路线图。

我们在下面总结了我们的发现，目的是在您考虑对自己当前的微服务实现进行检查时提供启发。

技术基础

2014年，Martin Fowler表示 成功实现微服务的 前提条件包括快速配置，基本监控和快速应用程序部署。OpenCredo团队在内部进行了长时间的讨论，我们不仅广泛同意该声明，而且在多个项目中也对此进行了验证。

快速配置

随着微服务平台，微服务兼容平台即服务（PaaS）和容器即服务（CaaS ）（ 如 Kubernetes，  Mesos 和 Docker  Datacenter ）的实现，快速配置在2016年变得不再那么重要了 。这些平台通常提供可将微服务部署到的计算资源的同质化池（或其他某种抽象化）。但是，某些公司选择部署到基础架构即服务（IaaS），例如Amazon Web Services  （AWS），  Google Cloud Platform提供的 服务。 （GCP）和Microsoft Azure，这里缺乏快速配置是导致开发和运营之间经常发生争执的原因。

作为微服务检查项目的一部分，我们通常会寻找警告信号，例如不可重复的构建，手动组装基础结构以及配置漂移（令人恐惧的“雪花服务器”）。OpenCredo的团队是容器技术和相关业务流程平台的支持者。我们也是HashiCorp工具的爱好者，并定期与Packer 和 Terraform一起工作（并为它们做贡献）  。尽管HashiCorp致力于争取世界统治，但我们当然意识到确实存在其他配置管理工具，并且我们与Ansible，  Puppet 和 Chef进行了大量合作 。

基本监控

监视微服务实现的能力确实至关重要。随着在应用程序中部署的服务数量的增加，交互的复杂性也 随之增加，因此，潜在的 突发行为成为现实（这是真正复杂的系统的标志）。作为微服务检查的一部分，我们寻找诸如未检测到的基础结构问题（例如磁盘空间用完），警报风暴（触发了太多警报以致无法知道问题的原因）和生产中断等问题。 。

我们定期与客户合作，以帮助集成和配置SaaS监视解决方案（例如 Datadog，  Sysdig 和 Ruxit），并且还与本地监视解决方案（例如 Prometheus）合作。我们也是合成交易 和关键烟雾测试的坚定支持者， 并且 为此目的使用了诸如JMeter 和 Serenity BDD之类的工具 。通常，当我们向项目经理和其他业务涉众展示此内容时，他们会想知道如何在不具有应用程序可见性的情况下进行管理！

快速的应用程序部署

快速应用程序部署的主题以及持续交付的相关主题 ，应有自己的博客文章。但是，在微服务检查的背景下，我们经常发现这是采用微服务的公司中大多数争执的原因。我们中的许多人习惯于使用诸如Jenkins，  Go CD 和 Spinnaker之类的持续集成和部署工具 ，但是当成功执行构建流程时，我们经常会看到公司内部出现问题。  一个团队中的成员应用于公司中的另一个团队。如果无法在整个公司中可靠且重复地部署构建，或者生产中断频繁，那么我们将进一步研究为可扩展的快速应用程序部署提供支持。通常，必须在技术和公司级别解决与该问题相关的问题。

我们看到的另一个常见模式是，最初的微服务实现或概念证明不与“传统”（赚钱）系统集成，因此，在这种情况下实现持续交付的痛苦并没有经历。我们经常与 SpectoLabs 团队合作解决此问题，因为他们在解决此问题（例如服务虚拟化 和 API仿真）方面拥有丰富的经验 。

不要忘记公司

对于那些使用微服务Bingo的人来说，这是您检查“ Conway法则”的地方。但是，正如我们在其他文章和演示中所讨论的那样，实际情况是 Conway在说实话……

公司设计与转型

当团队从概念验证阶段过渡到实施阶段时，通常会出现公司设计斗争的最初迹象。如上面“快速应用程序部署”部分所述，一旦实现扩展到一个团队之外，那么交互的复杂性就会增加。这通常在技术层面上具有挑战性，但在公司层面上几乎总是具有挑战性 。我们会寻找危险信号，例如工作队列，长时间的延迟或工作在公司中移动时出现的“信号中断”，以及团队朝不同的方向（或使用竞争技术）拉动。

我们已经 帮助多家公司 从开发团队到产品团队，再到管理层，回顾了他们当前的目标设定和公司结构方法。我们经常与公司内部的C * O级别一起工作，因为除非在此级别上达成一致和认可，否则公司其他部分进行的任何更改都可以轻松地解决。

“ DevOps”的重要性

尽管“ DevOps”一词  已经过分使用（但仍未 真正定义），但我们相信其背后的概念，例如（1）跨开发和运营共享理解和责任，（2）自动化，遵循原则驱动工具的实践，而不是相反的做法，以及（3）创建用于快速反馈的信号，对于微服务架构的成功至关重要。由于基于微服务的应用程序中的应用程序组件数量通常较高（与更传统的体系结构相比），我们经常看到问题迅速出现，团队无法达成目标，以多种不同方式解决同一问题。 货物养殖 自动化程度或对现成的“ DevOps工具”的错误使用；并且没有 情境意识。

DevOps的技术方面已经在本文中进行了介绍，但是与上一节关注公司设计的部分一样，DevOps的公司和人员方面同样重要（甚至更多）。我们已经看到DevOps的实施会在公司内部引起恐惧，我们也看到次优流程 是自动化的 （自动失败仍然是失败！）。根据我们的经验，我们开发了一些程序来协助 向“ DevOps” 工作方式的 转变。我们还认为，“ DevOps”运动背后的概念和目标对于更广泛的业务环境和当前的经济环境至关重要，在这些市场中，上市时间和创新速度是明显的竞争优势。

您能从第二双眼睛中受益吗？

正如老套话所说，在OpenCredo，没有两个项目是不一样的，因为我们为每个客户和项目量身定制了我们的服务。我们的目标是进行系统的更改，并提供尽可能多的知识转移，以使任何已实施的解决方案在长期内都是可持续的。话虽如此，我们已经在微服务的范围内确定了几大类，我们可以通过这些类别反复帮助客户。

整体到微服务评估

您现在应该迁移到微服务架构，还是从另一个解决方案中受益？通常，客户希望确保微服务能够解决可伸缩性和性能问题，而实际上，首先必须解决基础架构，设计和数据建模问题。

我们可以帮助您设计从 整体到微服务的 迁移策略。例如，我们可以帮助您回答以下问题：您应将现有功能提取到新服务中，首先应将哪些功能构建为微服务（以及如何对数据建模），以及如何将服务与遗留应用程序集成？

您是否需要有关公司如何确保为微服务实现做好准备的指南（从建立目标的战略一致性，实施最合适的公司结构到采用“ DevOps”哲学）？

业务和公司审查

您的团队是否了解  整个公司的价值流？OpenCredo帮助公司更好地了解了其 价值流图，然后帮助他们（通过实验）增强创新并减少了交货时间。

您的公司是否已对“影子IT ”感到不知所措？团队是否在创建微服务并将其部署到不同的平台？OpenCredo可以提供有关如何使IT走出阴影的指南。

员工是否积极 抵制变革？我们可以帮助您了解如何改善学习和沟通。

微服务平台/基础架构建议和指南。

您是否想利用PaaS解决方案，但不知道选择哪个？

您是否想将容器（Docker）引入基础架构堆栈，但是不确定如何实现，部署解决方案并使之 保持运行状态？

我们可以就Apache Mesos，  Kubernetes，  AWS ECS 和 Docker Datacenter等平台的优缺点提供指导 。

OpenCredo是编程基础架构和相关工具（例如HashiCorp  Terraform 和Packer，Ansible，Puppet和Chef）的专家。我们可以确保您在整个开发和运营团队中使用这些方法达到最佳效果。

持续交付微服务

我们可以帮助您 建立CI / CD管道 ，以支持从开发 到生产的快速交付经过测试和验证的应用程序组件 。

我们可以帮助您验证当前构建管道的有效性。例如，您是否必须同时部署多个服务以防止集成问题（可怕的“分布式整体”），还是您有多个手动测试验证门？