微服务的创建和管理最常见问题是什么?

Data

如果你不正确地划分责任，你就会遇到问题。将任何应用程序应用到分布式系统中。想想你可能会遇到的问题。管理数据和管理状态是许多人在管理有状态和无状态数据时遇到问题的地方。考虑事件驱动的命令和数据通信，以构建最好的体系结构。

1)状态管理和组件定义。如果崩溃和烧伤，您可以替换它，如果它是无状态的。

2)关注架构。如何拆分不同的组件。你可以增加复杂性而不是减少复杂性。

复杂性

任何考虑的团队都不应该介入，如果他们不清楚他们试图解决的问题的领域。微服务带来了大量的开销。随着时间的推移，它会得到回报，因为你有更多的组件。从一开始，一切都与开销有关。在确定自己需要微服务之前，避免使用微服务。当您为采用的每种语言选择堆栈、语言和数据库时，您需要开发样板代码和编制管理。如果您愿意为it生产做好准备，请仔细考虑。最终与数据的一致性也是如此。简单是最基本的事情要记住。简洁明了的api和逻辑，很容易让你的头脑去构建更复杂的应用程序和行为。

大多数传统组织都不得不移动传统的应用程序。这是一个多年的旅程。你不能停止支持单体系统。一次只做一次服务。您需要一个平台来运行这个整体并从中挖掘出功能。我们的目标是成为一个在边缘运行微服务的平台。我们使用一个虚拟机监控程序将一个整体搬到VM上，知道相同的平台可以支持Docker和VM。k8不太适合逐步过渡。

容器的一个问题是构建容器映像和发布到存储库的复杂性。这是一个开发人员过去并不担心的问题。微服务更难调试和故障排除。有这么多的微服务，很多移动部件。对单个微服务进行故障排除的能力并不像对传统的单片应用程序进行故障排除那么容易。您不能直接访问微服务。可能有很多复制品。对于开发人员来说，这是一个陡峭的学习曲线。

监控

三种类型:

1)对他们正在构建的系统的可见性和可观察性的渴望。当您希望系统在开发和生产中处于开箱即用状态时，能够使系统透明;

2)更大的企业和工程组织的迁移有强烈的愿望去理解最佳实践，需要更多的关于如何到达那里，陷阱和焦虑-标准化在哪里可以，在记录成功和失败的一边;

3)工程师的异花授粉——工程师们在工作，他们不得不绞尽脑汁，从零开始建造已经建成的东西。需要供应商和开源领导者对市场进行更多的教育。更多关于如何做事情的文档。

在不合适的时候尝试做微服务。我们如何让自动化和可观察性到位?我们如何测试我们的应用程序并获取数据以询问平台和应用程序，以及何时比较它们何时开始退化?可见性和向对应用程序开发人员负责的人公开。

2018年7月，我们调查了354名受访者，询问我们的用户在使用微服务架构时遇到了哪些挑战。对跨多个微服务的端到端流程缺乏可见性:59%的受访者。不明确的错误处理，导致在微服务之间的边界上出现未处理的错误:50%的应答者。从事不同微服务的团队之间的跨团队沟通:46%的受访者。使用不同的编程语言/使用不同的数据存储编写的复杂支持服务:38%。雇佣拥有合适技能的开发人员有困难:35%。由于大量服务导致的安全问题:30%。这些问题既有技术性的，也有组织性的。为了获得跨多个微服务的长时间运行流的可见性，并以自动化的方式处理错误，确保流在启动后总是结束，还不存在合适的工具。团队仍在研究如何在新的组织结构中有效地进行沟通，并试图找到具有微服务体系结构经验的合适人选。

技能

大多数人不理解将服务构建为细粒度的，并将其作为单个应用程序一起使用的重要性。当您将ESB(企业服务总线)分解为多个服务时，会遇到一系列挑战。主要的挑战是建立服务之间的通信并使其具有弹性。保证交付作为所选代码的一部分实现。您必须考虑如何使用分散的数据管理来管理数据。如何创建数据组合。通过整个网络支付的自主服务的总体监控和可观察性。需要使用观察工具。跟踪标准。如果你没有一个平台，你的企业文化也没有很好地结合起来，你就很难将微服务融入到产品中。无论你追求的是什么新项目，你都要把它作为一个微服务来做，而不是改变传统的应用程序。慢慢开始，逐步进入架构。

在构建、交付和管理微服务方面，存在很大的技能差距。很少有开发人员具备理解领域、从数据到API的服务编码、理解总体体系结构、与CI/CD管道集成以及交付运行中的服务所需的技能。用于低代码微服务创建和简化管理的工具对“ok”开发人员来说是一个巨大的提升，使他们在很少培训的情况下安全地提高速度，同时将“好的”开发人员变成摇滚明星。

安全

Discovery（发现）是最重要的。如何从安全角度发现微服务。它经历了所有你期望它经历的治理。编目微服务和高级api。创建微服务是一种商品。看看谷歌，“在10分钟内创建一个微服务的10个步骤”。

1)如果没有适当的治理，利用一个公开不应该公开的数据的服务，就可能变成蛮荒的西部。

2)数据安全。

3)发现管理。Swagger被认为有助于微服务管理。

其他

接口是什么?确保您没有破坏依赖关系。有哪些服务，以及如何访问它们?Kubernetes (K8s)和Istio都有帮助。要找到人们正在寻找的答案并不容易。不确定该问什么问题来解决这个问题。太早期阶段。

与IBM和Pivotal合作伙伴的客户不会直接看到问题。凯捷咨询公司和埃森哲公司在重组和架构方面看到了商机。企业在经历变革的过程中，建立了大量的支持结构。创造软件的艺术和科学。了解具有数字功能的软件如何增强您的产品以提供更好的体验。

最大的问题是沟通和所有权，因为一切都按照自己的计划进行。自动化将是下一个。如果没有自动化，如果你很难部署大的东西部署成百上千的小的东西如果没有自动化就无法完成。在分解系统之前，把自动化放在适当的位置。

我认为影响微服务的最大问题将是维护API兼容性。api成为一种“单向”契约。一旦它们被释放，它们可能需要无限期地得到支持，因为组织内外的任何人都可以使用它们。

服务注册和发现。今天部署应用程序意味着什么?如何维护业务“应用程序”中涉及的所有内容?