19 | 综合案例：电商平台技术架构是如何演变的？
单体系统
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
电商平台技术架构的演变是一个复杂而值得关注的过程。从最初的单体系统到SOA架构，再到服务调用去中心化和垂直分库，文章详细介绍了电商平台技术架构的发展历程。随着业务量的增长，作者还提到了水平分库及高可用部署以及多机房部署等解决方案。最后，为了避免跨机房访问带来的问题，文章提出了服务调用本地化的解决方案。这些演变过程中，不断解决着技术架构中的问题，如单体应用的性能瓶颈、数据库容量问题、跨机房访问的延时和不可用性等。通过这些演变，读者可以全面地了解电商平台技术架构的发展历程，以及如何解决技术架构中的各种问题。 文章还介绍了针对外部服务依赖的可用性问题的解决方案，包括依赖分级管理和多机房独立部署。针对跨机房数据库访问的性能问题和老机房整体故障带来的可用性问题，提出了多机房独立部署的解决方案。同时，文章还提到了容器化技术的发展对系统部署的优化作用。通过这些解决方案，系统的可用性、处理能力和可伸缩性得到了极大提升，能够更好地应对各种异常情况。 总的来说，本文通过一个简化的电商系统模型，分享了电商平台的技术架构发展过程，以及如何解决系统各个阶段出现的高可用、高性能和可伸缩问题。读者可以从中深入了解技术架构如何应对各种系统性挑战。同时，文章也提醒读者，系统的技术架构变化不一定要完全遵循特定过程，需要根据具体情况具体分析，灵活地运用解决手段。最后，作者留下了一个思考题，引导读者思考当前系统架构所处阶段及面临的问题，鼓励读者不断学习，寻找新的解决问题的手段。
《架构实战案例解析》，新⼈⾸单¥59
全部留言(16)
- 最新
- 精选
秋天问一下 多机房独立部署 数据库数据需要做同步吗？如何同步？作者回复: 需要数据同步，可以是A地的主库包括部分数据（比如奇数用户ID的订单），同步给B地的从库，B地也有主库（偶数用户ID的订单），同步给A地的从库，这样A/B地都有完整数据。如果AB物理挨得近，可以是裸光纤数据库同步的方式，远的话可以使用其他中间件同步。
2020-10-109
芒果老师您好，看完文章有2个问题？ 1.请问多机房独立部署的话，数据同步这块是怎么做的呢？ 2.我们公司现在也在采用k8s和docker的方式部署应用，但是类似数据库还是没有容器化。请问目前业界也是这样吗？还是已经实现全部上k8s部署了？作者回复: 1. 理想情况下，各个机房业务自成闭环，比如A机房处理用户Id是2倍数的用户交易，B机房处理另外用户。这里的数据库是水平分库，这两部分用户的订单放在不同的库里，A机房的订单会同步给B机房，反之一样。每个机房都会有全量数据。如果机房靠的近，可以采用数据库自带的主从同步方式，隔得远，使用程序同步机制。 2. 有状态的数据库一般不用docker部署。
2020-04-0336
brant老师咨询一个关于wms系统平台化的思路。背景是这样的，我们一开始自研发的wms系统只服务于大仓，然后慢慢又了前置仓，有些流程是不一样的。这个时候我们是用一套，然后进行配置化来实现比较好，还是抽象两个烟囱式的模型比较好。另外一个情况就是之前打造wms的时候跟oms系统比较耦合，然后目前出现了其他公司订单要直接对接我们的wms系统，这方面老师有什么建议么作者回复: wms和oms应该解耦，前置仓也是物理库存吧，理论上可以把它们当小仓看，也有出入库操作，可以和wms在一起。只是粗略建议，具体要看场景差异。 有个建议，和专栏关系不是特别密切的问题，大家也可以加我微信深入沟通:brucetwins
2020-04-1023
阿甘写的挺好。关于多机房部署有几个疑问： 1. 多机房部署之后，用户如何分片和路由（根据用户id分片当然简单，但是这样没法实现就近接入，比如广东的用户被分片到北京的机房那这个访问体验肯定是很差的） 2. 多机房部署之后，各机房之间的数据是怎样同步的？ 3. 当某个机房故障发生的时候，这个切换过程是怎样的呢？作者回复: 多机房部署，这里只提供思路，细化的架构设计很复杂，包括db数据，应用跨机房调用，缓存，消息系统等等。比如db数据同步，对于用户A，它的主库数据在A机房，从库数据在B机房，通过专线做主从同步，如果A机房主库出问题，可以从B机房的从库同步数据回来，也可以把B机房的从库升级为主库(如果B机房和A机房是同城就近部署的话)，具体需要根据实际情况而定。
2021-06-102
jian请教一下老师，这里说“在实践中，我们还可以提供多套水平分库。比如说，针对交易数据，我们可以同时按照用户维度和商户维度进行水平分库，用户维度的库用于前台用户下单的场景，商户维度的库用于后台商家履单的场景。这里，只有用户维度的分库会支持写，我们通过数据同步机制，把用户维度分库的更新同步到商户维度的分库里。”。这是指存储两份相同的数据，只是维度不一样吗？为什么不用lookup表或者缓存实现？作者回复: 对的，是两套表，简单的lookup不能很好地解决问题。比如给定商户ID，在用户维度库里如何找出该商家下的订单呢？只能扫描所有用户维度的分库。
2020-06-161
探索无止境老师的每篇文章都值得二刷，而且每次提问都得到老师的指点，非常推荐订阅！关于最后提到的双机房模式，还要考虑两个机房的数据同步问题，是不是采用消息中间件异步的方式来实现两个机房的数据库数据同步？作者回复: 机房靠的近的话，可以直接用数据库本身的同步功能。机房隔得远，可以选择解析底层的binlog，然后同步。使用偏上层的消息中间件也是一种选择，但这个更合适业务系统间的数据同步。 多机房部署很复杂，包括数据分布，缓存，消息系统等，大家有这个概念就行，深入下去，要解决的问题比较多。
2020-04-131- hello老师，请教您一个问题，您说的多机房独立部署方案，那存储问题是如何解决的？
作者回复: 可以参考我另一个问题的回复
2020-04-031 
流云追风为什么选择了多机房而不是上云呢？作者回复: 大的互联网平台都是自建机房，或者说自建内部云，多机房协同的复杂性也不是公有云能解决的。比如美团，它不会用腾讯云或阿里云。
2021-10-272
小洛这篇是一篇很好的体系化梳理文章 谢谢老师的分享，请教您一个问题 1、如果是多机房独立部署，假设有北方机房，南方机房，这个距离很远（甚至可以是国内、国外这么远），那么北方的用户来到南方使用我们的系统，我们是路由回北方机房进行服务提供吗？要如何优化这种业务场景呢？作者回复: 原则上来说，北方的用户来到南方使用我们的系统，我们是路由回北方机房，这个只是接入层长途路由，服务端内部还是走北方机房，性能问题不大。
2020-04-052
川杰接上一个。 我可能没有阐述清楚，我们有一张大的结算指令表，表中有一个交易编号的字段，如果结算服务不访问交易，那么只能: 1.调用结算服务，返回要计算的结算指令上的所有交易编号。 2.调用交易服务，获取交易数据。 3.将交易数据传给结算服务的下一个计算接口。 这样不是太麻烦了？作者回复: 你这里交易服务和结算服务有上下游关系，有直接调用关系也正常。 或者你拆分的更彻底一些，把交易服务分为偏上层的和偏底层的，偏上层的交易服务同时调用底层交易服务和结算服务。
2020-04-033
