架构思维第二篇

Posted hanruikai

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了架构思维第二篇相关的知识,希望对你有一定的参考价值。

业务架构

业务架构的特性,通过特性基本上就知道业务架构的大体框架。笔者通过 x、y 数轴加以说明,因为业务要体现出业务流程的流动性和业务的层次性,下面就说明这两个特性:

 

  • 业务的流动性:其实这是业务生命周期的体现,从产生、拥用、使用可以看出业务的流动,这是横向的。

  • 业务的层次性:笔者一般习惯用场景层、产品功能层、领域模型层、依赖层来画业务架构图,这是纵向的。场景层依赖下面的产品功能层,多个场景很有可能对应一个产品功能,产品的功能又是由领域模型来支撑的。

 

 

 

业务架构方法

业务架构的方法还是从系统性思考、分解、抽象、模式这四点具体说明。

 

  • 系统性思考:站在业务的角度,分析业务与业务之间的关联性,如优惠券业务,它就涉及到人群选择、风控安全、活动、会场、优惠、交易、凭证等,思考系统之间的交互和依赖关系,以及依赖系统要提供的哪些能力。

  • 分解:系统性思考让我们的目光放得更广,整体上考虑整个业务的运转,此时还没有想业务的具体流程,只是知道有,并不深入考虑如何做。分解就不一样,它聚焦的是业务本身是如何运转的,一般业务由几个主要的流程组成的,每个流程又能往下继续分解出细的流程,分解的目的是为了找出业务的要素,此时的元素都是孤零零的。

  • 抽象:分解不是我们的目的,通过分解找出的业务要素,此时要经过一定的抽象才能形成我们的领域对象,因为分解找到的业务要素很多是可以合并归类的,这样就大在减少了业务要素,也降低了理解的复杂度。

  • 模式:通过业务架构的特性,按照场景层、产品功能层、领域模型层、依赖层这四层画出业务架构图。

优惠券业务举例

 

系统思考

如何进行系统性的思考,笔者建议可以使用反推法,假设已经有了这项业务,它应该是如何运转的、涉及到哪些人,实际上这个过程就是推演的过程,基本上能把整个交互都考虑清楚,业务实现起来基本上没问题。

 

  • 用户:用户有优惠券,下单会使用优惠券,涉及到交易和优惠。

  • 系统:涉及到建券、发券、核销券、退券

  • 建券与我们优惠券系统关联最大,也即是我们要做的事。

  • 发券,发给谁呢,肯定不是遍地撒网,现在基本上是精准营销了,要知道哪些用户是活跃用户,所以涉及到算法推荐;除了发给谁是我们关心的,营销还有一个比较核心的点,就是营销模式,你怎么能吸引用户,这就涉及到会场、活动,这些玩法是非常关键的。

  • 核销券:优惠券券在什么条件下可用(满 100 元减 10 块)?订单价格如何计算出来的?

  • 退券:退款了,券要不要退回?

所以,经过上面的分析,初步涉及到的业务方就已经出来,此时还只是一个粗略的关系,这个过程可能需要几轮不断的讨论最后才成型

 

业务流程

业务流程是客观存在的,而且任何一个业务在一定的时候内应该有一条稳定的业务流程,这个业务流程是符合人的认识的,具有严谨的逻辑性。怎么理解呢?一个业务要运转起来,不可能是一团糟,一定具备流程,而且是人能接收的,否则你设计一个反人类的业务产品出来,注定是失败的。拿优惠券来讲,根据它的生命周期,很容易想到它的主业务流程:建券、发券、用券、退券。

分解和抽象

上面是一个大的流程,还要对各个流程再进一步细分,分解成更小的子流程,每个子流程中包含一系列的步骤,其实这个步骤就是不断深入地过程,同时对业务的理解也不断加深,多问几个为什么就深入了。

 

  • 建券:这个券包含了哪些内容?

  • 发券:给谁发?发券的条件是什么?

  • 用券:什么条件下能使用优惠券?用券涉及到哪些过程?

  • 退券:什么场景下会退券?

 

随着深入的过程,整个业务的细节也浮现出来了,现在就是要抓业务要素,这个要素可以通过每个阶段的产物来看。建券的产物是券批次,发券的产物是券实例,用券的产物是用券明细,退券的产物是退券明细。

 

接下来就是抽象的过程,这个抽象的过程就是对已找出的产物进行抽象。券批次包含:券类型和券门槛限制两个重要的信息,用券明细和退券明细统一抽象成券明细,优惠券又与活动强相关,所以也把券活动放进去。

业务架构

 

接下来就是画整体的业务架构图了,按照场景层、产品功能层、领域模型层、依赖层来画,画业务架构图要体现两点出来:业务流向和产品功能。通过下面的图可以直观地感知业务流向是什么(即是蓝色区域,建券、发券、用券、退券),通过分层可以清晰地看到可以支持的场景有哪些,场景依赖的产品功能有哪些,业务的领域模型是什么,依赖的业务又有哪些,真正好的图能做到一图胜千言的效果。

 

笔者喜欢的画法是"一主两翼",主体的部分就是上面讲的分层,两翼是运营平台和数据平台,这样很直观、简洁。

 

业务与业务隔离

 

