架构实战案例解析
王庆友
前1号店首席架构师
立即订阅
2081 人已学习
课程目录
已更新 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 | 高性能和可伸缩架构:业务增长,能不能加台机器就搞定?
架构实战案例解析
登录|注册

10 | 可复用架构案例(三):中台是如何炼成的?

王庆友 2020-03-13
你好,我是王庆友。
第 8 讲中,我通过一个实际的订单服务案例,和你介绍了如何设计一个基础服务。今天,我就继续带你了解,如何在实际的业务场景中,通过一步步的架构升级,最后落地一个中台,实现企业级能力的复用。
通过前面的介绍,我们已经很清楚了共享服务和中台的价值,但在实践中,要不要对系统做这样的升级,我们还需要结合业务来判断,比如说:
业务上有什么重大变化,导致当前系统的弊端已经很明显,不能适应业务发展了呢?
架构改造时,如何在业务、系统、资源三者之间做好平衡,对系统进行分步式的改造呢?
我们知道,架构没有最好,只有最合适的。随着业务的发展,系统需要不断地升级,这是一个螺旋式上升的过程,如何结合当前的业务发展阶段,适时地推进架构改造,并能比较接地气地落地,是我们要追求的目标。
接下来,我以实际的订单系统改造为例,结合订单业务的发展和系统的痛点,为你介绍,如何推进架构从单体到共享服务、再到中台的改造过程,保证系统能够不断适配业务的升级。
先说下项目背景。公司作为供应商,为大型餐饮连锁企业打造 O2O 交易平台,包括三方聚合外卖、自有小程序、App 点餐,这些线上用户的订单最终会落到门店的收银系统,由门店进行履单。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《架构实战案例解析》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(11)

  • Jeff.Smile
    老师,从功能上看,第二层的应用平台层是否可以省掉,直接由前端比如小程序或者app等渠道直接发起request调用中台呢?第二层主要作用是什么?

    作者回复: 前端直接调中台的服务不合适,主要有两个原因:
    1. 对于外部过来的请求,我们需要提供一些非业务性的功能,比如签名验证,协议和参数适配(外部的rest和内部的rpc)
    2. 中台只是提供基础业务功能,前端过来的请求是代表一个业务场景,需要同时用到多个服务的功能,比如前台下单,需要用到用户服务,商品服务,库存服务,订单服务等,这不合适直接在前端做功能整合。

    2020-03-13
    4
    1
  • Geek_kevin
    目前公司还没有共享服务,业务服务复用率低
    2020-03-22
  • noia_zhou
    想请教一下,对于简单的只涉及单个应用的查询或修改,网关层能直接调用共享服务吗?还是说必须是一个严格分层模式。

    作者回复: 可以跨层调用,比如根据订单ID查询订单信息,没有必要做多层包装。

    2020-03-22
  • 刘楠
    我们公司的模式有点像,可以学习下,按这个样搞下
    2020-03-20
  • AngryApe
    王老师您好,前面能力复用讲到的业务实体、业务流程、产品,但是这篇的架构图中只画了业务实体,没有出现业务流程对应的服务。我的理解中台更多的是业务流程的复用,是我理解的不对吗?

    作者回复: 业务流程偏定制,很难实现这个粒度的复用。
    对于典型的比较通用的流程,可以有对应的聚合服务实现流程,但一般这样的聚合服务数量不会很大,大部分流程的逻辑在应用里自己实现。

    2020-03-17
  • Alex
    用户中心估计是大家第一个要动手的共享服务吧
    2020-03-16
  • 老师,请教一下在文中这套系统中,用户的数据结构应该是什么样子,因为这里有小程序用户,有外卖第三方平台用户,那么用户系统的数据表是不是一张大表,包含了所有小程序和外卖用户需要的信息?如果是这样,后面在对接其他新业务用户,那么就要修改数据表扩展新字段,这好像不是很好,那么是不是可以认为内部有多个表存储这这些用户数据,然后订单里面在关联不同的用户id?

    作者回复: 用户基本信息表就一张,同一个用户就一条记录。
    然后有一个用户渠道表,一个用户一个渠道一条记录,比如小程序渠道,公众号渠道,支付宝渠道就有三条记录。用户基本信息表和用户渠道表1对多关联。

    2020-03-15
  • 孙同学
    https://www.processon.com/view/link/5e51378ce4b0c037b5f9d1e3 学习整理更新
    2020-03-14
  • 粗线条Jackie
    仔细研读了老师的每一期课程,受益匪浅。我们团队现有的Ecommerce平台,由最初的电话下单一体式应用,逐步演化成支持了PC Web、小程序、企业App和第三方外卖平台的SOA服务化架构。比对了老师的文中介绍,感觉目前我们的服务模块更像是一个"应用平台"+"业务中台"的结合体,供前端应用直接调用,向下与连锁门店和POS打通,为了适配业务的快速变化,现有服务模块的更新频次过高和模块间的紧耦合是比较突出的问题。后续,打算梳理和界定好业务的领域模型边界,把"应用平台"+"业务中台"尝试分离独立。

    有两个小问题,请教一下老师,望指点迷津:
    1. 老师文中提到了OMS系统,但在架构图中没有模块与之映射,通常情况下这个OMS与业务中台中的订单中心是同一回事情吗?

    2.由问题(1)引申,我某位在零售公司做架构的朋友,他们出于在天猫/京东开店的需求,采购了某外部商用的OMS产品进行私有化部署(需商用OMS公司做实施和二开),并通过阿里接口与企业供应链WMS进行了打通。他们目前围绕这个商用的OMS做了一些二次开发,调用OMS的开放API可以批量导入更多小平台订单和手工单。请问这种模式下,这个OMS可以理解为业务中台的订单中心吗?还是仅仅做为一个抓单汇集的工具,企业中台需要重新做订单中心的规划建设?

    3."业务中台"的边界划分,领域驱动设计(DDD)相关知识是否必需?老师后续课程是否有会有涉及呢?

    作者回复: 赞一个,能够结合实际做很深入的思考。试着回答你的问题:
    1. OMS是一个很重要的概念,说下我理解的OMS职责。当订单生成后,OMS就开始工作,比如对订单进行审核,决定订单流转到哪个仓库履行,交给哪个配送商进行配送,OMS是一个决策和调度中心,自己不具体干活。它和订单中心还不是一回事,一般说它在订单中心后面,会通过订单中心读取数据,并修改订单的状态。
    #2,这个OMS看起来更像一个订单中心,不知它有没有提供后续订单如何处理的决策。
    #3 业务中台,共享服务划分和业务紧密相关,DDD是一种方法和工具,可以使用它来划分,DDD概念拆的很细,给我们提供很清晰的分析思路,但也是有点繁琐,如果能够参考而不是照搬它那就最好。

    2020-03-13
  • tt
    老师,有一个问题,如果中台中的模块是由若干的不同的厂商开发的,要如何保证部署的独立性呢。一个基础服务版本升级,现有接口没有变化,增加若干新的接口,还如何组织测试呢?

    作者回复: 一般来说,中台总体上是由一个供应商开发,其他供应商可以基于中台做具体业务场景开发。

    2020-03-13
  • 阿男
    老师您好,如果是传统It公司,所做的系统没有这么大的体量,领导又想上个中台,有没有好的下手思路?

    作者回复: 可以根据当前c端最急需的,慢慢落地一个个能力,比如会员中台,营销中台,把前后台给打通。

    2020-03-13
收起评论
11
返回
顶部