微服务应该是可扩展的，并专注于单一的责任。每个自足的模块单元在一个更大的系统中处理一个特定的功能。一个大型应用程序由模块化组件或服务（如容器或无服务器计算）构建而成。
把微服务想象成一个由不同部门、预算和要求组成的企业。每年，这些要求都会根据公司的需求而改变。你的应用程序也不会随着时间的推移而面临同样的需求水平。可能有一些方面需要更多的需求，还有一些方面你需要更多的关注。在你的应用程序中也会需要发生不同程度的扩展。微服务允许你在不同的领域进行扩展和增长而不影响其他领域。而且它们可以独立扩展。
我们都记得编程中的单一责任原则。微服务也不例外。它们只需做好一件事。您还可以获得更好的弹性和容错性的固有好处。微服务架构旨在通过将故障振荡到单个服务来防止整个系统出现故障。如果出现特定故障，我们知道故障在哪里，并能在不影响其他任何事情的情况下解决它。
还有一个可发现的方面。通过使用像HashiCorp的Consul这样的服务网络解决方案，你会知道什么时候有新的服务上线，并有一个集中的系统，成为一个服务目录，定义这些服务做什么以及如何与它们沟通。
为什么你应该考虑微服务
- 更快的上市时间：微服务实现了单个组件的并行开发和部署，加速了整个开发过程，减少了交付新功能的时间。
- 提高可扩展性：微服务可以独立扩展，使企业可以更有效地分配资源，更有效地处理不同的工作负载或流量模式。
- 增强复原力：微服务的分散性降低了整个系统的故障风险，确保了持续的服务可用性和更好的整体系统可靠性。
- 灵活性和适应性：微服务使企业能够利用不同的技术和框架来实现不同的组件，从而更容易适应不断变化的要求或纳入新技术。
- 更容易维护和更新： 微服务的模块化设计简化了系统维护和更新，因为单个组件可以升级或替换而不影响整个系统。
微服务最佳实践
保持微服务的小型化、集中化，并负责单一的业务能力是至关重要的。这种方法允许你增加额外的功能，避免蔓延。然而，关于理想的规模并没有坚定的规则，因为它将根据具体的应用程序及其要求而变化。
您还需要确保设计时考虑到故障问题。虽然容错是运行多个服务和微服务的固有设计，但它还增加了额外的弹性，如重试机制、断路器和舱壁。想想为什么船上会有舱壁。有隔板是为了保证结构的完整性，但如果出现问题，隔板被关闭，船也不会沉没。许多基于事件的架构都使用所谓的死信队列。如果一条消息无法送达，它就会进入一个特定的队列，并在那里接受检查，以确定失败的原因。
微服务的设计应基于领域驱动的设计原则，即根据业务能力对服务进行建模，并使用通用语言来确保服务与业务需求相一致。领域驱动设计的重点是在对业务领域的深入理解基础上创建软件系统。它的原则有助于指导设计过程，确保软件与领域保持一致，并为业务提供价值。这些原则共同促进了对业务领域的深入理解，并帮助确保开发与业务需求和不断变化的需求保持紧密的联系。
以 API-优先的方法进行设计，并实施 API 网关，为促进微服务和第三方子系统之间的通信提供中心连接点。 API 网关可处理大部分路由选择，并负责授权、验证和速率限制。应用程序接口的设计模式对于微服务的模块化和可重用性至关重要。
这里有一些额外的微服务最佳实践：
- 自动化测试和部署：使用自动化工具测试和部署微服务，如持续集成和持续部署（CI/CD）管道，这可以减少错误的风险，确保服务得到快速和一致的部署。
- 使用容器化：容器化提供了一种轻量级和可移植的方式来打包和部署微服务。使用容器化可以帮助简化部署过程，提高应用程序的可扩展性和可移植性。
- 监控和观察： 微服务应该被监测和记录，以确保它们按预期执行，并识别任何问题或错误。日志聚合器和应用性能监控（APM）工具可以做到这一点。追踪提供了对通过分布式系统的数据流的洞察力。这三大支柱有助于提供端到端的性能可见性。
- 安全的服务：微服务应使用最佳实践，如认证、授权和加密，不要忘记容器安全！政策应强制执行哪些微服务可以与其他微服务对话，以减少整体攻击面！政策应该强制规定哪些微服务可以与其他服务对话，以减少整体攻击面。安全应该是任何设计的一部分，并在开发的所有阶段进行检查，从而使应用程序更加安全，并保护敏感数据。
注释