架构实战案例解析
王庆友
前1号店首席架构师
立即订阅
2075 人已学习
课程目录
已更新 17 讲 / 共 22 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 想吃透架构?你得看看真实、接地气的架构案例
免费
概述篇 (1讲)
01 | 架构的本质:如何打造一个有序的系统?
业务架构篇 (9讲)
02 | 业务架构:作为开发,你真的了解业务吗?
03 | 可扩展架构:如何打造一个善变的柔性系统?
04 | 可扩展架构案例(一):电商平台架构是如何演变的?
05 | 可扩展架构案例(二):App服务端架构是如何升级的?
06 | 可扩展架构案例(三):你真的需要一个中台吗?
07 | 可复用架构:如何实现高层次的复用?
08 | 可复用架构案例(一):如何设计一个基础服务?
09 | 可复用架构案例(二):如何对现有系统做微服务改造?
10 | 可复用架构案例(三):中台是如何炼成的?
技术架构篇 (6讲)
11 | 技术架构:作为开发,你真的了解系统吗?
12 | 高可用架构:如何让你的系统不掉链子?
13 | 高可用架构案例(一):如何实现O2O平台日订单500万?
14 | 高可用架构案例(二):如何第一时间知道系统哪里有问题?
15 | 高可用架构案例(三):如何打造一体化的监控系统?
16 | 高性能和可伸缩架构:业务增长,能不能加台机器就搞定?
架构实战案例解析
登录|注册

08 | 可复用架构案例(一):如何设计一个基础服务?

王庆友 2020-03-09
你好,我是王庆友。
在上一讲中,我提到过,在架构设计中,要实现业务上的复用,一个比较可行的做法是,把各个基础业务封装成共享服务,供上层所有应用调用。所以今天,我就来和你聊一聊,如何从头开始,落地这样一个典型的共享服务。
我们知道,落地一个微服务其实并不困难,但要实现一个能够高度复用的共享服务并不容易,在落地过程中,经常会有一系列的问题困扰着我们。
我们事先对服务的边界没有进行很好的划分,结果在落地的过程中,大家反复争论具体功能的归属。
由于对业务的了解不够深入,我们要么设计不足,导致同一个服务有很多版本;要么服务过度设计,实现了一堆永远用不上的功能。
对于落地一个共享服务来说,服务边界的划分和功能的抽象设计是核心。服务边界确定了这个服务应该“做什么”,抽象设计确定了这个服务应该“怎么做”。
接下来,我就以一个实际的订单服务例子,为你详细讲解一下要如何重点解决这两个问题。这样你可以通过具体的案例,去深入地理解如何落地共享服务,实现业务能力的复用。

订单业务架构

