04 | 可扩展架构案例（一）：电商平台架构是如何演变的？
单体架构
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
电商平台架构的演变过程展示了从单体架构到分布式架构的发展历程。文章首先介绍了单体架构的特点和局限性，指出随着业务复杂度的增加，单体架构的不足逐渐显现。随后，文章详细阐述了分布式架构的优势和局限性，强调了其适用于业务相关性低、耦合少的系统。最后，文章提出了SOA架构作为更高效地集成应用的解决方案。通过对电商平台架构演变过程的介绍，读者可以了解到不同架构的优劣势及适用场景，为实际工作中的架构选择提供了参考。 文章首先介绍了传统的SOA架构，通过封装现有系统的能力为独立服务，解决了遗留系统集成的问题。随后，文章详细介绍了新的SOA架构，强调了通过服务共享解决系统重复建设问题的方法。接着，文章引入了微服务架构的概念，强调了微服务围绕更小的业务单元构建独立的应用，以及微服务的灵活性和弹性。最后，文章提到了对服务依赖关系进行有效管理的重要性。 总结：本文详实介绍了电商平台架构的演变过程，从单体架构到分布式架构，再到SOA架构和微服务架构。每种架构都针对前一种架构的缺点做了改进，架构的扩展性也变得越来越好，可以满足更高的业务复杂性要求。但需要注意的是，每种架构都有优点和缺点，并且在实际系统中并存。架构选择应根据当前业务特点进行合理选型。通过本文，读者能深入理解架构的扩展性，以及根据业务现状进行合理的架构选型。
《架构实战案例解析》，新⼈⾸单¥59
全部留言(31)
- 最新
- 精选
Leo置顶老师好！请问在做微服务的时候，经常遇到一个问题就是，各系统经常依赖其它系统的数据，那这部分依赖数据是复制存放在依赖的系统还是实时调用？如果实时调用性能问题怎么考虑？如果复制存放在依赖的系统的话，又产生了数据同步问题。性能问题和数据同步问题怎么考虑？ 例如： 1.A系统依赖用户用户，因为A系统要在系统页面上选择用户授权，这时就要有用户的ID和显示名称，那这种在页面上展示一下的数据可以使用用户中心接口调用得到数据并展示。 2.如果A系统要出一上报表，报表上有A系统本身的数据展示，又要有用户的数据展示，比方说用户，订单量汇总之类的，一般的思维就是在A系统数据库存有用户数据，两表一关联查询就得到了，难道还要实时调用用户中心接口得到数据和A系统数据再组装在一起吗？ 3.有些数据的存储本身就要依赖其它服务的数据，如一行定单数据依赖于用户数据，在保存定单时，一定要关联用户信息，这种情况好像不得不冗余保存用户信息了？作者回复: 尽量避免冗余别的系统数据，虽然性能有好处，但也带来一堆问题，比如数据同步，数据一致性，业务逻辑分散在多处，最好是从源头拿数据。跨多个系统的报表最好的做法是统一由数据部门搞定，他们首先会对数据进行汇总。 保存订单时，保存的是用户ID，至于收货地址这些都是订单信息，不是用户信息。
2020-03-0510
aszt置顶老师，你好！SOA架构是中心化的，由ESB连接服务提供方和消费方，但微服务也不是完全去中心化的，微服务也需要注册中心，服务编排、路由、熔断等，需要网关。这些事情以前可能由ESB一块干了。从本质上说SOA架构和微服务架构都属于分布式架构，在理念上是一样的，都是进行业务拆分、服务化，只是在拆分粒度上不同，技术实现上有创新，这样理解是否正确？作者回复: 可以这么理解， 1. 传统的ESB处于调用的中心，ESB是单点，出问题的话，调用就失败。对于微服务来说，直接调用微服务，注册中心中途挂了影响不大，服务编排不需要的，路由熔断也都在调用方做，所谓的哑管道，指调用通路很简单。 2. 除这个之外，ESB负责业务流程编排，这个在微服务里就绝对抛弃了，微服务是智能终端，所有的逻辑都在服务里面提供。
2020-03-046
睡不着的史先生置顶服务跟应用到底是什么区别？服务的落地方式跟应用落地的方式到底什么区别？恳请老师回答作者回复: 这是个好问题，不然容易搞糊涂。 应用和服务都对应一个独立的进程。但应用一般指的是用户能够直接感知的部分，比如app和浏览器页面，带有UI的，针对具体的业务场景。服务指的是背后提供数据和业务逻辑的，不带UI，服务更强调通用的能力。 现在普遍采取前后端分离，一般我们把前端和直接为前端服务的服务端合在一起认为是一个应用，或者简单地说直接的服务端是应用，它的特点是直接面向前端的业务场景，经常变化，代码是定制的。通常情况下本身不干活，通过调用服务是实现功能，稍微复杂的情况，会对后面服务进行聚合。 现在应用也是通过api提供给前端，形式上和服务差别不大，当定位上有明显不同。
2020-03-02229
唐高为置顶分布式系统解决的是早期自建系统之间的通信，SOA解决的是企业采购的系统之间的通信，是两个不同的应用方向；分布式系统是各个系统内部提供统一接口，SOA是在系统外部重新封装一套统一接口。但是，令人疑惑的是，这些系统都是不同公司使用不同语言开发的，要怎么才能把它们封装起来呢？这就需要使用十八般武艺了。有些系统自己提供 WebService 接口或者 HTTP 接口，这个好封装。有些系统并没有提供任何接口，那就可能要直接访问数据库，从数据库中将数据通过接口提供出来了。还有的，可以使用类似爬虫的技术直接从系统页面抓取数据。或者有些系统会使用邮件将流程和数据发送给用户，那么就可以从邮件里解析出用户信息和业务数据。反正，根据不同的系统采用不同的方式吧。作者回复: 十几年前，两个术语很流行，EAI（enterprise application intergratioin）和EII(enterprise information intergratioin), 都是为了各个系统打通。 现在互联网企业盖过传统企业，应用都是自己开发，集成没问题，更多考虑系统扩展和复用，能够快。
2020-02-2926
贺看到文章很多地方出现了"端到端"，这个"端到端"的意思是指从入口到操作db都在一个服务实现的意思吗?作者回复: 端到端指的是业务流程的完整闭环，或者是一个调用处理的闭环，从http调用开始，到内部各个服务调用链路的处理，不是指一个方法处理所有功能。
2020-09-015
寒光在实践中，我们往往弱化微服务的小应用定位，然后扩大化微服务小服务的定位，我们不再强调端到端的业务封装，而是可以有各种类型的微服务。 老师这个总结真的特别接地气，完全没有了那种阳春白雪的感觉，非常有实际的指导意义，尤其是“系统服务”“共享服务”“业务服务”的归类，让我有一种踏破铁鞋无觅处，不知转入此中来的感觉，之前总是觉得，一个微服务，必然是独立部署、独立运维、端到端的形成一个业务闭环，否则就觉得不是微服务，或者是假的微服务，总之，就是非常纠结，现在突然打开了思路，比如：常见的基础数据，像地理类的省市区县之类的，好像可以叫基础数据服务了~~作者回复: 你看的很认真，并能够结合自己的实践深入思考，这样学到的才是属于自己的，赞一个。
2020-12-294
J.Smile“但在电商场景下，业务都是围绕交易展开的，各个页面（应用）都需要和商品、用户、订单、库存打交道，对于这样业务相互依赖、应用之间需要紧密协作的场景，在系统架构方面，是否有更好的手段，可以更高效地集成这些应用呢？ 答案是有的，SOA 架构就可以有效地解决这个问题。” —————————————————————— 老师，分布式架构就不能解决上边的问题吗，通过api接口不是可以做到互通吗？总觉得以这个原因引入SOA加构说服力不强呢，而且SOA和分布式两个架构之间有很多重叠部分吧作者回复: 通过api可以互通，但在业务关系紧密的情况下。每个应用都会有部分的商品，用户，订单，库存逻辑，职责碎片化，应用之间耦合紧密，相互影响。如果用服务化的思路把商品，用户等单独封装起来，然后供各个业务共享，开发效率和质量都更好。 SOA架构也是分布式的一种，当然微服务也是分布式。
2020-02-284- InfoQ_e8fa90f8b254老师，图画的很好看，请问你这个画图软件是什么？
作者回复: 苹果笔记本自带的画图软件
2021-05-053 
明才微服务，拆分扩展是容易了，但是整合起来，包括服务依赖关系，二方包依赖问题，需要权衡。作者回复: 我见过很多公司，微服务数量很多，但依赖关系混乱。整个服务体系一定要做好分层，依赖关系简单清晰。
2022-02-221- InfoQ_e8fa90f8b254老师，请教下，拆分微服务后，各个服务各自管理自己的数据，但有场景需要条件分页查询多个服务的数据，怎么处理？冗余其他服务的数据过来吗？
作者回复: 1. 汇总数据到es或hadoop平台 2. 先根据过滤条件查询主服务，然后根据id批量查询另一个服务，拼接数据
2021-11-251
