单体应用
单体应用（Monolith）是一个独立应用程序。它构建为单个单元，不仅负责特定的任务，还可以执行满足业务需求所需的每个步骤。
优点
以下是单体应用的一些优点：
- 易于开发或调试。
- 快速可靠的通信。
- 易于监控和测试。
- 支持ACID事务。
缺点
单体应用的一些常见缺点是：
- 随着代码库的增长，维护变得困难。
- 紧密耦合的应用程序，难以扩展。
- 需要使用特定技术栈。
- 每次更新时，都会重新部署整个应用程序。
- 可靠性降低，因为单个错误可能会导致整个系统崩溃。
- 难以扩展或采用新技术。
模块化的单体应用
模块化的单体应用（Modular Monolith ）是一种构建和部署单个应用程序（即单体应用部分）的方法，我们构建它的方式是将代码分解为独立的模块，用于应用程序中所需的每个功能。
这种方法减少了模块的依赖性，这样我们可以在不影响其他模块的情况下增强或更改模块。如果做得好，从长远来看，这确实是有益的，因为随着系统的增长，它降低了维护一个整体的复杂性。
微服务
微服务体系结构由一组小型、自治的服务组成，其中每个服务都是自包含的，并且应该在有界的上下文中实现单个业务功能。有界上下文是业务逻辑的自然划分，它提供了一个明确的边界，域模型存在于该边界内。
每个服务都有一个单独的代码库，可以由一个小型开发团队管理。服务可以独立部署，团队可以更新现有服务，而无需重新构建和部署整个应用程序。
服务负责保持自己的数据或外部状态（每个服务的数据库）。这与传统模型不同，传统模型中有单独的数据层处理数据持久性。
特点
微服务架构风格具有以下特点：
- 松散耦合（Loosely coupled:）：服务应该是松散耦合的，以便可以独立部署和扩展。这将使权力下放每个开发团队，从而使他们能够以最小的限制和操作依赖性更快地开发和部署。
- 小而专注（Small but focused）：它是指范围和责任，而不是大小，服务应该专注于特定的问题。一般来说，“它只做一件事，而且做得很好”。理想情况下，它们可以独立于底层架构。
- 为业务构建（Built for businesses）：微服务架构通常围绕业务能力和优先级进行组织。
- 弹性和容错（Resilience & Fault tolerance）：服务的设计应确保在发生故障或错误时仍能正常运行。在具有独立可部署服务的环境中，容错是最重要的。
- 高度可维护性（Highly maintainable）：服务应该易于维护和测试，无法维护的服务将被重写。
优点
以下是微服务架构的一些优点：
- 松散耦合的服务。
- 服务可以独立部署。
- 多个开发团队的高度敏捷性。
- 提高容错性和数据隔离。
- 更好的可扩展性，因为每个服务都可以独立扩展。
- 消除了对特定技术栈的长期依赖。
缺点
微服务架构带来了自己的一系列挑战：
- 分布式系统的复杂性。
- 测试更加困难。
- 维护成本高（单个服务器、数据库等）。
- 服务间通信有其自身的挑战。
- 数据完整性和一致性。
- 网络拥塞和延迟。
最佳实践
让我们讨论一些微服务最佳实践：
- 围绕业务领域建模服务。
- 服务应该具有松耦合和高功能内聚性。
- 隔离故障并使用弹性策略防止服务内的故障级联。
- 服务应该只通过设计良好的API进行通信。避免泄漏实现细节。
- 数据存储应为拥有数据的服务专用
- 避免服务之间的耦合。耦合的原因包括共享数据库模式和严格的通信协议。
- 分散一切。各个团队负责设计和建造服务。避免共享代码或数据架构。
- 通过使用熔断器快速失败，以实现容错。
- 确保API更改向后兼容。
陷阱
以下是微服务架构的一些常见陷阱：
- 服务边界不基于业务域。
- 低估了构建分布式系统的难度。
- 服务之间共享数据库或公共依赖。
- 缺乏业务一致性。
- 缺乏明确的所有权。
- 缺乏幂等性。
- 尝试在所有事物中用ACIS来代替BASE。
- 缺乏容错设计可能导致级联故障。
当心分布式单体应用
分布式单体应用是一个类似于微服务架构的系统，但其内部紧密耦合，就像一个单体应用程序。采用微服务架构有很多优点。但在开发时，我们很有可能最终得到一个分布式的单体应用。
我们的微服务如果具有以下特点，则它只是一个分布式单体应用：
- 需要低延迟通信。
- 服务不容易扩展。
- 服务之间存在依赖。
- 共享相同的资源，例如数据库。
- 紧密耦合系统。
使用微服务架构构建应用程序的主要原因之一是具有可扩展性。因此，微服务应该是具有松散耦合的服务，使每个服务都独立。分布式单体架构不具备这一点，导致大多数组件相互依赖，增加了设计复杂性。
微服务与面向服务架构（SOA）
你可能已经在互联网上看到了面向服务的架构（SOA），有时甚至可以与微服务互换，但它们彼此不同，这两种方法之间的主要区别在于范围。
面向服务架构（SOA）定义了一种通过服务接口使软件组件可重用的方法。这些接口利用公共通信标准，并专注于最大化应用程序服务的可重用性，而微服务被构建为各种最小的独立服务单元的集合，专注于团队自治和解耦。
为什么你不需要微服务
所以，你可能会想，单体应用似乎是一个坏主意，为什么会有人使用它？
嗯，这要看使用场景。虽然每种方法都有其优缺点，但建议在构建新系统时从整体开始。重要的是要理解，微服务不是万能的，而是解决组织问题。微服务体系结构不仅与技术有关，还与组织的优先级和团队有关。
在决定转向微服务架构之前，您需要问自己以下问题：
- “团队是否太大，无法在共享代码库上有效工作？”
- “有团队妨碍了其他团队吗？”
- “微服务是否为我们提供了明确的业务价值？”
- “我的业务是否成熟到可以使用微服务？”
- “我们当前的架构是否对我们的通信开销进行了限制？”
如果你的应用程序没必要分解为微服务，则不需要这样做。没有绝对必要将所有应用程序分解为微服务。
我们经常从 Netflix 等公司及其微服务的使用中获得灵感，但我们忽略了我们不是 Netflix 的事实。他们经历了大量的迭代和模型，然后才有了一个适合市场的解决方案，当他们确定并解决了他们试图解决的问题时，这种架构变得可以接受。
这就是为什么要深入了解你的业务是否真正需要微服务的原因。我想说的是，微服务是解决复杂问题的解决方案，如果你的业务没有复杂问题，你就不需要它们。
