通用技术服务：独立实现还是抽象？边界如何定义？

在技术架构设计中，是否为每个业务服务都独立实现用户鉴权、文件上传、消息通知等基础能力，还是将其抽象成独立的通用服务，是一个常见的权衡问题。

独立实现 vs. 通用服务：

• 独立实现：

  • 优点：
    • 简单直接： 每个服务独立维护自己的逻辑，易于理解和调试。
    • 灵活定制： 可以根据每个服务的具体需求进行定制，不受通用服务的限制。
    • 隔离性好： 一个服务的修改不会影响其他服务。
  • 缺点：
    • 重复代码： 存在大量重复代码，增加维护成本。
    • 一致性问题： 难以保证各个服务之间的一致性，例如用户鉴权逻辑不一致。
    • 资源浪费： 每个服务都需要独立的资源来运行这些基础能力。

• 通用服务：

  • 优点：
    • 减少重复代码： 避免了大量重复代码，降低维护成本。
    • 提高一致性： 保证各个服务之间的一致性，例如统一的用户鉴权逻辑。
    • 资源利用率高： 多个服务共享通用服务，提高资源利用率。
  • 缺点：
    • 复杂性增加： 通用服务的设计和维护更加复杂。
    • 依赖性增加： 一个通用服务的故障会影响到所有依赖它的服务。
    • 定制性降低： 难以满足所有服务的个性化需求。

通用服务的边界定义：

通用服务的关键在于边界的定义，避免其演变成新的单体应用。以下是一些建议：

1. 单一职责原则： 每个通用服务只负责一个明确的职责，例如用户鉴权服务只负责用户身份验证和授权，文件上传服务只负责文件上传和存储。
2. 微服务架构： 将通用服务拆分成更小的微服务，每个微服务负责一个更细粒度的功能。例如，用户鉴权服务可以拆分成身份验证服务、授权服务、会话管理服务等。
3. 接口标准化： 定义清晰、标准的接口，方便各个业务服务调用。可以使用RESTful API、GraphQL等技术。
4. 数据隔离： 通用服务不应该直接访问业务服务的数据，而是通过API进行交互。
5. 可配置性： 提供一定的可配置性，允许业务服务根据自身需求进行定制。例如，用户鉴权服务可以支持不同的认证方式。
6. 版本控制： 对通用服务进行版本控制，方便业务服务进行升级和回滚。
7. 监控和告警： 建立完善的监控和告警机制，及时发现和解决问题。

建议：

对于用户鉴权、文件上传、消息通知等基础能力，建议抽象成独立的通用服务。但是，在设计通用服务时，需要严格控制其边界，避免其演变成新的单体应用。可以采用微服务架构、接口标准化、数据隔离等技术来保证通用服务的灵活性和可维护性。

在初期，可以先为每个业务服务独立实现这些基础能力，然后逐步将其抽象成通用服务。这样可以降低初期开发的复杂性，并更好地了解各个业务服务的具体需求。