我的同事小A是一位后端研发工程师,最近在抱怨需求实在太多。
业务方1要求在给商家返回的订单信息中增加库存剩余情况;
业务方2要求在给用户发放权益前增加对用户积分的判断;
业务方1又要增加这个订单,如果参与促销的话,再给商家返回单次促销收益情况;
业务方X。。。
我跟小A聊了下。
系统是不是已经按照微服务的理念去实践的,是。
那么一个后端系统是不是下面这样的交互方式?
图1
是。
我说,需求其实就两种。
第一种:从多个服务中聚合数据来为用户提供非规范化的数据(比如,库存信息、单次促销金额)。
第二种:利用底层的功能来提供专门的业务逻辑(比如,先增加积分判断再去发放权益)。
图2
我们一起,又想了想。
是,就这两种。
随着时间的推移,这两类需求会引起服务出现层级结构的分化。靠近系统边界的服务会和某些服务交互以聚合它们的输出——我们将这种服务称为聚合器;还有些专门的服务会作为协调器,来协调下层多个服务的工作。
那为什么我们的后端研发人员总是感到需求很多,那么多呢?
因为,纵然种类只有两种,但是每个种类下的需求数量,需求个数确实多,所以我们的后端研发人员非常辛苦,说需求多也是没有错误的。
有没有什么理论的方法,指导一下,改变改变么?
系统多,需求多,如果人又少的情况下,我们更应该注重建设业务中台能力。
第一步,前后端分离,前端开放出去。
第二步,聚合共性业务流程能力,个性化业务逻辑开放出去。
通过合理的成本转移,共享、共建。
我在上周思考系列文章中,画了一张图,也是在阐述这个逻辑。
图3
只是在这个过程中,对开发人员的习惯和方式都会形成挑战,甚至有人会觉得这是阻碍他们开发,这些刚开始都是可以理解的。
OOA、OOD、OOP,常年游走在这些之外,突然又被拽到这个路径上来,难免会不舒服,甚至自己早已都忘记了OO的能力,尽管常年在用Java这样一门OO的编程语言,却一直写着函数式代码。
说到这里,有人,会发起挑战。
你说的这样轻巧,共性能力聚合、个性能力开放,就问你,一个简单的问题。
来了一个需求,你到底是在原来的服务中增加,还是新开一个服务?
好,我们还是以《微服务实战》中的一个例子来说明。
做了一个在线投资工具,用户要提交订单,然后把订单提交到交易市场交易,因此需要一个订单管理的服务。
那么,订单管理里面,就包含了记录订单的状态和将订单提交到市场两个功能。
这两个功能都在一个服务里面,我们要不要继续让它们保持现状,凡是跟订单管理相关的需求,都放到这个服务里面,还是我们需要考虑,有的需求,要新开一个服务呢?
回答两个问题。
1、驱动市场操作这个领域变化的因素是什么?
答:不同的市场规则、新开发的市场
2、驱动订单管理这个领域变化的因素是什么?
答:产品订单的类型、交易的账户
因此,你会发现,这两个领域并不会同时变化!但是,它们却放在了一个服务里面。
那么,每次来了任何一方的需求,另外一方都要被代码牵连,至少你测试的时候要都想着它们吧。
图4
你说,需求来了,我们应该放到一个服务里面,还是新开一个服务呢?
答案就很明显了吧。
你说,怎么做能力聚合呢,共性的能力,要区分它们的修改原因,修改原因不同,则不建议把它们放到一起,可以形成多个微服务,而这些微服务又共同组成了“业务能力的聚合”。