如何过渡到微服务架构

最新推荐文章于 2024-09-27 16:27:44 发布

cxu0262

最新推荐文章于 2024-09-27 16:27:44 发布

阅读量163

点赞数

文章标签：数据库大数据运维

获取完整的书

建议零售价$ 39.99

看见

至此，您知道什么是微服务以及它们如何工作。现在是时候深入探讨：即，如何过渡到微服务的非常关键的话题。

微服务过渡的需求

单一应用程序非常大（就代码行而言）且复杂（就功能相互依存关系，数据等而言），为地理区域中的数十万用户提供服务，并需要数名开发人员和IT工程师。整体应用程序可能类似于图1。

有时，即使具有所有这些特征，应用程序也可能一开始运行良好。就应用程序可伸缩性或性能而言，您可能不会遇到挑战。但是随着时间和使用情况的增加，将会出现问题，并且对于不同的应用程序，问题可能会有所不同。

[了解什么是微服务。 •然后学习如何构建微服务应用程序。 •最后，学习如何为您的微服务选择数据库。 | 通过InfoWorld的App Dev Report新闻通讯了解编程方面的热门话题。 ]

例如，对于云或Web应用程序，由于更多用户使用您的服务，您可能会遇到可伸缩性问题，或者由于构建时间较长和进行回归测试，可能会变得昂贵且难以发布常规的新更新。如图2所示，整体应用程序用户或开发人员可能会遇到右侧列出的一个或多个问题。

那时，向微服务的迁移听起来可能不仅仅只是一种时髦的想法。听起来像是救生员。过渡看起来类似于图3所示的应用程序。

那么，您如何进行此类更改？有两种可能的方案：

创建一个全新的应用程序。
转换或迁移已经存在的整体应用程序。

后一种情况的可能性更大，但是不管您当前的情况如何，都需要了解这两种情况的来龙去脉。

使用微服务创建新的应用程序

我从未见过许多从头开始构建基于微服务的应用程序的实际场景。通常，一个应用程序已经存在，而我从事的大多数应用程序更多是从单片架构过渡到微服务架构。在这些情况下，架构师和开发人员的意图一直是重用一些现有的实现。但是，随着技能在市场上变得越来越容易获得，并且已经发布了一些成功的实现，我们将看到更多从头开始构建基于微服务的应用程序的示例，因此探索这种情况当然值得。

假设您已经弄清了所有要求，并准备好将要构建的应用程序的体系结构设计。在开始时，您需要考虑许多常见的最佳实践，以下几节将介绍这些最佳实践。

组织准备

您必须问自己的第一个问题是您的组织是否已准备好过渡到微服务。这意味着组织的各个部门现在需要通过以下方式对构建和发布软件进行不同的思考：

团队结构。 整体式应用程序团队（如果有的话）需要分解成几个小型的高性能团队，这些团队了解微服务的最佳实践或接受过最佳实践的培训。如图3所示，新系统将由一组独立的服务组成，每个服务负责提供特定的服务。这是微服务范例的一个关键优势：它减少了通信开销，包括那些多次不间断的会议。应根据业务问题或他们要解决的领域来组织团队。这样一来，通信就成为遵循时间和遵循的一组标准/协议，以便这些微服务可以作为一个平台相互协作。
每个团队都必须准备独立于其他团队运作。他们应该是标准Scrum团队的大小；否则，沟通将再次成为问题。执行是关键，每个团队都应该能够满足不断变化的业务需求。
工具和培训。 关键需求之一是组织准备投资新工具和人员培训。在大多数情况下，现有的工具和流程将需要淘汰，并采用新的工具和流程。这将需要大量的资本投资，以及在雇用具有新技能的人员和对现有员工进行再培训方面的投资。从长远来看，如果决定采用微服务的权利是正确的，那么组织将看到节省并收回投资。

基于服务的方法

与单片应用程序不同，对于微服务，您需要采用基于服务的自我维持方法。将您的应用程序视为一堆松散耦合的服务，它们相互通信以提供完整的应用程序功能。必须将每个服务视为具有自己的生命周期的独立，独立的服务，可以由独立团队开发和维护。这些团队可以从各种技术中进行选择，包括最适合其服务需求的语言或数据库。

例如，对于一个电子商务站点，团队将编写一个具有内存数据库的完全独立的服务（如购物车微服务），并编写一个具有关系数据库的另一项服务（如订购微服务）。实际应用程序可能使用微服务来实现基本功能，例如身份验证，帐户，用户注册和通知，这些服务具有封装在API网关中的业务逻辑，该网关根据客户端和外部请求调用这些微服务。