业务与业务的隔离需要有一个标识来唯一标志,阿里有的团队叫 bizId,在我们团队是通过 productId(业务线 Id)来区分。标识说起来简单,但它只是第一步,隔离的表象就是通过业务线来区分。思考一个问题为什么要实现业务之间的彼此隔离?

 

  • 业务自身需求:这个很好理解,不同的业务有自己的特点。

  • 业务之间的互不影响:隔离的目的就是为了互不影响,将变化的东西缩小到业务线内,不可能改动一个业务线的需求,结果把其它业务线影响了。

  • 业务的可扩展性:平台型的业务有一个最大的特点是要较好地支持可扩展性,往大的方面讲,新接入一条业务线的改动有多大、往小的方面讲,对于某个业务线内的需求改动又是多大,比较好的状态就是具备可配置,稍微配置一下,一个新业务线就接入,这是我们最想看到的结果。

 

通过 productId(业务线 Id)这个唯一的业务身份串起整体业务,在业务处理过程中,可以知道这个业务线需要的具体业务策略和处理规则。

 

业务与业务的隔离体现了业务之间的变化和独立性,所以就产生了业务与技术(平台)的隔离。

 

业务与平台的隔离

 

业务与技术(平台)的隔离体现了变与不变的关系虽然这句话被很多人讲过,但不同的系统实现的策略不一样。平台型业务一般要解决 80%以上的共性问题,20%左右通过开放来实现

业务与技术(平台)的隔离不像业务与业务之间的隔离那样,两个业务之间没有交集,业务与技术(平台)之间是有交集的,这让人听起来有些蒙,下面细细分析。

  • 不同业务线之间有一条共性的业务流程:虽然不同的业务线产品之间有各自不同的点,但它们之间有一个明显共性的业务流程,这个业务流程是业务的生命周期,就好比类与对象之间的关系,本质是同一类事物,不同的对象好比不同的业务线产品,具体的实现上有些差异。在优惠券中,核心的业务流程就四个:建券、发券、用券、退券,不管什么业务线接入,它都遵守这条固定流程。

  • 业务变化的是子流程中的内容:不同业务线产品的不同之处体现在哪里?体现在业务细节上,这个是变化的,如业务的准入条件不一样、业务规则不一样、有的子流程中某一个处理步骤不需要…,这些是变化的部分,需要把变化的部分抽象出来并封装变化。所以,不变的是业务大流程,变化的是业务实现细节

  • 业务与技术(平台)的隔离理解的二重性:有些人理解业务与技术(平台)的隔离就是业务的实现不依赖于技术,比如数据要怎样存储?服务治理用什么框架?…这些说的是对的,它本身没有错。而我理解是有两重含义:一就是如上面所说的,业务的实现不依赖于具体技术,偏技术选型,这是常识;二是领域层的可扩展性,前 2 项已经说了业务的共性和变化,这个就是体现出应对变化的策略,尽管不同的系统有不同的具体实现,但总的原则是平台要能识别出这些变化,并能应对这些变化。

业务与技术(平台)的隔离体现在共性和变化的隔离,把变化的部分告知平台、实现开放出来,所以说它们是有一定交集,这个交集就是应对变化的部分。它涉及到技术方面,所以在技术架构中会单独拿一篇来讲。

 

业务能力地图是领域模型的进一步扩展和延伸,领域模型偏静态的表达领域对象和领域对象之间的关联关系;而业务能力地图是动态的表达业务执行流程是什么。领域模型是基础,业务能力地图是进一步的扩展,一个表达有什么,一个表达怎么做,一动一静,可以更好的理解业务和业务流程所涉及到的核心步骤。

业务能力地图是在领域模型的基础之上进一步扩展,可视化地表达业务流程

 

业务mock能力

 

业务 mock 能力是指 mock 用户数据方便排查问题,排查问题的第一步是重现问题,尤其是在端上,可能在某些条件下展示有问题,用测试数据又没有重现这个问题,如何来做呢?可以通过 mock 用户的信息来展示数据,说白了就一句话偷天换月,在最底层的查询时,把用户信息置换掉。举个例子,用户在下单时发现有些优惠券没有展示在列表页中(实际上是有些优惠券不满足订单条件,如满减券、限门店使用等),用户向客服反映,客服再向技术支持人员反馈,技术支持人员再往具体的开发反馈,这个链路就很长了。如果客服同学使用这项 mock 能力,完全可以通过 mock 用户数据来当前的数据是怎么展示的,再看用户所有优惠券,对比优惠券的限制规则就能知道哪些优惠券不能使用,这样就可以快速响应用户问题。

 

使用这个 mock 能力时,有一点需要考虑的就是数据安全,并不是所有的行为都可以 mock,一般来讲只有读场景下才能 mock;还有一点需要注意的是全链路 mock 范围,只有在指定的接口上才能 mock,不能直接从导购链路一路往下 mock,只会在最底层的业务接口上进行 mock,否则全链路数据都被置换了。

 

mock 主要方便问题重现和定位

 

业务监控

在大公司,通过日志采集、清洗、实时统计,可以看出当前业务的处理情况,有同比、环节的数据,如当前下单率是多少,通过监控这个指标可以看出业务是否正常,如果下单率明显下跌比较厉害,大概率是哪个链路上出了问题。

没有业务监控的系统对业务的运行状况一无所知

 

原文地址:

https://www.infoq.cn/article/G*DTr9RmIyh0hR59ZTug

 

以上是关于架构思维第二篇的主要内容,如果未能解决你的问题,请参考以下文章

架构思维第二篇

架构思维第二篇

云原生第二篇--容器管理工具 Docker生态架构及部署

系统架构分布式消息队列

java多用户商城系统架构之第二篇

大型网站架构系列:分布式消息队列