揭秘开发巨系统时的设计问题：如何保证系统的健壮性和可扩展性？

大家好，我是小米，一个热爱技术分享的程序员。我今天想和大家聊一聊关于系统设计中的一些问题，这些问题都是我在公司开发“巨系统”中遇到的。

我们的系统最初是一个简单的电商平台，但随着业务的发展，我们不得不将系统拆分为统一订单系统、统一会员系统、货源系统等多个平台组成的一个复杂的系统，我将其称为“巨系统”。然而，由于业务增长迅速，我们的技术部门需要进行“敏捷开发”，在时间和任务的压力下，我们可能会忽视系统的健壮性和可扩展性，甚至忘记了设计模式的五大基础原则（SOLID）。

我曾多次和架构师发哥沟通这个问题，并提出了一些关于系统设计的“警告”和“风险”。今天我想和大家分享一下其中的一些问题，特别是货源系统和分销系统的设计问题。

假适配器模式的货源

货源系统对接多个采购平台，丰富电商平台的商品。我的理解是，货源系统就像设计模式中的适配器模式，它可以在内部处理不同货源的数据、字段等不一样的兼容性，以确保电商平台不必关心货源的具体细节，只需要关心是哪种货源、是哪种商品类型。

但是，我们接收货源系统的两个供应商时，他们告诉我们：“商品ID在A货源是字符类型，在B货源是数字类型，你们的电商平台需要处理一下。”当时我很震惊，“这不是你们货源系统的责任吗？”但是对方告诉我，其他系统对接他们的货源也是这样的。

这个问题让我意识到，设计系统就像写代码一样，时时刻刻提醒自己“高内聚，低耦合”，保持代码的纯粹性。你现在的“省事”是为系统埋了一个“雷”，不要为了眼前的“省事”和“时间”而让后期“费事费时间”。

不守规矩的分销

分销系统的设计是为了统一管理分销员、商品和佣金计算等，电商平台需要在用户登录、分销商品和下单时访问分销系统，计算佣金，最终通过分销系统发放佣金并提现。

在测试过程中，我们发现，测试人员购买分销商品下单后，始终没有分销金额。经过开发人员的排查，发现分销商品下单时存储的分销员ID是统一会员系统的会员ID，而分销系统的会员ID却是分销系统自己设计的ID，没有采用统一会员系统的ID，导致分销系统无法正确地计算佣金。

这个问题也让我意识到，在系统设计中，需要考虑各个模块之间的协作和依赖，尤其是在分布式系统中更加重要。不同模块之间的数据传输和格式必须保持一致性，否则会导致无法正确地传递数据，从而影响整个系统的运行。

此外，在系统设计中，还需要考虑到系统的可扩展性和容错性。当系统面临高并发、大数据量等情况时，必须考虑采用分布式、缓存、负载均衡等技术手段，以保证系统的高可用性和稳定性。

总结

总之，系统设计是一个需要细心和耐心的过程。在设计系统时，需要考虑到各个模块之间的协作和依赖关系，遵循设计模式的五大基础原则（SOLID），保持代码的纯粹性和高内聚、低耦合，同时考虑系统的可扩展性和容错性。只有这样，才能设计出高效、稳定、可靠的系统。

END

如有疑问或者更多的技术分享，欢迎关注我的微信公众号“知其然亦知其所以然”！