本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 按抽象模式分支
<a name="branch-by-abstraction"></a>

当您能在单体周边拦截调用时，Strangler fig 模式效果很好。但是，如果您想对存在于遗留应用程序堆栈中更深层次且具有上游依赖关系的组件进行现代化改造，我们建议按抽象模式分支。这种模式使您能够对现有代码库进行更改，以允许现代化版本与旧版本安全共存，而不会造成中断。

要成功使用抽象分支模式，请按照以下过程操作：

1. 识别具有上游依赖关系的单体组件。

1. 创建一个抽象层，用于表示待现代化的代码与其客户端之间的交互。

1. 抽象到位后，将现有客户端更改为使用新的抽象。

1. 在单体结构之外使用经过重新设计的功能，创建新的抽象实现。

1. 准备就绪后，将抽象切换到新的实现。

1. 当新的实现为用户提供了所有必需功能并且不再使用单体架构时，请清理旧的实现。

抽象分支模式经常与[功能切换](http://martinfowler.com/bliki/FeatureToggle.html)混淆，后者还允许您逐步更改系统。不同之处在于，功能切换旨在允许开发新功能，并在系统运行时保持这些功能对用户不可见。因此，在部署时或运行时系统使用功能切换来选择特定功能或一组功能在应用程序中是否可见。抽象分支是一种开发技术，可以与功能切换结合使用，以便在新旧抽象之间切换。

下表说明了按抽象模式使用分支的优势和劣势。


****  

| 优点 | 缺点 | 
| --- | --- | 
|  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/modernization-decomposing-monoliths/branch-by-abstraction.html)  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/modernization-decomposing-monoliths/branch-by-abstraction.html)  | 

下图显示了保险单体中*通知*组件的分支抽象模式。它首先为通知功能创建摘要或接口。以较小的增量更改现有客户端，以使用新的抽象。这可能需要在代码库中搜索与*通知*组件 APIs 相关的调用。您可以将通知功能的新实现作为单体架构之外的微服务进行创建，并将其托管在现代化的架构中。在您的单体中，您新创建的抽象接口充当代理并调用新的实现。您可以将通知功能移植到新的实现中，在经过全面测试并准备就绪之前，新实现将保持非活动状态。当新的实现准备就绪时，您可以切换抽象来使用它。您需要使用一种可以轻松切换的切换机制（例如功能切换），这样在遇到任何问题时可以轻松切换回旧功能。当新的实现开始向用户提供所有通知功能并且不再使用单体时，您可以清理较旧的实现并删除可能已实现的任何切换功能标志

![\[通过抽象模式使用分支将单体分解为微服务\]](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/modernization-decomposing-monoliths/images/branch-by-abstraction.png)