微服务设计原则——功能设计

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版本，而不会受到新版本更改的影响。

5.2 向新兼容

向新兼容也称为向前兼容（Forward Compatibility），是指指系统、接口或协议在设计时考虑到未来的版本更新，使得当前版本能够与未来的版本兼容。这意味着即使未来的版本发生变化，当前的系统或客户端仍然能够正确地理解或处理这些变化，而不需要进行重大修改。

• 【强制】兼容上游扩展。账户类型、品类、字段取值等，自身服务需要做到兼容，并在非法输入时，编写防御性代码来处理这些情况，做好容错。
• 【建议】兼容性字段：在数据库设计中保留一些扩展字段或列，用于未来可能的功能扩展。

6.异步时序问题

异步时序问题是指在异步编程或系统设计中，由于事件、任务或消息的执行顺序和时间不确定，可能导致意外行为或错误的情况。这种问题在分布式系统、并发编程、异步操作等场景中尤为常见。理解并解决异步时序问题是确保系统正确性、稳定性和一致性的重要步骤。

• 【强制】梳理清晰的依赖关系：在设计异步任务时，明确任务之间的依赖关系，保证任务处理的正确性。
• 【强制】监控与日志记录：在异步系统中，设置详尽的监控和日志记录，及时发现并排查时序问题。
• 【建议】防御性编程：设计系统时假设异步任务可能以任何顺序执行，并编写防御性代码来处理这些情况。
• 【建议】异步任务测试：通过并发测试工具和方法，模拟异步任务的并发执行，提早发现可能的时序问题。

异步时序问题在并发和分布式系统中是一个复杂且常见的问题。通过合理使用同步机制、原子操作、事件驱动模型、事务处理、消息传递等手段，可以有效避免和解决这些问题。同时，清晰的设计、充足的测试和监控也在防止和诊断时序问题中起到至关重要的作用。

7.并发问题

7.1 并发时序

并发时序问题是指在多线程或并发系统中，由于不同线程或任务的执行顺序和时间不可预测，可能导致程序的行为异常或产生错误的情况。与异步时序问题类似，并发时序问题同样涉及到任务的顺序执行，但它们更多地发生在共享资源和状态之间的竞争上。

• 【强制】梳理清晰的依赖关系：在并发处理时，明确任务之间的依赖关系，保证任务处理的正确性。
• 【强制】并发场景，对依赖条件进行检测，满足后才能继续后面的操作。
• 【建议】并发任务测试：通过并发测试工具和方法，模拟异步任务的并发执行，提早发现可能的时序问题。

7.2 并发数据竞争

并发数据竞争问题是指当多个线程或进程在没有正确同步的情况下，同时访问和修改共享数据时，可能导致程序的运行结果不确定，或者出现意外的行为。这种问题通常在并发编程中发生，需要特殊注意。

• 【强制】并发编程需要注意哪些有关临界资源的访问问题，可适当使用锁来保证共享资源的互斥访问。
• 【建议】避免数据竞争。通过减少或消除共享状态来避免数据竞争。例如，使用无状态的操作，或者将状态局限在单一线程内，避免在多个线程之间共享数据。
• 【建议】检测与调试数据竞争。许多编译器和开发工具提供静态分析功能，可以在编译时检测潜在的数据竞争问题。比如 Golang 的 go race 检测数据竞争。

---

参考文献