电子商务前端交易系统的设计原则

我个人认为设计系统需要根据时间而有所不同. 一个系统不能一次完美地设计. 在资源有限的情况下，它必须首先解决当前的核心问题并预测/发现可能的未来问题. ，逐步解决最痛苦的问题. 也就是说，系统设计是一个连续迭代的过程，在迭代过程中发现并修复了问题. 也就是说，满足需求的系统会不断进行迭代优化，而架构却不是一次完美. 这是一个连续的过程，个人不相信结构完美的银弹. 但是，如果一开始就具有良好的基础系统设计，将来将更容易实现更令人满意的目标.

在设计系统时应更多考虑墨菲定律:

1. 没有什么比表面上看起来的要简单；

2. 一切将花费比您预期更长的时间；

3. 出错的地方总会出错；

4. 如果您担心正在发生的事情，那么更有可能发生.

但是，我们还必须考虑80/20规则. 在系统设计的初期，我们将有限的资源用于刀片的边缘. 我们的目标是满足系统的当前需求并支持未来的需求.

在持续的系统开发过程中，前辈们还总结了许多设计原则/经验；我个人很幸运能够使用一些经验/原理. 在系统开发或演进的早期阶段，根据系统的特性使用设计原则. 如果一开始不是核心问题，请不要使系统设计复杂化.

在系统设计的早期阶段，需要权衡制作一个完整的大型系统还是按功能划分系统. 例如，当私立学校时，用户/交易的数量将不会特别大，并且发展将由我自己决定. 在资源有限的情况下，无需拆分系统（例如拆分商品，订单等），仅需构建一个大型而完整的系统即可. 例如，在设计JD尖峰系统时，预计一旦启动JD尖峰系统，其数量将非常大，并且投入的资源仍然足够. 在这种情况下，有必要考虑按功能划分系统.

我遇到的分裂主要包括以下情况:

系统维度: 根据系统功能/业务划分，例如商品系统，购物车，结算，订单系统等；

功能维度: 系统的功能进一步细分电商交易管理系统，例如优惠券系统，可以分为后台优惠券创建系统，优惠券收集系统，优惠券系统等；

读写维度: 根据读写比例的比例来划分，例如商品系统，每个交易系统都会读取，读取大于写入，因此可以划分为: 商品写服务，商品读服务；读取服务可以考虑完全缓存以提高性能；例如，如果写入量太大，则需要考虑子和子表；有一些聚合读取方案，例如产品详细信息页面，请考虑数据异构拆分系统，它将分散在多个位置的数据分散存储到一个位置，以提高读取性能和可靠性；

AOP维度: 根据访问特性，根据AOP进行划分. 例如，产品详细信息页面可以分为CDN和页面渲染系统； CDN是AOP系统；

模块维度: 例如，根据基本或代码维护特性进行拆分，例如基本模块: 子库和表，连接池等；如果代码维护通常根据三层体系结构（Web，Service，DAO）进行划分.

首先确定它是否仅需要简单的单点远程服务调用. 如果一台机器不能支持集群，是否可以在客户端注册多台机器并使用Nginx进行负载平衡？随着越来越多的呼叫者，我们必须考虑使用服务自动注册和发现（例如，Dubbo使用zookeeper）；我们还需要考虑服务的分组/隔离，例如某些系统访问权限太大，导致整个服务都被链接，因此有必要为不同的调用者提供不同的服务组并隔离访问；之后，随着呼叫数量的增加，例如服务电流限制，黑名单和白名单等也将被考虑. 还有一些需要注意的细节，例如超时，重试机制，服务路由（可以在不同数据包之间动态切换），故障补偿等，所有这些都会影响服务质量.

汇总为进程内服务--->单点远程服务--->集群手动注册服务--->自动注册和发现服务---->服务分组/隔离/路由---->当前限制/黑白名单.

在设计时，请考虑是否需要对数据进行版本控制以及如果数据维护存在问题是否需要回滚. 例如，是否需要对商品维护进行版本控制. 当前，我们有一些非常重要的系统，需要对数据进行版本控制和支持回滚. 总体设计类似于以下设计:

如果您联系了保险业务，您会发现不同的保险理赔服务是不同的，因此我们在系统设计期间设计了一套理赔流程服务. 承销过程和索赔过程是分开的，然后相互关联电商交易管理系统，以便某些索赔过程可以重用并提供个性化的索赔过程.

状态和状态机

在设计交易订单系统时，将有一个前进状态（待付款，待发货，已发货，已完成）和一个逆状态（取消，退款）等. 前进状态和逆状态应基于您的自己的系统特性，以确定是否有必要分开存储.

此外，订单状态也会发生变化，例如待付款，已付款的装运，待收收货和完成的迁移；考虑是否需要使用状态机来驱动状态更改和后续流程节点操作.

考虑到并发状态修改的问题，同时，对同一顺序只能进行一次修改；状态更改的顺序，状态的倒数第一问题，例如付款成功消息和用户取消消息之间的时间差.

消息队列

消息队列，用于断开一些不需要同步调用的服务或订阅您自己系统关心的某些更改；使用消息队列来实现服务解耦（一对多消耗），异步，缓冲（峰值裁剪）等. 例如，电子商务系统中的交易订单数据，此数据有很多系统需要关注并订阅，例如订单生成系统，定期交付系统，订单风险控制系统等；如果订阅者过多，则将订阅单个消息队列成为瓶颈，您需要考虑消息队列的多个镜像副本.

