微服务中能付出什么, 得到什么
这篇文章目的是强调，只有当我们付出足够的努力来处理我们将要面对的组织和分布式计算问题时，才能获得微服务并从中受益。在后面的段落中，您将发现我们从真正的微服务中得到了什么，以及它们从我们这里得到了什么。您在这里不会找到任何具体的解决方案，而是对在使用微服务之前需要解决多少不同的、复杂的问题进行高级概述。
微服务体系结构的主要优点之一是每个微服务都是一个独立的单元。自治是什么意思?我们可以从很多角度来分析。
部署
首先，自主服务可以随意部署，独立于其他服务。提供自治的基本方法是清晰地分离业务功能，以便有界上下文不会泄漏到其他服务中，并创建紧密耦合。如果微服务是自治的，它可以具有高度的内聚性。内聚是一个源自物理的术语，在这种情况下，高内聚意味着应用程序的所有部分(用源代码表示)都是非常紧密地连接在一起的，它需要大量的能量来将一个东西与它分离。
自治也与技术有关。当然，在开发我们的应用程序时，您应该明智地选择技术，以便它们与公司的能力和策略保持一致。但是，您应该能够使用与其他服务不同的技术堆栈来创建应用程序。这意味着您不能用特定的技术绑定接口——您的API应该与技术无关。
数据管理
另外值得一提的是，微服务不仅仅是关于代码的——它们也是数据库。首先，每个微服务都需要管理自己使用的数据。其次，即使你很清楚地识别有界限的上下文，但你的一些服务使用的是同一个数据库(模式)你的应用程序仍然是耦合的，而且你无法独立部署它们，如果有数据库故障，所有的程序都将无法使用。
可伸缩性
扩展我们的应用程序有两个主要原因。第一个是因为我们想要更大的负荷。第二个是关于我们希望在失败时提供的弹性。在单片架构中，我们需要用所有的组件来扩展整个系统。通常令人痛苦的是，扩展一个整体的唯一方法是通过添加更多的CPU或内存进行垂直扩展。另一方面，有了微服务，我们就有了自主性，这使我们能够通过独立甚至自动地添加新节点来横向扩展应用程序。
弹性
我已经提到了弹性在前款规定的,但我需要添加,除了在单个服务的范围,提供弹性自治提供给我们机会去隔离特定服务中的问题和错误,所以其他的不受影响,因此,系统仍然可以工作。
组织文化
最后但并非最不重要的是，自治也与组织文化有关。每个微服务应该由一个敏捷团队管理和开发，该团队对整个生命周期承担全部责任。为了交付尽可能最好的软件，团队需要有能力决定团队中的人将如何工作。
你不免费得到它
权衡——它们无处不在。微服务可以给我们带来很多好处。下面您将找到一些东西，您需要提供这些东西，以便将您的体系结构称为微服务体系结构。
监控
当我们的系统由一个或几个节点上的单个应用程序组成时，您就可以很容易地找到日志文件并在出现任何问题时对它们进行检查。如果没有错误，但是用户的响应时间非常长，那么您可以对应用程序进行概要分析，并在一个地方查找瓶颈。在分布式环境中，事情变得很复杂。首先，有几十个应用程序在不同的节点上运行，每个节点上都有几个实例，这些实例通常是动态分配的，找到出错的地方是一项非常艰巨的任务。其次，如果不是你在日志中找到的错误，而是你的反应能力，那么发现错误就更糟糕了。因此，在微服务体系结构中，我们必须接受和处理系统监控方面的复杂性。
现在，您应该提供的第一件事是一个中央系统，它将聚合来自所有应用程序实例的日志，并使您能够在一个地方对它们进行分析。ELK栈就是一个很好的例子(Elasticsearch, loghide, Kibana)。其次，您还应该提供一个跟踪解决方案，以便您能够找出哪个请求导致了问题。在这个领域，一个很棒的解决方案示例是Spring Cloud Sleuth，它可以通过Zipkin轻松增强，它可以帮助您分析和可视化基础设施和延迟中的服务之间的依赖关系。使用这组工具，您可以很容易地发现系统的哪个部分造成了瓶颈。当我们讨论应用程序日志时，我们考虑查找已经发生的错误的源。在微服务体系结构中，对主机、cpu、内存、网络延迟、响应时间等的实时监控也是无价的。使用像Grafana +这样的工具并适当地配置应用程序，您可以轻松地可视化所有这些度量。设置适当的阈值，您可以触发警报并在真正糟糕的事情发生之前作出反应。
在微服务环境中，这似乎是可选的。有人可能会说“我可以在每个实例中搜索日志”。这需要一些时间，但我可以处理它。如果您有3个应用程序，那么它可能会起作用，但是如果您有很多这样的应用程序，那么您花在寻找问题上的时间将最终会损害您在微服务体系结构中获得的所有其他好处，因为它将是完全不可维护的。我们需要承认，在系统监视的环境中，微服务带来了很多复杂性，但这正是我们真正需要提供的。
持续交付
然而，微服务体系结构的另一个特性是，当您有小型的、独立的应用程序时，您可以更快地提供更改，并且与单片方法相比，它们对整个系统的影响要小得多。这意味着，在开发特性时，您应该随时准备部署这些特性。实现这一点的第一步是使用所谓的持续集成，以便您在代码库中提供的每一个更改都自动地在已有版本的完整性方面得到验证——您的代码编译了吗?你的考试通过了吗?静态代码分析结果是正数吗?这些和可能更多的条件在您的构建管道中被检查。这是持续交付的基础。通过交付，我的意思是生产一些工件，这是一个潜在的候选版本，可以安全地部署到生产上。它可能是.jar文件，或者更特定于平台的生物，例如docker映像。原因是，在微服务体系结构中，我们需要快速响应更改，并在将代码推送到存储库之后立即部署它们。
当然，有时将我们的更改部署到生产中并不容易。可能会有一些规定和流程包含一些手工工作,如用户验收测试,或者单击“部署”按钮由某人负责,但这不是它应该的样子,如何开发团队应该是一个负责的公司的一部分的服务在他们的整个生命周期。在开发人员、测试人员和负责人之间划一条界线是不健康的，但是在交付方面，我们——开发人员应该做好准备。
结论
微服务已经流行了好几年，这是有充分理由的。涉及组织文化、技术、部署、数据管理、可伸缩性和弹性的自治给技术人员和业务人员带来了很多价值，但同时，实现它需要付出很多努力。服务发现、负载平衡、故障设计、监视、持续交付是我们需要的基础，而且它毕竟不是那么便宜。在使用微服务之前，我们需要知道所有这些事情。我希望在阅读本文之后，您能够自信地说，您的基础架构是提供完整的微服务自治，还是您只有另一个分布式系统。