如果你正在开发一个大型的、复杂的应用程序，或者正在拆除一个单体的应用程序，你应该考虑微服务架构。微服务架构将一个应用结构为一系列松散耦合的服务。微服务旨在通过实现持续交付和部署来加速软件开发。
在微服务下，有两种类型的项目。
- 棕地项目--它指的是在现有或遗留系统的背景下开发和部署一个新的软件系统。因此，将一个单体应用转换为微服务就属于这个项目。
- 绿地项目 - 这涉及到为一个全新的环境从头开始创建一个系统，没有任何遗留代码可供利用。当你从零开始，没有任何限制或依赖性时使用的一种方法。
按子领域模式分解
领域驱动设计（DDD）方法是一种建立复杂软件应用程序的方式，它是基于面向对象的领域模型的开发。DDD为每个子域定义了单独的领域模型。每个子域都属于一个领域。识别子域与识别业务能力的过程相同，即分析业务和识别专业领域。最有可能的是，最终的结果将是业务熟悉的子域。领域模型的范围在DDD中被称为有界上下文。有界上下文包括实现模型的代码工件。
子域可以分类如下
- 核心--企业最大的差异化因素，也是应用中最有价值的部分。
- 支持 - 不是一个差异化因素，但与企业提供的服务有关。通常是内部实施或外包。
- 通用 - 不针对业务，最好使用现成的软件来实施。
这种模式有以下好处
- 子域是相对稳定的，所以架构是稳定的。
- 我们的开发团队是跨职能的、自主的，并且专注于交付业务价值而不是技术功能。
- 服务是松散的耦合和内聚的。
将单体应用分解为微服务时面临的挑战
在分解单体应用时，可能会出现一些挑战。
- 网络延迟--在一个分布式系统中，网络延迟是一个持续的问题。你可能会发现，对服务的特定分解会导致两个服务之间出现大量的往返次数。
- 保持跨服务的数据一致性 - 每个服务都会有自己的数据库，所以保持跨服务的数据一致性会很困难。
- 上帝类--上帝类是控制系统中太多其他对象的对象，它超越了逻辑，成长为做所有事情的类。由于其规模和复杂性，它是一个集中了系统智能的类，并使用其他类的信息。
Strangler模式
当把传统的单体应用迁移到微服务架构中时，会使用Strangler模式。通过使用这种模式，单体应用可以通过用新的服务取代特定的功能而逐步转变。一旦新的服务准备就绪，旧的组件就会被扼杀，新的服务就会投入使用，而旧的组件就会退役。