现在每个人都在谈论微服务。 几乎每一次会议，会议和会议都不是没有什么微服务的故事，它们是什么，它们有多好，如何降低项目的复杂性等等。
所有这些报告的主要信息-微服务有助于摆脱项目的过度复杂性和复杂性。 但是，对于我来说，您根本无法摆脱复杂性，也无法重新制作项目，从而使所有事情一下子变得简单。 困难将从一个区域转移到另一个区域。
例如：有一个非常复杂的纠结的整体，我们将其分为几个服务，每个服务看起来很棒，任何人都可以弄清楚代码，但是环境会如何？ 复杂性在增长：这些是分布式事务，需要记录下来才能了解这是单个事务； 为每项服务添加CI / CD和交付； 交互方案变得不平凡。
我在报告中听到的最有争议的论文或陈述，我准备与之争论：
对于新的团队成员而言，进入整体项目的成本更高 。 出于某种原因，习惯上通过新开发人员开始执行任务的速度来评估加入项目的成本。 是的，他将很快在小型服务中解决该问题，并很快地发布任务（尤其是根据规范，“他们写了什么，然后我做了”）。
但是其他团队成员呢？
新的测试人员将处理集成模型。 测试服务是好的，但是除了测试服务合同之外，您还需要检查影响多个服务的业务流程。
刚开始，这位新分析师甚至可能会断头，直到他了解内部挑战的所有复杂性。
微服务使您可以更频繁地发布 。 微服务的细分速度更快，因为它们被分为几个并行任务，这些任务是并行开发和测试的，并且仅用于检查集成（不考虑分析时间）。
您也可以使用整体来完成此任务，这完全取决于任务的分解。 通常，一开始会有一项任务-创建常规功能（更正常规数据库或修改接口），然后每个人都会看到自己的子任务并提供测试。
并且企业支付的功能发布时间将是相同的。 仅当释放所有组件时，该功能才会关闭。 微服务可以解决99％的任务，但是在最后一个功能关闭之前，它们不会被投入战斗。
他们还没说什么
难度越来越大
使用微服务时，
基础架构很复杂 。 这是由于您需要支持的不是一个应用程序，而是许多服务。 有必要监视所有服务的性能，了解版本对服务的依赖性，具有用于组装服务和交付的CI / CD计划，以及用于响应服务故障的机制，以使其他所有功能都不会失效。
这似乎是简单的事情，在整体中我们必须做同样的事情。 仅在整体中，我们才在一个应用程序上工作，并且随着服务数量的增加，复杂性也在增加，这需要更高的技能来支持。
微服务增加了复杂性 -新的库，支持分布式事务的新功能，处理其他服务的错误，发送重复的请求，回滚事务。 在大多数情况下，这些机制将是常见的，大多数开发人员不会参与其中，而只会使用它们。
但是其中可能存在错误，必须纠正。 如果我们没有任何问题地进行维修，那么将变更部署到200-300服务上，将需要时间和开发控制措施。 而且，如果您需要使用更新的库来重建服务，甚至需要重做调用（它们已像这样固定，没有提供），那么所有这些都将变得很有趣。
巨石-不是一个大泥球
通常如何开始有关微服务的美好世界的故事？ “我们有一块巨石，那是一块坚实的泥土，里面的一切都是令人困惑和难以理解的，”加上他们将展示出可怕的景象。 整体已经变得令人恐惧，“您将工作不力，您的项目将变成整体”。
但是没有整体可以（并且应该）清晰，结构化，带有“良好”代码和文档，就像微服务项目可能会变成一个更大的污垢，如果您不参与开发流程并且不监控开发质量。
那该怎么用呢？
好问题，只有您可以回答。 因为只有您知道您决定什么业务问题，所以项目将是什么。 没有灵丹妙药，没有可以使用的理想架构，总会有“幸福”。
在整体和微服务中，请遵循文档并保持最新。 有文档总比没有文档好。
建立一个开发过程，在该过程中，代码质量只会提高（审查，单元测试）。 但是关于质量，您可以写整本书，这是一个单独的大话题的话题。
简单易懂的代码与微服务无关，该代码应该是先验的。
测试自动化也与代码质量有关。
自动化您可以自动化的一切-CI / CD。 可能存在很难放入CI / CD的技术堆栈，但是99％的组件/交付可以自动化。