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

Data

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

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

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

复杂性

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

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

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

监控

三种类型:

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

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