在促进电子商务业务发展时，此时的系统流量将比正常流量高几倍甚至几十倍. 此时，需要进行一些特殊的设计以确保系统可以顺利通过此时间段. 有很多方法，通常会牺牲强一致性，但是要确保最终一致性.

例如，扣除库存，您可以考虑采用以下设计:

直接在Redis中进行扣除，然后记录扣除日志，并通过Worker同步到DB.

还有一个交易订单系统，您可以考虑以下设计:

首先，结算服务调用接单服务将订单存储到: Redis订单和订单队列列表，可以根据需求水平将订单队列列表扩展N个表，并提高了接收订单的能力通过队列缓冲区表；然后由同步Worker同步到订单中心表；假设用户已经支付了订单，则订单状态将驱动状态更改. 此时，订单队列列表的订单可能未同步到订单中心表. 此时，状态机将根据实际情况重试.

如果用户查看单个订单的详细信息，则可以直接从Redis订单中找到；但是如果您查询订单列表，则需要考虑订单Redis和列表的合并.

同步工作程序在设计时需要考虑并发处理和重复处理，独立串行扫描处理（每个工作程序仅扫描表的一部分）或集群处理（Map-Reduce），此外还需要考虑是否订购相关字段将添加到组列表中: 处理器（正在处理的应用程序）和处理状态（正在处理，已处理，处理失败）.

在使用消息异步机制的情况下，可能会出现消息丢失，因此有必要考虑对数据进行校对和更正以确保数据的一致性和完整性. 工人可以定期扫描原始表进行补偿，扫描周期根据实际情况确定.

Order子库和子表通常根据订单ID进行划分，那么如果要查询用户的订单列表，则需要先汇总N个表的数据然后返回，这将导致订单表非常低；异构订单表，用户订单表，子库和表的异构集（根据用户ID）；此外，还需要考虑存档历史订单数据.

还有一个异构场景，例如产品详细信息页面，因为数据源太多，影响服务稳定性的因素太多，所以最好的方法是将使用过的数据存储在异构环境中存储形成数据闭环；提高能和稳定性. 某些数据异质性意义不大，例如可以将库存价格视为异步加载或并发请求合并.

在我联系过的许多系统中，许多场景都需要反馈. 例如，某些内容已被修改以预览并查看最终效果，即我想获得一些反馈. 有些是规则系统，希望在系统数据反馈中看到这些规则. 因此，在设计背景系统时，请考虑效果的预览和反馈.

对于某些重要的后台功能，您需要设计和批准流程，例如调整价格和记录操作，以确保可以跟踪和审核操作.

例如，需要考虑重新提交结算页面，并且在进行以下单次扣除时，有必要防止库存的两次扣除. 解决方案可以考虑防重KEY，防重表. 在某些情况下，例如重复付款，某些电子商务网站同时支持微信支付和京东支付. 不同的渠道无法防止重复付款，但是系统设计需要记录每次付款. 例如，下图是我在京东使用京东付款和微信付款模拟重复付款后所获得的退款的付款细节:

消息通常在事务系统中使用，现有的消息中间件基本上不能保证不会发生重复的消息消耗；因此，业务系统在重复使用消息时需要考虑幂等处理. 另外，在使用第三方支付时，第三方支付将执行异步回调，因此我们还应考虑回调的幂等处理.

我接触过的某些系统完全没有文档记录，也没有用代码注释，它们都在人与人之间传递. 这将导致人们后来接管的痛苦，他们不敢更改某些代码，例如，某些代码完全是因为它是在某些特殊的业务情况下编写的，可以说没有任何评论和目前尚不清楚为什么要这样做. 因此，在系统开发之初，应该有一个文档库（设计体系结构，设计思想，数据字典/业务流程，存在的问题），业务代码/带有注释的特殊要求.

包括代码和人员. 代码主要提交给代码仓库进行管理和备份. 代码仓库应至少具有多个版本. 人员备份是指至少应具有两个开发理解的系统，即如果其中一个离开，新人接管后就不会发生频繁的事故. 其他人是编写系统核心代码的“核心人员”，被认为是“不可替代的”. 在这种情况下，即使离开工作岗位，他也有可能将一个兄弟聚在一起开发核心代码（业务系统）. 您仍然可以努力克服困难.

本文仅对少量原则进行了分类，其中有许多好的原则无法在文章中进行全面解释，例如回滚（系统出现问题时，系统应在第一时间回滚，排除并保留（如有必要）对故障机器进行故障排除，服务有损（故障功能降级/屏蔽，某些人可用，某些系统可用），灰度释放（功能仅针对某些人开发，因此可以认为问题只会影响少数人）等等，每个原则都可以写一篇文章来详细说明.

前端交易系统本身非常复杂. 以上原则只是作者在实际开发中遇到和使用的一些原则，并且有许多好的原则和经验可供参考. 如果您有好主意，欢迎整理成文章与更分享. 另外，笔者不熟悉支付/结算，供应链，仓库生产等部分，只是对前端交易系统的一些原理进行了总结，希望更多的人加入进来以改进设计原理库.

转载:

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/ruanjian/article-251387-1.html