04 | 可扩展架构案例（一）：电商平台架构是如何演变的？
单体架构
请订阅文章所属专栏。
精选留言(15)
睡不着的史先生 置顶服务跟应用到底是什么区别？服务的落地方式跟应用落地的方式到底什么区别？恳请老师回答作者回复: 这是个好问题，不然容易搞糊涂。 应用和服务都对应一个独立的进程。但应用一般指的是用户能够直接感知的部分，比如app和浏览器页面，带有UI的，针对具体的业务场景。服务指的是背后提供数据和业务逻辑的，不带UI，服务更强调通用的能力。
现在普遍采取前后端分离，一般我们把前端和直接为前端服务的服务端合在一起认为是一个应用，或者简单地说直接的服务端是应用，它的特点是直接面向前端的业务场景，经常变化，代码是定制的。通常情况下本身不干活，通过调用服务是实现功能，稍微复杂的情况，会对后面服务进行聚合。
现在应用也是通过api提供给前端，形式上和服务差别不大，当定位上有明显不同。2020-03-02 1 4
知莫问 置顶分布式系统解决的是早期自建系统之间的通信，SOA解决的是企业采购的系统之间的通信，是两个不同的应用方向；分布式系统是各个系统内部提供统一接口，SOA是在系统外部重新封装一套统一接口。但是，令人疑惑的是，这些系统都是不同公司使用不同语言开发的，要怎么才能把它们封装起来呢？这就需要使用十八般武艺了。有些系统自己提供 WebService 接口或者 HTTP 接口，这个好封装。有些系统并没有提供任何接口，那就可能要直接访问数据库，从数据库中将数据通过接口提供出来了。还有的，可以使用类似爬虫的技术直接从系统页面抓取数据。或者有些系统会使用邮件将流程和数据发送给用户，那么就可以从邮件里解析出用户信息和业务数据。反正，根据不同的系统采用不同的方式吧。作者回复: 十几年前，两个术语很流行，EAI（enterprise application intergratioin）和EII(enterprise information intergratioin), 都是为了各个系统打通。
现在互联网企业盖过传统企业，应用都是自己开发，集成没问题，更多考虑系统扩展和复用，能够快。2020-02-29 1 2
Leo 置顶老师好！请问在做微服务的时候，经常遇到一个问题就是，各系统经常依赖其它系统的数据，那这部分依赖数据是复制存放在依赖的系统还是实时调用？如果实时调用性能问题怎么考虑？如果复制存放在依赖的系统的话，又产生了数据同步问题。性能问题和数据同步问题怎么考虑？
例如：
1.A系统依赖用户用户，因为A系统要在系统页面上选择用户授权，这时就要有用户的ID和显示名称，那这种在页面上展示一下的数据可以使用用户中心接口调用得到数据并展示。
2.如果A系统要出一上报表，报表上有A系统本身的数据展示，又要有用户的数据展示，比方说用户，订单量汇总之类的，一般的思维就是在A系统数据库存有用户数据，两表一关联查询就得到了，难道还要实时调用用户中心接口得到数据和A系统数据再组装在一起吗？
3.有些数据的存储本身就要依赖其它服务的数据，如一行定单数据依赖于用户数据，在保存定单时，一定要关联用户信息，这种情况好像不得不冗余保存用户信息了？作者回复: 尽量避免冗余别的系统数据，虽然性能有好处，但也带来一堆问题，比如数据同步，数据一致性，业务逻辑分散在多处，最好是从源头拿数据。跨多个系统的报表最好的做法是统一由数据部门搞定，他们首先会对数据进行汇总。
保存订单时，保存的是用户ID，至于收货地址这些都是订单信息，不是用户信息。2020-03-05
aszt 置顶老师，你好！SOA架构是中心化的，由ESB连接服务提供方和消费方，但微服务也不是完全去中心化的，微服务也需要注册中心，服务编排、路由、熔断等，需要网关。这些事情以前可能由ESB一块干了。从本质上说SOA架构和微服务架构都属于分布式架构，在理念上是一样的，都是进行业务拆分、服务化，只是在拆分粒度上不同，技术实现上有创新，这样理解是否正确？作者回复: 可以这么理解，
1. 传统的ESB处于调用的中心，ESB是单点，出问题的话，调用就失败。对于微服务来说，直接调用微服务，注册中心中途挂了影响不大，服务编排不需要的，路由熔断也都在调用方做，所谓的哑管道，指调用通路很简单。
2. 除这个之外，ESB负责业务流程编排，这个在微服务里就绝对抛弃了，微服务是智能终端，所有的逻辑都在服务里面提供。2020-03-04
tt架构的演进，真是一个螺旋式上升的过程。
本文的第一张图和最后一张图，从图的拓扑结构上，没有本质的区别。但：
1、图中的连线已经从进程内的函数调用，变为了通过轻量级的通讯框架的服务间的调用了；
2、业务的核心是数据，图中的节点的边界变成是根据业务数据进行划分边界的了；
3、业务之间的数据需要共享，数据已经“服务化”了。
因为根据业务域进行了服务化，所以在部署上变得更轻量级、更加松耦合，更好组合，所以变得更可扩展了。2020-02-28 3
孙同学https://www.processon.com/view/link/5e51378ce4b0c037b5f9d1e3 看了两遍整理好的，没有实际经验，感觉理解的很浅。2020-02-28 1 2
Jeff.Smile“但在电商场景下，业务都是围绕交易展开的，各个页面（应用）都需要和商品、用户、订单、库存打交道，对于这样业务相互依赖、应用之间需要紧密协作的场景，在系统架构方面，是否有更好的手段，可以更高效地集成这些应用呢？
答案是有的，SOA 架构就可以有效地解决这个问题。”
——————————————————————
老师，分布式架构就不能解决上边的问题吗，通过api接口不是可以做到互通吗？总觉得以这个原因引入SOA加构说服力不强呢，而且SOA和分布式两个架构之间有很多重叠部分吧作者回复: 通过api可以互通，但在业务关系紧密的情况下。每个应用都会有部分的商品，用户，订单，库存逻辑，职责碎片化，应用之间耦合紧密，相互影响。如果用服务化的思路把商品，用户等单独封装起来，然后供各个业务共享，开发效率和质量都更好。
SOA架构也是分布式的一种，当然微服务也是分布式。2020-02-28 1- jun我们公司的电商系统，还是单体架构模式，由于业务不断增加导致目前处于一个无序状态，什么都不敢调整，动一个小地方可能会影响到其他的业务流；所以现在准备按业务领域来区分模块，进行微服务的架构设计，比如商品基础模块、物流基础模块、订单模块，准备是以这种方式进行，不知是否可行。
作者回复: 方向没问题，你也可以看下第9篇文章，有讲到如何对单体系统做服务化改造
2020-03-12 
Mandalorian讲得真好2020-03-10
dowannado20200307 单体 分布式 soa 微服务 中台 拆 合2020-03-07- 睡不着的史先生老师，还没太明白，您说应用也是通过api提供给前端，也就是说API是应用的一种形式吗？服务对外暴露的不也是API吗？2020-03-03
曌"架构没有最好，只有最合适"，这才是精髓啊，感觉很多企业动不动就要上微服务，也不管自己的体量是否需要微服务，有些小的公司服务体量也小，那么其实单体应用就可以，完全能撑得起业务，如果强行上微服务，那么往往就浪费了很多人力成本，技术成本，还达不到好的效果，所以我的理解是要看微服务是否适合自己，能否帮我们解决最根本的问题，再去衡量如何上微服务，怎么上微服务。2020-03-01
李端对端这个词怎么理解？是指一条线闭环吗？作者回复: 一个业务处理的起点到终点
2020-03-01
Rory已经反复读了这些章节几遍了，也尝试用这些原则和方法分析现有产品，很有收获。
希望更新再快一些）：2020-02-28
探索无止境我理解的微服务其实就是分布式架构的一种，只是有两点改进：
1，服务粒度拆分更细，方便上层应用复用
2，服务间的通信协议更简单便捷，比如http方式2020-02-28