11、微服务开发：挑战与解决方案

微服务开发：挑战与解决方案

1. 共享库处理

微服务的原则是自治和自包含。为遵循此原则，有时可能需要复制代码和库，这些可以是技术库或功能组件。例如，航班升级资格在值机和登机时都会检查，如果值机和登机是两个不同的微服务，可能需要在两个服务中复制资格规则，这是添加依赖和代码复制之间的权衡。

嵌入代码比添加额外依赖更容易，因为它能实现更好的发布管理和性能，但这违背了DRY原则（每个知识片段在系统中必须有单一、明确、权威的表示）。这种方法的缺点是，若共享库出现错误或需要增强，必须在多个地方进行升级。不过，每个服务可以包含不同版本的共享库，所以这可能不是严重的挫折。

将共享库开发为另一个微服务本身需要仔细分析。如果从业务能力角度看它不符合微服务的标准，那么它可能会增加更多的复杂性而不是实用性。这里的权衡分析在于通信开销与在多个服务中复制库之间。

2. 微服务中的用户界面

微服务原则主张微服务是从数据库到表示层的垂直切片。但实际中，通常需要快速构建UI和移动应用来整合现有API，这在现代业务要求IT快速响应的场景中很常见。移动应用的普及是这种方法的原因之一，许多组织中有靠近业务团队的移动开发团队，他们通过组合和整合来自内部和外部多个来源的API来快速开发移动应用。在这种情况下，可以构建无头微服务，让移动团队构建表示层。

另一个问题是，业务可能希望构建针对特定社区的整合式Web应用。例如，开发针对机场用户的离港控制应用，它可能包含值机、贵宾室管理、登机等功能，这些功能可能被设计为独立的微服务，但从业务角度需要整合到一个Web应用中。此时，可以构建一个容器Web应用或占位符Web应用，它链接到后端的多个微服务。这种方法的一个优点是可以有多个针对