微服务设计原则—

文章目录

1.ID生成
2.数值精度
3.DB操作
4.性能测试
5.版本兼容
- 5.1 向旧兼容
- 5.2 向新兼容
6.异步时序问题
7.并发问题
- 7.1 并发时序
- 7.2 并发数据竞争
参考文献

1.ID生成

在分布式系统中，生成全局唯一ID是非常重要的需求，因为需要确保不同节点、服务或实例在并发操作时不会生成相同的ID。

如无必要，ID 长度不要超过 128 字节。
使用业界成熟的 ID 生成方案，如 UUID (Universally Unique Identifier)，Snowflake 算法，数据库自增ID，基于 Redis 的分布式ID生成器，以及分布式唯一ID生成服务（Zookeeper 或 etcd）等，而不是自己实现。
如果一定要自己生成，使用基于“时间戳+机器ID+序列号”的组合而不是仅仅使用时间戳。因为在并发场景，同一时刻会产生相同的ID。注意序列号如果使用随机值可能会重复。

2.数值精度

数值精度问题在计算机科学中经常出现，尤其是在涉及浮点运算、金融计算或其他高精度要求的应用中。解决数值精度问题通常需要根据具体场景采取适当的策略。

【强制】使用 decimal 类型处理浮点数，可规避数值精度问题。
【强制】返回给前端的浮点数使用 stirng 类型表示。
【强制】在实现涉及数字精度处理的业务逻辑前，必须与需求方（如产品经理）确认需求的详细描述和业务背景，确保精度设计符合业务需求。
【强制】确定统一的数字精度处理标准（如统一使用四舍五入到两位小数）
【强制】增加精度相关的单元测试用例和接口测试用例，确保数字精度处理在各种场景下都能正确执行。特别是单测，可以构造遍历价格和数量涵盖业务99%使用场景的case。
【建议】整数代替浮点数：在货币计算等需要高精度的场景中，使用整数而非浮点数来表示数值。例如，用最小货币单位（如分）表示金额，以避免浮点数的精度误差。
【建议】合理的舍入策略，比如四舍五入：在进行浮点数计算时，可以使用四舍五入来减少累积误差。
【建议】浮点数对比结果小于某个极小的的浮点数即可视为相等。

3.DB操作

外部调用包括对外部系统的调用和基础组件的调用。它具有返回时间不确定的特性，必然会导致大事务。大的数据库事务，会造成其他客户端对数据库连接的请求获取不到，那么和这个数据库相关的所有服务都有可能处于等待状态，造成数据库连接池被打满，多个服务直接宕掉。

【强制】避免长事务，不要在 SQL 语句中进行网络调用「如果一定需要调用，设置网络总超时时间不能高于30ms,且拉起慎重评估」。
【强制】单表数据量过大或访问量过大（有高并发读写需求）时，要有分库分表的设计。
【强制】在涉及数据库操作时，必须检查正确使用事务管理。例如，确保事务开启、操作和提交的一致性。
【强制】编写高效的SQL查询，避免引入慢查询和不必要的连表查询。例如，使用索引。
【强制】对于大规模的数据操作，采用分批处理，避免一次性操作对系统性能的影响。
【强制】在涉及多个步骤的操作中，使用数据库事务，确保操作的原子性和一致性。
【强制】DB操作语句对关键字段（如条件字段）进行校验（如判空），并对不符合预期的字段进行告警监控。
【建议】将长事务分解为多个短事务，每个短事务处理一部分操作。这不仅能提高系统的并发性，还能减少单个事务的执行时间。例如：分阶段提交：将事务拆分为若干阶段，每个阶段提交一次。
【建议】使用缓存机制，减少数据库查询次数，提高系统性能。
【建议】在功能实现过程中，优先使用经过验证的工具、库或数据源。

4.性能测试

能测试是软件测试中的一个重要环节，特别是在开发和维护 Web 服务、API 和微服务时。进行接口性能测试有如下作用：

确保系统可用性：通过测试接口在高并发和长时间运行下的表现，确保系统能够在用户访问高峰期保持正常运行，避免崩溃和服务中断。
识别性能瓶颈：通过分析响应时间和资源使用情况，识别出影响接口性能的瓶颈，帮助开发团队进行针对性的优化，从而提升整体系统性能。
优化用户体验：快速的接口响应时间直接影响用户满意度，性能测试可以确保接口能够快速响应用户请求，提升用户体验，减少用户流失。

关于性能测试，一般遵循如下实践：

【强制】涉及性能要求的业务场景，技术方案中编写性能测试用例，约定好压测目标（如单机 QPS 和 P99）。
【强制】编码过程中，尽可能地将可并行的任务改为异步并行处理。选择适当的并发处理策略，如线程池、无锁算法、异步处理等，减少不必要的计算，提高请求响应效率。
【强制】开发完成后，执行压测，确保在系统上线前性能达到预期标准。
【建议】实现对系统性能的实时监控，及时发现和处理性能异常。配置性能异常告警，确保在性能指标超出阈值时，能够及时通知相关人员进行处理。
【建议】关注极端case下的时延，也就是长尾请求（可以用对冲策略来解决）。

5.版本兼容

5.1 向旧兼容

向旧兼容也称为向后兼容（Backward Compatibility），是指在软件系统或接口更新时，确保新版本的系统或接口能够正常运行旧版本的功能或与旧版本的客户端进行交互。向旧兼容性设计对于保持系统的稳定性和用户体验至关重要，尤其是在大规模分布式系统中，向旧兼容性可以防止新版本导致的业务中断或用户操作失败。

【强制】新增功能：在接口更新时，尽量以增加新功能的方式而不是修改或移除旧功能。
【强制】兼容的协议。设计协议时，允许接收端忽略无法识别的字段，而不是直接拒绝处理。比如新增协议字段，而不修改旧协议字段。
【强制】默认值支持：如果必须增加新的参数，确保它们具有合理的默认值，使旧版本的客户端无需更改即可继续使用。切记，默认值不要有业务含义。
【建议】版本控制：引入版本控制机制，如在API路径中包含版本号（如 /api/v1/resource），确保旧版本的客户端可以继续访问原有的API版本，而不会受到新版本更改的影响。