提醒一下：微服务可能是由单个开发人员实现的小型服务，也可能是需要几个开发人员的复杂服务。对于微服务，大小无关紧要；这完全取决于服务必须提供的一项功能。

此时必须考虑的其他方面是伸缩性，性能和安全性。扩展需求可能会有所不同，并在每个微服务级别按需提供。应该在所有级别上考虑安全性，包括静态数据，进程间通信，动态数据等等。

进程间（服务到服务）通信

必须考虑的关键方面是安全性和通信协议。异步通信是必经之路，因为它可使所有请求保持在正常状态，并且不会长时间保留资源。

使用诸如RabbitMQ之类的消息总线可能被证明对这种通信是有益的。它很简单，每秒可以扩展到成千上万的消息。为了防止消息系统在出现故障时成为单点故障，必须正确设计消息总线以实现高可用性。其他选项包括ActiveMQ，这是另一个轻量级消息传递平台。

在此阶段，安全是关键。除了选择正确的通信协议之外，行业标准工具（例如AppDynamics）还可用于监视和基准化进程间通信。任何异常都必须自动报告给安全团队。

当有成千上万的微服务时，处理所有事情确实变得很复杂。我将在第3章中说明如何通过发现服务和API网关解决此类问题。

技术选择

过渡到微服务的最大优势是它使选择成为可能。每个团队都可以独立选择最适合给定微服务的语言，技术，数据库等。通常情况下，团队没有这种灵活性，因此请确保您不要忽略并错过机会。

即使团队正在处理多个微服务，也必须将每个微服务视为一个独立的服务，并且需要对其进行分析。在为每种微服务选择技术时，必须牢记可伸缩性，部署，构建时间，集成和插件的可操作性等。对于数据量较小但访问速度更快的微服务，内存数据库可能是最合适的，而其他数据库可能共享相同的关系数据库或NoSQL数据库。

实作

实施是关键阶段；这是所有培训和最佳实践知识都派上用场的地方。要记住的一些关键方面包括：

独立。 每个微服务都应具有自己的生命周期，并应高度自治。它需要在不依赖于其他微服务的情况下进行开发和维护。
源代码控制。 必须放置适当的版本控制系统，并且每个微服务都必须遵循标准。在存储库上进行标准化也是有帮助的，因为它可以确保所有团队使用相同的源代码控制。它在各个方面都提供了帮助，例如代码审查，可在一处轻松访问所有代码。从长远来看，将所有服务置于同一源代码管理上是有意义的。
环境。 所有不同的环境（例如开发，测试，阶段和生产）都必须妥善保护和自动化。这里的自动化包括构建过程。这样，可以按需集成代码，大部分时间是每天。尽管Jenkins被广泛使用，但是有几种可用的工具。 Jenkins是一个开源工具，可帮助实现包括持续集成和持续交付（CI / CD）在内的软件构建和发布过程自动化。
故障安全。 事情可能会出错，并且软件故障是不可避免的。在微服务开发中必须解决下游服务的处理失败。其他服务的故障必须在用户看不见的程度上达到正常水平。这包括管理服务响应时间（超时），处理下游服务的API更改以及限制自动重试的次数。

对于微服务，不要害羞通过使用复制和粘贴来重用代码，但是要在限制范围内做到。这可能会导致某些代码重复，但是比使用可能最终导致服务耦合的共享代码更好。在微服务中，您需要解耦，而不是紧密耦合。例如，您将编写代码以使用服务的输出响应。每当您从任何客户端调用相同的服务时，都可以复制此代码。重用代码的另一种方法是创建公共库。多个客户端可以使用同一个库，但是每个客户端应负责维护其库。

当您创建太多库并且每个客户端都维护不同版本时，有时可能会变得很有挑战。在这种情况下，您可能必须包括同一库的多个版本，并且由于向后兼容和类似的考虑，构建过程可能会变得困难。根据您的需要，您可以选择任何一种方式，只要您可以控制客户端的库和版本的数量，并对它们进行严格的处理即可。这无疑将使您免于大量代码重复。

鉴于微服务数量众多，调试问题可能会变得困难，因此您需要在此阶段进行某种检测。最佳实践之一是用唯一的请求ID标记每个请求并记录每个请求。这个唯一的ID标识了发起请求，并且每个服务都应将其传递给任何下游请求。

当您发现问题时，可以清楚地追溯日志并找出有问题的服务。如果建立集中式日志记录系统，此解决方案将是最有效的。所有服务都应以标准化格式将所有消息登录到此共享系统，以便团队可以根据需要从一个地方（从基础结构到应用程序）重播事件。值得关注的是用于集中式日志记录的共享库。市场上有几种理想的日志管理和聚合工具，例如ELK（ Elasticsearch ， Logstash ，Kibana）和Splunk 。