如何在实践中将单体架构迁移到微服务

　　关于从单体(Monoliths)架构迁移到微服务架构的主题有一些很好的文章，单体架构的优点和缺点非常简单。不过可以了解其他事项——策略。构建单体是因为它们更容易上手。当系统已经投入生产时，微服务通常是出于需要而出现的。

　　但是，在决定何时进行迁移时会出现很多问题——例如如何确定服务的边界?如何验证微服务架构的自我修复特性?

　　这对于服务网格的分布式方面尤其具有挑战性。需要将应用程序视为它的一部分以便中断。本文的目标是保持在传统单体应用中所拥有的便利，同时避免与领域相关的紧密耦合。本文将概述一些在执行这一迁移时可以使用的实用方法。

　　决定

　　单体应该是一个模块组成的整体，所以可以很容易将其分解。人们有一个将单体称为“互连代码块”的误区，但情况远非如此。大多数单体应用程序使用现代编程语言(例如包和模块等)的功能来分离各个部分。模块化单体的各个部分之间的调用通过明确定义的接口或事件总线进行。支持单体应用程序的立场可能源于Java背景，因为Java特别适合大型单体应用程序。根据其架构、语言、问题域等，而拆分代码库的点将会完全不同。

　　如何在这方面做出客观的选择?何时是开始迁移到微服务的最佳时机?

　　微服务架构迁移最重要的前提是授权分离。如果不将其作为外部服务进行分离，则可能没有前进的空间。这是微服务迁移中最难的部分。这样做的好处是可以在保持单体架构的同时采取这一步。如果无法执行这一迁移，那么继续前进是没有意义的。完成这一操作之后，还涉及其他几个因素：

　　团队规模——随着团队的成长，保持凝聚力是一项挑战。这是可以通过审查团队的成长来轻松进行基准测试的部分。密切关注入职速度和其他指标，例如解决问题的时间。这些可能是衡量项目复杂性的最佳指标。

　　相互依赖——如果项目高度相互依赖并且没有明确的分隔线，那么微服务的好处可能会成为障碍。一些项目本质上是深度混合的，并且没有清晰地分离各个部分。要注意不同模块之间的事务完整性。事务管理等功能不能在微服务之间进行。如果用户有一个必须可靠一致的系统，例如需要始终保持一致的银行系统，则事务的边界必须位于单个服务中。这些类型的事情会使迁移过程变得特别困难。

　　测试——如果没有大量特定于模块的测试和大量集成测试，就无法进行这样的工作。审查测试代码将比任何其他方法更能了解准备情况。那么，在逻辑上能孤立地测试一个模块吗?

　　一旦对这些有所了解，就可以开始估计从单体应用到微服务迁移可能获得的好处。

　　从哪里开始?

　　假设单体代码已经相对模块化并且支持单点登录(SSO)，可以选择任何想要的模块。那么如何知道哪一个将在大量的时间和精力投入中获得最佳回报?

　　在理想情况下，用户希望定位那些能带来最大利益并且最容易迁移的部分：

　　查看问题跟踪器/版本控制——哪个模块最容易出现故障?

　　检查模块化——哪个模块最小且相互依赖最少?数据可以清晰地分离吗?最好从容易实现的目标开始。

　　分析应用程序——哪个模块最昂贵并且可以从扩展中受益?

　　这些事情在本地运行时非常简单，但应用程序在生产中的行为通常与其本地或暂存环境有很大不同。在这些情况下，可以使用开发人员可观察性工具(例如运行时行计数器)来评估使用情况。而在选择要突破的模块时，需要在利益和效用之间取得平衡。

　　避免微小的单体架构

　　微服务用户将继续构建不遵循一般规则的产品。“自我修复”就是最明显的例子。将单体应用程序解耦成微服务应用程序非常困难。需要隔离各个部分，并确保一切都在规模上合理运行。或者更糟糕的是在停机期间进行。

　　当可部署服务宕机时，系统如何生存?如何测试这样的产品?

