有关微服务的五个问题

在讨论应用程序开发对现有已开发应用程序的影响和过渡到微服务时，有五个问题以不同的形式不断出现。无论组织的大小如何，它们都是相同的，并且在组织向微服务体系结构发展的过程中，它们似乎成为稍后策略讨论的一部分。

1.“当一个整体被拆分为分布式服务（微服务），例如从内部调用到分布式REST API时，如何处理通信中的性能影响？”

该问题的基础是将现有的单体应用程序分解为微服务时（在可能的情况下）会发生什么，这方面存在不确定性。这里需要理解的是，拆分服务的目标是获得比API调用速度更高的部署速度。

将微服务从现有的整体中分离出来，允许在与应用程序开发团队分离的团队中隔离服务开发。该服务工程团队可以按自己的时间间隔进行操作，每周、每天甚至每小时部署变更。

对于未知的网络调用的代价是要权衡您整体的高度严格的部署需求，这种需求可能导致其部署间隔在2-3个月中产生波动。专业的微服务团队意味着对业务、竞争和安全需求的更快响应，使得更快的交付间隔成为可能。对于网络调用而言，同样重要的是检查这种新的分布式体系结构中网络调用的粒度。

2.“我们要如何利用像OpenShift这样的容器平台的优势来处理从整体使用中分离出来的、具有状态的服务？”

有状态的应用程序分为有两种类型：

构建使用内存状态或数据库状态的业务应用程序。

构建特定的数据库引擎，需要对底层磁盘的高性能（甚至是低级别）访问。

第一种是开发和部署云本地应用程序及其有状态组件的主流方式，同时仍然使用基于Kubernetes的OpenShift等容器平台来生成微服务。

第二种通常最好留给专门的供应商。这是因为这些类型的解决方案可以深入到维护操作系统内核本身的扩展。关注特定领域的业务价值并将其交付给客户更有意义。

3.“如何处理支持分布式服务的数据库，从而使状态成为整个系统中的单个状态视图？”

有很多方法可以处理您的整体状态，这通常与其数据库后端有关。在处理迁移到微服务时，有多种方法可供使用。

我们建议您考虑将状态和数据从单体应用程序集成到微服务架构中。它涵盖了将数据分发和集成到微服务中的关键要素。还提供了对提交、读取、更新和删除（CRUD）模式的理解，它包括对分布式系统中涉及的一致性模型的深入了解。

可供您参考的另一种方案是用于智能数据库更改数据捕获的开源工具Debezium。首先能够迁移到微服务，而无需进行上述的深入更改。您可以构造一些方法来捕获和更新对状态/数据的更改，特别是对您的微服务感兴趣的更改，而不需要更改底层数据结构。

4.“当生产中有许多与状态服务相关的数据源时，如何将主应用程序的状态从生产转移到测试环境？”

在微服务世界中，每个微服务的运作方式看起来就像它是组织外部的另一项业务的一部分。当您与企业之间建立业务关系时，微服务开发团队被迫维护一个强大的API并拥有自己的测试套件。我们必须意识到，好的微服务应该是一个黑匣子。

很少有外部业务合作伙伴拥有所有数据，而仅拥有测试所需的数据。同样的原则也适用于在组织中开发和维护微服务的内部团队。在这个新的世界中，测试往往会在生产中发生更多，这就是为什么我们看到诸如Istio这样的服务网格技术的价值的原因。

对您的解决方案进行进一步的改进，可以使用Debezium通过通用的Kafka主干来复制数据，匿名化数据并将其放置到各个独立的微服务开发团队（组织内部的业务合作伙伴）所需的位置。

5.“如何使用API网关或服务网格将应用程序迁移到更现代的工作方式？”

首先，让我们定位一下API管理是如何使用的，请记住，我们之前讨论过微服务开发团队独立的工作，就像企业对企业的合作伙伴一样。这些开发团队有一个API，它是他们特定微服务的前端。通过使用API管理工具，开发团队将其微服务API发布到其组织管理的API层中供使用。

与之相对的是服务网格技术，它关注的是微服务能够在其部署层中彼此通信。考虑诸如微服务发现，负载平衡，故障恢复，指标和监视之类的事情。服务网格以一种新颖的方式解决了分布式服务遇到的微服务内部挑战。

正如您所看到的，上面提到的每一种技术都可以发挥不同的作用，我们认为每一种技术都是成功的微服务策略的必要组成部分。

由于这些问题是基于在服务层现代化过程中与组织的交互，所以在您向交付应用程序的现代体系结构过渡时，这些问题既实际又相关。