微服务架构强调服务的独立性，但实际开发中难免需要在多个服务间共享代码。合理的代码共享能提升开发效率、减少重复工作，同时避免破坏服务自治。以下是几种常见的代码共享方式：
1. 共享库（Shared Libraries）
将通用逻辑打包成独立的库（如 Java 的 JAR、Node.js 的 npm 包、Python 的 wheel），供多个微服务引入使用。
适用场景： 工具类方法（如日期处理、字符串校验） 通用客户端（如调用内部 API 的 SDK） 数据结构定义（如通用 DTO、枚举）注意版本管理，避免因升级共享库导致服务不兼容。建议采用语义化版本控制，并配合 CI/CD 自动化测试。
2. 领域模型或协议共享（Schema Sharing）
在服务间共享数据结构定义，比如通过 Protocol Buffers、OpenAPI 规范或 JSON Schema 定义接口契约。
优点： 确保服务间通信的数据格式一致 支持代码自动生成，减少手动编码错误 便于文档化和接口治理可将 schema 文件放在独立仓库中，由各服务引用并生成对应语言的代码。
3. 内部框架或基础组件封装
将共用的技术栈封装成内部框架，例如统一的日志格式、监控埋点、认证中间件等。
这种方式适合技术规范强的团队，能保证服务在可观测性、安全等方面保持一致。
需注意避免“胖框架”问题——框架过于复杂，反而限制了服务的灵活性。
4. 代码复制（Copy-Paste，谨慎使用）
对于极小的、稳定的通用代码（如一个简单的加密函数），直接复制到各服务中也是一种选择。
虽然违背 DRY 原则，但在某些场景下更简单可控，尤其适用于变化少、依赖弱的代码片段。
关键是要明确标识为“共享逻辑”，一旦需要变更，应有机制通知所有使用者。
基本上就这些。选择哪种方式，取决于团队规模、发布频率、技术栈一致性等因素。核心是平衡复用与解耦，避免因共享引入强耦合。