　　这种架构的最大问题之一是部署规模。将单个服务打包在发现系统和API网关中，并使用断路器来启用修复属性。API网关和类似服务通常是基于SaaS的解决方案，但即使用户自己部署它们，准确地复制生产也很困难。典型的复杂性包括将URL编码到网关和实际代码中。意外绕过网关并直接访问服务器或底层基础设施。这些是在遗留代码和大型系统中难以检测到的微妙事物。

　　由于这种复杂的拓扑结构，在本地工作时几乎不可能正确测试愈合行为。由于部署工作大相径庭，得到的任何结果都是不准确的。

　　但是不能仅仅为了证明一个观点就关闭生产微服务。

　　这是微服务架构的巨大好处之一。在发现代码中，可以添加一个特例，为特定用户提供“虚拟”或失败的微服务。问题是这些症状可能很难验证，因为“自我修复”服务看起来好像正在运行。在这种情况下，可以使用日志或快照来验证代码是否正确，并且模块确实已经断开连接。

　　例如，可以使用大多数API网关来模拟API的不可用性。然后可以通过调用并验证断路器是否被触发，并且其结果仍然到达来检查其他服务是否按预期工作。系统似乎已经自我修复。但也许某些用户代码直接调用了Web服务并有效地绕过了API网关?如何验证缓存中的所有内容都正常工作，并使用预期的回退?

　　这就是日志和快照的来源。可以将它们添加到后端API以及断开的服务中，以验证得到的结果确实是来自网关缓存的结果。

　　冲洗-重复

　　当从单体应用程序中分离出第一个微服务时，这个过程最具挑战性。当打破额外的部分时，通常会变得更容易，直到单体都消失了。但在这一过程中也存在挑战。最初，选择一个更容易实现的目标。在前进的过程中遇到了更艰巨的挑战，需要为可能不太理想的服务确定边界。

　　问题是经常需要根据直觉采取这些步骤。但是当创建模块时，可能使用了逻辑分离而不是相互依赖。因此，两个模块可能具有深度依赖关系，并且作为微服务可能没有意义。将它们拆分到不同的位置，甚至将它们捆绑在一起可能更有意义。例如，可能有一个管理多个帐户的会计系统。逻辑分离可能会将在账户之间转移资金的代码移动到单独的模块中， 但这会使事情变得非常困难。在会计系统中，资金必须从一个帐户到达并转移到另一个帐户;它永远不会“消失”。当向一个帐户添加资金时，必须从另一个帐户中减去这些资金，并且两者都需要在一次交易中发生。一个简单的解决方法可能是在一个请求中同时进行扣除和资金转移。但是，这并不能解决一般性问题，因为可以从一个帐户中提取资金并分成多个帐户。在多个小型操作中执行这一操作可能会导致副作用。这是可行的，在这种情况下，会将核心会计逻辑与账户系统保持在一起。

　　其中一些相互依赖关系可以从代码中推断出来并重构掉，转换为消息传递和异步调用。使用消息服务是最有效的解耦方式之一，许多语言和平台支持各个部分之间的模块屏障。这可以将整个模块与应用程序的其余部分隔离开来，并将交互限制在一个狭窄的界面中。通过设置这样的障碍，可以使用编译器和IDE来强制执行模块限制。

　　结语

　　分解单体应用程序总是具有挑战性，而将业务逻辑隔离到正确的域中需要时间和精力。特定服务的通信开销和功能划分是在这样的过程中产生差异的组件。没有交付保证，测试更加困难。由于API网关、代理设置、发现等原因，生产环境与开发环境完全不同。

　　遗留代码的成功迁移对客户来说是无缝的，它完全改变了动态。交付不同，验证部署是否成功比使用单体应用程序更具挑战性。当一切正常时，用户体验是相似的，但是如何验证呢?

　　这就是工具的用武之地;可以使用开发人员的可观察性工具(日志、计数器、日志)来验证。即使生产失败，跨服务边界的修复仍然有效。但这绝非易事，因为松散耦合只是第一步。不同形式的故障期间的行为只能在生产中进行测试，毕意人们不想仅仅为了证明自己的观点是否正确而导致生产失败。