《电商前端交易型系统设计原则.docxVIP

电商前端交易型系统设计原则从毕业到现在已经快7年开发经验了，做过基础用户系统、积分商城、偷菜游戏、论坛、博客等等；也一个人全栈开发在线视频网站，也开发过几万、几十万、几千万、几个亿不同量级的系统，踩过不少坑，也学到许多经验。设计了一些系统，也有了一些自己的观点，个人认为设计系统要因场景因时间而异，一个系统不是一下子就设计的非常完美，在有限的资源情况下一定是先解决当下最核心的问题，并预测/发现未来可能出现的问题，一步步解决最痛点的问题。也就是说系统设计是不断迭代的过程，在迭代中发现问题修复问题；即满足需求的系统是不断迭代优化出来的，不是一下子就架构的非常完美，这是一个持续的过程，个人不相信完美架构银弹。不过如果一开始就有好的基础系统设计，未来可以更容易达到一个比较满意的目标。在设计系统时应该多思考墨菲定律：1、任何事都没有表面看起来那么简单；2、所有的事都会比你预计的时间长；3、会出错的事总会出错；4、如果你担心某种情况发生，那么它就更有可能发生。但是也要思考80/20法则，在系统设计初期将有限的资源用到刀刃上，我们的目标是系统满足现有需求并能支持未来需求。在持续开发系统过程中前辈们也总结了很多设计原则/经验；而我个人也有幸运用了一些经验/原则。设计原则是系统发展初期或进化过程中根据自己系统特征匹配使用的，如果刚开始不是核心问题请不要复杂化系统设计。拆分在系统设计初期，是做一个大而全的系统还是进行按功能拆分系统这个需要进行权衡；比如做私塾在线时本身用户量/交易量不会特别大，而且开发就我一个人，资源有限，那就没必要对系统拆分（比如拆分商品、订单等等），就是做一个大而全的系统。而比如设计一个京东秒杀系统，预测到一旦上线量会非常大，而且投入的资源还是蛮充足的，这种情况下就要考虑进行按功能拆分系统。笔者遇到的拆分主要有如下几种情况：系统维度：按照系统功能/业务拆分，比如商品系统、购物车、结算、订单系统等等；功能维度：对一个系统进行功能再拆分，比如优惠券系统，可以拆分为后台券创建系统、领券系统、用券系统等；读写维度：根据读写比例特征进行拆分，比如商品系统，交易的各个系统都会读取，读大于写，因此就可以进行拆分：商品写服务、商品读服务；读服务可以考虑全量缓存提升性能；比如写的量太大，需要考虑分库分表；还有些聚合读取的场景，如商品详情页，请考虑数据异构拆分系统，将分散在多处的数据聚合到一处存储，提升读的性能和可靠性；AOP维度：根据访问特征，按照AOP进行拆分，比如商品详情页，可以分为CDN、页面渲染系统；CDN就是一个AOP系统；模块维度：比如按照基础或者代码维护特征进行拆分，如基础模块：分库分表、数据库连接池等等；还有如代码维护一般按照三层架构（Web、Service、DAO）进行划分。服务化首先判断是不是只需要简单的单点远程服务调用即可，如果单机扛不住了需要集群，是不是可以在客户端注册多台机器，使用Nginx进行负载均衡即可解决；如果随着调用方越来越多，就要考虑使用服务自动注册和发现（如Dubbo使用zookeeper）；还要考虑服务的分组/隔离，比如有的系统访问量太大导致把整个服务打挂，因此需要为不同的调用方提供不同的服务分组，隔离访问；后期还会随着调用量的增加还要考虑如服务的限流、黑白名单等等。还有一些细节需要注意，如超时时间、重试机制、服务路由（能动态切换不同的分组）、故障补偿等等，这些都会影响到服务的质量。总结为进程内服务—单点远程服务—集群手动注册服务—自动注册和发现服务—-服务的分组/隔离/路由—-限流/黑白名单。数据版本化，可回滚在设计时考虑是否需要进行数据的版本化，数据维护出问题是否需要回滚。比如商品的维护是不是需要版本化。我们目前有一些非常重要的系统需要对数据进行版本化并且支持可回滚。流程可定义如果接触过保险业务，会发现不同的保险理赔服务是不一样的，因此我们在系统设计时就设计了一套理赔流程服务。而承保流程和理赔流程是分离，然后进行关联，从而可以复用一些理赔流程并提供个性化的理赔流程。状态与状态机在设计交易订单系统时，会存在正向状态（待付款、待发货、已发货、完成）和逆向状态（取消、退款）等，正向状态和逆向状态应该根据自己系统的特征来决定是不是需要分离存储。另外还有订单状态的变迁，比如待支付、已支付待发货、待收货、完成的迁移；要考虑是不是需要使用状态机来驱动状态的变更和后续流程节点操作。还要考虑并发状态修改问题，同时对同一个订单只存在一个修改；状态变更的有序问题，状态变更消息的先到后到问题，如支付成功消息和用户取消消息的时间差。消息队列消息队列，用来解耦一些不需要同步调用的服务或者订阅一些自己系统关心的变化；使用消息队列可以实现服务解耦（一对多消费）、异步、缓冲（削峰）等。比如电商系统中的交易订单数据，该数据有非常多的系统关