电商商城架构建设 第1篇
我们在电商平台，除了购物商品，其实还会有很多虚拟商品的消费需求，例如充话费、买视频会员、买游戏卡等。
一般情况下，我们选购一个商品，话费100元，输入手机号，支付100元，然后话费即到账。
虚拟商品的购买流程，有以下几个特点：
和实物商品业务流程相比，虚拟商品的业务流程主要体现在以下两大差异：
其实对到虚拟商品销售，其业务流程与之前只有轻微差异，其系统架构与之前则是毫无差异。
那为啥要单独说这一业务？
这就更加验证了文章开头说的，系统搭建是否足够抽象化、是否足够有前瞻性。
我们可以看到，对到虚拟商品业务，只需在供应链系统，针对供应商类型、供应商入驻模块支持多类型，比如该供应商是实时采购机制、入驻可能是API模式等；在黄金流程下单模块，针对虚拟商品订单，支持充值账号填写；在履约模块中，支持支付成功后实时充值……
因此，当系统框架足够原子化、抽象化，新业务的接入，自然就不用“伤筋动骨”。
这几年在电商平台，常见的一个购物方式是——分期支付。
当你看到一部手机3000元时，平台告诉你，可以先使用额度完成支付，选择分多少期还款，支付完成后，即可坐等收货。后续每个月按时还款即可。常见的淘宝花呗支付、京东白条支付都属于该类场景。
也就是说用户无需先付钱，而是先享受到货品，后续每月按月还款。当然，每月还款金额，除了商品金额，还需要包含于一定的利息服务费。
对到分期支付场景，最大的特点是涉及到了“信贷”，而信贷的基础是“信用”，也就是说平台风控系统会对用户进行信用评估。
这个信用评估涉及到了用户购物全流程。首先，风控会基于用户提交的信息，判断可以给用户多少额度。其次，风控会在用户尝试下单时，决策用户购买该商品可用的额度值、分期数、息费等。接着，风控会在用户真正支付时，实时决策该笔订单是否可以分期支付，也就是风控审核是否通过。
如果风控判定用户分期支付成功，那么后续流程中还有一个关键角色——资金。
订单需要先进行融资，也就是说存在一个资方，先帮用户把商品货款支付给平台。融资完成后，用户就会生成账单，意思就是生成一个用户向资方借款的凭证，后续每个月用户需向资方进行还款。当全部账单还完后，则该笔交易才最终结束。
和正常支付的流程相对，分期支付购物在流程上，主要有以下几大差异点：
1）额度授信
用户进入到平台，需要先提交资料信息，经过风控审核，申请获得购物额度。只有获取了购物额度，才能在平台使用分期支付。
正常情况下，购物类型的消费额度，多为循环额度，也就是说授信了10000元额度，如果使用了4000元，剩余6000元依然可用。等到4000元还款完成，则可用额度又恢复成10000元。
当用户实际购买某个商品时，风控会调控是否允许用户使用分期支付，可使用的分期范围是多少，每个分期的息费是多少。
当用户选定好某个商品，提交订单支付时，风控需要实时判断，该笔订单是否允许分期支付。
之所以有该审核环节，是因为授信的额度属于循环额度，授信和交易之间必然存在时间差。授信时是基于用户当时的风控表现，授予用户额度；不代表交易时，用户的风险表现未发生变化，因此需要在交易时再进行实时审核判断。
4）额度扣减
当用户支付成功后，首先会进行额度更新，也就是额度扣减。用户的可用额度随之变少。
用户确认收货后，需要将该笔订单进行融资，也就是寻找到资方，承担该笔信贷单。当然，也可以先进行融资再发货，从流程上二者皆可行，取决于业务实际决策。
在进行融资匹配时，常见的有直贷、信托、保理、自持等多种资产承接方式。融资成功，代表有资方替用户将订单货款先付给平台，此时可生成账单，后续由用户进行还款。
一般情况下，消金平台都会有自持资金，也就是在其他方式融资失败的情况下，可使用自持资金兜底。
如果是先融资后发货，也可以在融资失败的情况下，将订单关闭，不进行发货履约。
6）账单处理
当到了账单还款日，用户按月进行还款，所有账单还款完成，则意味着账单完成。
如果用户申请售后，订单关单后，需要同步将账单关闭。
如果此时账单还未有还款，则关闭用户账单，额度回退即可。
如果此时账单已有还款，那么除了关闭账单，额度回退以外，还需要将用户已还款的金额也退回，该部分金额一般叫做溢缴款，顾名思义就是用户溢出来的缴款额。
为支撑分期支付购物流程，整个电商系统框架需在以下几大系统模块进行兼容处理：
金融营销模块主要负责金融元素的营销，包括：
黄金流程中的金融额度模块，主要承接用户端全流程中涉及分期金融元素的展示和使用
在用户基础中，需增加用户金融信息维护，一方面用户流程强依赖于用户的基础数据；另一方面业务分析也需要用户金融相关的画像。
主要信息包括授信状态、授信额度值、用户风险表现等。一般情况下风控系统会维护用户风险相关的各类信息，例如芝麻信用分、微信支付分等都属于该类信息。
在支撑系统中，除了风控系统需支持用户风险识别，应用于授信、交易环节外，还需新增资金系统的支持。
资金系统需要确保分期支付订单可以融资成功，只有生成账单，才意味着订单的真正支付成功。因此，资金系统需至少支持以下模块内容：
回到最开始讨论的话题，我们对于系统框架的拆解和设计，主要基于两方面考虑：
一是作为产品，我们需要对系统有清晰的认识，这样可以保证我们在新业务来临时，快速响应和解决。
二是作为产品，我们需要有基本的拆解能力、抽象能力、规划能力，这对个人能力和认知的提升有很大帮助。
但是我们经常在市场上看到很多课程和广告宣传，通过跟老师学习，可以掌握如何设计电商系统。我觉得这个是绝对不成立的。
首先，每个公司的价值一定具有独特性，他一定是满足了不一样的需求，这样公司才有生存的可能性。
那么，公司的价值需要靠业务实现，业务也就一定具有独特性。
最后，业务的落地靠系统承接，因此，每个公司的系统也一定具有其独特性。
我们不存在一套系统框架设计，能满足市场上全部公司的应用。
所以，当我们拆解和设计系统时，一定要按照公司业务的实际情况，基于现状和业务诉求进行处理。不是设计出来一套“高大上”，“全世界通用”的系统才是最好的。能解决业务问题，满足当前公司发展的系统，就是最好的。
上文的系统拆解及设计，也仅仅是一个参考，任何脱离了业务存在的系统，都是“废品”。
专栏作家
产品小球，微信公众号：产品小球，人人都是产品经理专栏作家。95后的产品经理，潜心专研互联网产品C端和B端设计，洞察用户需求，探索商业模式。
题图来自 Unsplash，基于CC0协议。
电商商城架构建设 第2篇
本文将分享某某商城网站在架构实践中的经验和教训，包括：
某某商城网站的系统架构演化过程可以分为以下几个阶段：
初期架构：在网站成立初期，采用的是简单的单体应用架构，将所有功能都集中在一个应用中。这种架构的优点是开发速度快，但随着业务的发展，逐渐暴露出可扩展性差、维护成本高等问题。
分层架构：为了解决单体应用架构的问题，商城网站逐渐演进为分层架构。将系统划分为表示层、业务逻辑层和数据访问层。这种架构有助于代码的模块化和重用，提高了系统的可维护性和可扩展性。
微服务架构：随着业务的发展，商城网站进一步演进为微服务架构。将系统拆分成多个独立的服务，每个服务负责一个特定的业务功能。这种架构可以更好地应对业务的快速发展，提高了系统的可扩展性和可维护性。
容器化与云原生架构：为了提高系统的可扩展性和可维护性，商城网站采用了容器化技术和云原生架构。将服务部署到容器中，实现了服务的快速部署和弹性伸缩。同时，利用云原生技术，实现了系统的自动化运维和监控。
在技术选型方面，某某商城网站主要做了以下决策：
编程语言：使用了Java作为主要编程语言，因为Java具有跨平台、高性能、可扩展性强等优点。
框架：使用了Spring Boot框架作为开发框架，因为Spring Boot具有易于使用、快速开发、社区活跃等优点。
数据库：使用了MySQL作为关系型数据库，因为MySQL具有成熟稳定、使用广泛、可扩展性强等优点。同时，还使用了Redis作为缓存，提高了系统的访问速度。
前端技术：使用了HTML、CSS、JavaScript等前端技术，实现了网站的交互效果。同时，还使用了React等前端框架，提高了前端开发效率。
在实现策略方面，某某商城网站主要采取了以下措施：
模块化开发：将系统的各个功能模块进行了模块化开发，提高了代码的可读性和可维护性。
代码审查：实施了代码审查制度，确保了代码的质量和可维护性。
持续集成与持续部署：采用了持续集成与持续部署(CI/CD)的工程实践，提高了软件开发的效率和质量。
在架构优化方面，某某商城网站主要采取了以下措施：
数据库优化：对数据库进行了索引优化、分库分表等优化措施，提高了数据库的查询性能。
缓存策略：采用了适当的缓存策略，提高了系统的访问速度。
异步处理：对于耗时的操作，采用了异步处理的方式，提高了系统的响应速度。
负载均衡：通过负载均衡技术，实现了系统的水平扩展，提高了系统的处理能力。
在实践中，某某商城网站还积累了丰富的经验，如：
（1）定期对系统进行性能测试和评估，及时发现并解决性能瓶颈。
（2）重视团队成员的技术培训和能力提升，提高了团队的技术水平。
（3）与其他团队进行技术交流和合作，共同解决技术难题。
在架构实践中，某某商城网站主要遇到了以下挑战：
高并发访问：随着用户量的增长，系统面临着高并发访问的挑战。为了应对这一挑战，采用了缓存策略、负载均衡等技术，提高了系统的并发处理能力。
数据一致性：在分布式系统中，如何保证数据的一致性是一个重要的挑战。采用了一致性哈希、分布式事务等技术，确保了数据的一致性。
系统可用性：为了提高系统的可用性，实施了容灾备份、故障切换等技术，确保在出现故障时能够快速恢复服务。
技术更新换代：随着技术的不断发展，如何保持系统的技术领先是一个挑战。通过关注技术动态，及时更新技术栈，确保系统的技术领先。
电商商城架构建设 第3篇
考虑到交易系统OLTP特性和开发人员熟练程度，采用MySQL作为底层存储、ShardingSphere作为分库分表中间件，将用户标识(userId)作为分片键，保证同一个用户的订单落在同一个库中。
接入新租户时约定一个租户编码(tenantCode)，所有接口都要带上这个参数；租户对数据量和并发量进行评估，分配至少满足未来五年需求的库表数量。
租户与库表的映射关系：租户编码 -> {库数量,表数量,起始库编号,起始表编号}。
通过上面的映射关系，可以为每个租户灵活分配存储资源，数据量很小的租户还能复用已有的库表。
示例一：
新租户接入前已有4库*16表，新租户的订单量少且并发低，直接复用已有的0号库0号表，映射关系是：租户编码-> 1,1,0,0
示例二：
新租户接入前已有4库*16表，新租户的订单量多但并发低，用原有的0号库中新建8张表来存储，映射关系是：租户编码-> 1,8,0,16
示例三：
新租户接入前已有4库*16表，新租户的订单量多且并发高，用新的4库*8表来存储，映射关系是：租户编码-> 4,8,4,0
用户订单所属库表计算公式
库序号 = Hash(userId) / 表数量 % 库数量 + 起始库编号 表序号 = Hash(userId) % 表数量 + 起始表编号
可能有小伙伴会问：为什么计算库序号时要先除以表数量？下面的公式会有什么问题？
库序号 = Hash(userId) % 库数量 + 起始库编号 表序号 = Hash(userId) % 表数量 + 起始表编号
答案是，当库数量和表数量存在公因数时，会存在倾斜问题，先除以表数量就能剔除公因数。
以2库4表为例，对4取模等于1的数，对2取模也一定等于1，因此0号库的1号表中不会有任何数据，同理，0号库的3号表、1号库的0号表、1号库的2号表中都不会有数据。
路由过程如下图所示：