不同企业的订单业务是不一样的,所以这里我先介绍下这个订单的业务场景。
这是个 O2O(Online To Offline,线上到线下)的交易业务,订单的来源有两个,一个是自有小程序或 App 过来的订单,还有一个是外卖平台过来的订单,然后这些线上的订单会同步到门店的收银系统进行接单和进一步处理。这里我放了一张订单的业务架构图,你可以到文稿中看下:
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《架构实战案例解析》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(9)

  • Jxin 置顶
    1.碰巧也是做订单系统的。
    2.目前接管的订单系统是一个开发了四五年的单体订单系统。
    3.没有边界划分,以往的实现,基本就是开发将产品的业务逻辑翻译成代码。现象就是部分拆单策略非常复杂,所有本该外部系统承接的业务逻辑都由订单组完成。这就导致你想维护订单组,支付,营销,会员,商品你都要懂业务。(起步简单,可能这些现在的分组都是那么几个人来完成,但随着业务线的发展,各组的业务都膨胀了很多,已经不是个人短时间能够掌握的)。
    4.代码耦合非常严重,一个商品组的表对象do,会在各个组的api包里面被依赖,相关的业务逻辑也严重依赖该do。牵一发动全身,常常因为一个字段的调整开很久的会议。
    5.代码实现没任何扩展性和灵活性,大量逻辑判断依赖入参状态,导致从单体转多元输入后,一个方法动不动就上千行代码,大量根据数据元做逻辑跳转的代码。

    6.职责模糊,功能复杂,代码耦合高,实现逻辑基本硬编码没有扩展的能力,没有任何单元测试。

    7.现在需要该项目能灵活支撑多元业务的接入,基本就是单体往saas发展了。我能想到的方法都需要较大成本,因为最小的组成单元“策略”,本身的实现不具备可灵活复用的特性,必须重构其实现方式。但如此一来,成本太大。领导是接受不了的。

    作者回复: 感觉你这个不仅仅是订单服务,而包含了订单之上打的oms系统,如果一开始各个基础业务划分的好,系统整体就很好调整,下一讲说的是现有系统的服务化改造,也许对你有用

    2020-03-09
    1
  • 探索无止境
    可惜只有22讲,每一讲都有收获
    2020-03-09
    3
  • 孙同学
    https://www.processon.com/view/link/5e51378ce4b0c037b5f9d1e3 学习整理更新,有个疑问,基础服务不主动调用其他服务,那在优惠计算不是要调用其他服务,然后将结果存储在自己的数据模型中吗,还是说向外提供接口,用于输入优惠计算规则?

    作者回复: 上层应用负责调用优惠计算,然后把结果交给订单服务负责存储。

    2020-03-10
    2
  • 中国合伙人
    我想问一下,订单模型不一样,我们经常通过扩展字段存储差异化数据。那在哪解析扩展字段?基础服务负责解析这些差异字段吗?这里要怎么设计不同业务类型订单查询?

    作者回复: 如果扩展字段是通用的,订单服务会把这部分逻辑落进去,如果是某个项目专用,订单服务支持落数据就可以

    2020-03-09
    1
  • Jeff.Smile
    老师好,订单服务在异步通知应用的时候使用的技术我觉得不一定非要mq吧,只要应用把自己的通知url告知订单服务,订单服务负责在信息变动时进行推送就可以了,这种更简单一些,不过可能可用性不是很高而已。

    作者回复: 你这种说的是url回调,这也是一种方式,在支付里用的比较多,收到第三方平台支付成功后,支付服务回调应用系统提供的URL完成通知。
    这种方式比同步调用耦合性低,比消息通知耦合性高一些,并且调用不成功,要重试,服务要做的事情要更多一些。
    如果针对不特定的接收者,消息通知更合适,解耦更彻底一些。

    2020-03-09
    2
    1
  • 舞命小丢
    讲的挺好的
    2020-03-28
  • 小洛
    请教下老师
    1、关于设计两个状态字段管理订单主状态和子状态,可以主状态是个单独字段,而子状态放在扩展字段吗?那么订单还承接按照子状态纬度的查询
    2、关于订单主状态,基本状态是不可变的,比如支付,下单,结账(结束)但是我们公司的业务就是结账状态有个逆操作反结账,然后还可以不停地在原订单的基础上再加菜,这样的设计合理吗

    作者回复: 1. 既然子状态是显式的,最好有明确字段保存。
    2. 针对这种情况,可以考虑结账不是订单的结束态,而是结账后,过一定时间自动关单,变成真正的"完成"状态。

    2020-03-16
  • AYOU
    老师好:
      1.基本信息管理里面有用户信息,这个用户信息是用户系统的用户基本信息吗?上层系统下单组装用户信息时,订单系统只存用户id还是存一个用户的基本信息?
      2.一般退货的流程是在订单系统做吗?

    作者回复: 是用户基本信息,订单系统一般只存用户id,多存信息就冗余了,简单的情况下,退货单也在订单服务里管理,比如餐饮外卖。复杂情况是有单独的退换货系统,比如电商

    2020-03-11
    1
  • tt
    可复用的两个点:清晰的边界划分和抽象的内部设计。

    1、对于边界划分。在服务的设计之处,总是会现有一个头脑风暴、各方需求裹挟的发散过程,然后随着设计的进行,必需经过收敛,所以我觉得界定服务不做什么更有实践意义。同时,服务功能越单一,越利于复用。

    2、对于内部抽象设计。

    我听完本科,觉得抽象设计还是紧紧的围绕到目前为止的不变的核心:数据和规则(这里特制对外的服务)。

    对于数据,不仅要保证需要的数据要覆盖全面(基础信息、组合信息、外部系统使用的信息——之前的可也讲过,服务是相互正交、互不调用的,但可以共享一定的数据),而且要考虑数据是动态的(比如订单状态的变化),变化就涉及到状态检验规则。这就又涉及到了数据的全面到底是什么含义?是胡子眉毛一把抓么?不是的,是应该抓主要矛盾(比如订单分为基本状态和子状态)


    不主动调用外部,并不是说和外部没有信息交互。这时,使用消息队列进行消息通知自然是一个好的选择,使得内外部解耦。

    进一步,订阅发布模式使得发布消息的实体和接受消息的实体解耦了,双方只需要面对消息本身即可。这是一个理解消息队列的高级的视角。
    2020-03-09
    1
收起评论
9
返回
顶部