有关云可移植性的三个考量：二微服务架构

微服务应该是可扩展的，并且是专注于单一职能的，由每个自包含的模块化单元负责处理一个更大规模系统中的一个特定功能，而大型应用程序往往就可以由这种模块化的组件或服务（如容器或无服务器计算）构建而成。

我们可以将微服务看作由不同部门、预算和要求组成的业务。每年，这些要求都会根据公司需求的变化而变。随着时间推移，我们的应用程序也会面对不断变化的要求，其中的某些方面可能会产生更多需求，有些方面则需要我们投入更多关注。此外，应用程序中的不同方面可能还需要进行不同程度的扩展或缩放。微服务可以帮助我们在不影响其他方面的情况下，以独立的方式对应用程序中的某些方面进行缩放或扩展。

相信大家都还记得编程领域所谓的“单一职责原则”（Single responsibility principle）。微服务在这方面也是一样的。微服务应该只负责做一件事，并且做好这件事。当然，通过使用微服务，我们还能在弹性和容错能力方面获得一些固有的好处。微服务架构旨在通过将故障约束到单个服务来防止出现影响整个系统的故障。如果出现特定故障，我们将知道故障位于哪里，并能在不影响其他东西的情况下解决这种故障。

另外还要注意可发现（Discoverable）问题。通过使用诸如HashiCorp的Consul这种服务网络解决方案，我们将能知道新服务何时上线，并能使用一个集中的系统充当服务目录，从而定义这些服务的用途以及服务之间的通信方式。

为何使用微服务

• 更快的上市时间：微服务可以并行开发和部署多个组件，从而加速整体开发流程，缩短交付新功能所需的时间。
• 提高可扩展性：微服务可以独立扩展，从而让企业更高效地分配资源，同时更高效地处理不同工作负载或流量模式。
• 增强弹性：微服务去中心化的本质特性降低了系统范围内故障的风险，保证了持续的服务可用性以及更高的系统整体可靠性。
• 灵活性和适应性：微服务可以让企业为不同组件使用不同技术和框架，从而更容易适应不断变化的需求或融入新技术。
• 简化维护和更新：微服务的模块化设计简化了系统的维护和更新，因为每个组件都可以在不影响整体系统的前提下单独升级或替换。

微服务最佳实践

保持微服务规模小巧、专注于负责单一业务能力，这一点至关重要。这样我们才能轻松添加额外的功能并避免蔓延。然而，每个微服务的理想规模是多少，这并没有什么明确标准，这需要我们根据具体应用及实际需求来决定。

我们还需要针对失败进行相关设计。虽然多个服务和微服务运行过程中，按照设计本身就具备与生俱来的容错能力，但额外的设计可以增加额外的弹性，例如重试机制、断路器以及隔板。想象一下船舶为什么会安装隔板。这些隔板可以保证船舶的结构完整性，而如果船舱漏水，隔板关闭，也可以保证船不会沉没。很多基于事件驱动的架构使用了一种所谓的死信队列（Dead letter queue），如果某条消息无法传递，就会被放入一个特殊的队列，接下来就可以检查该队列中的消息来确定失败原因。

微服务应该围绕领域驱动（Domain-driven）的设计原则来设计，这意味着要基于业务能力对服务建模，并使用通用语言来保障服务符合业务需求。领域驱动的设计侧重于围绕对业务的深入理解来打造软件系统，其原则有助于指导设计过程，确保软件与领域保持一致且能为业务提供价值。这些原则共同促进了对业务领域的深入理解，有助于确保开发工作能与业务需求和不断变化的要求紧密契合。

采取以API为先的方法进行设计并实现API网关，借此即可提供中央连接点，从而促进微服务和第三方子系统之间的通信。API网关负责处理大部分路由工作，以及身份验证、认证、速率限制等工作。API的设计模式对于微服务的模块化和可复用能力至关重要。

此外对于微服务，还有下列这些最佳实践：

• 自动化测试和部署：使用持续集成和持续部署（CI/CD）管道等自动化工具测试和部署微服务，从而降低错误风险，确保以快速、一致的方式部署服务。
• 使用容器：容器提供了一种轻量级、可移植的方式来打包和部署微服务。使用容器有助于简化部署流程，改善应用程序的可扩展性和可移植性。
• 监视和观察：微服务需要不断监视和记录，以确保按照预期运行，并及时发现存在的问题或错误。日志聚合器和应用程序性能监视（APM）工具可以帮助我们做到这一切。通过跟踪，我们还可以进一步了解分布式系统中的数据流。这三大能力有助于针对性能获得端到端的可见性。
• 保护服务：应通过身份验证、认证授权、加密等最佳实践措施保护微服务的安全，当然，容器本身的安全性也不容忽略！为减小整体攻击面，我们应该通过强制执行的策略来定义微服务能与其他服务通信的内容。安全性应该成为所有设计工作的一部分，并且需要在开发过程的每个阶段进行彻底的检查，这样才能获得更安全的应用程序，并妥善保护敏感数据。