首页
学习
活动
专区
工具
TVP
发布

微服务的层次结构

假设有这样一款专注互联网医疗的产品,有医生,有患者,对应的有医生使用的APP和患者使用的APP,并且两款APP都支持通过手机号码注册,找回密码等常见功能。医生提供付费咨询服务,按天收费,患者可以自由选择购买多少天的服务,在服务有效期内,患者以在线提问的形式进行咨询,医生则会及时高质量的进行专业解答。除此之外,为了更好的推广和运营,还建设了一个运营平台,运营人员通过分配的账号即可登陆,开展日常的运营管理工作。

当然该产品本身涉及的业务对象和业务逻辑要比上面提到的复杂何止10倍,因此技术选型采用的是以dubbo为核心的微服务架构。本文为了突出主题,刻意的裁剪了其他干系不大的繁枝茂叶。

案例介绍完毕之后,接下来我们将尝试通过对案例的剖析,试图回答以下几个问题:

1>根据案例的描述,该产品可以识别出几个微服务?

2>如何定义这些微服务之间的层次结构?

3>如何鉴定一个业务对象应该被当作应用层的对象还是某一个微服务中的一部分?

首先我们来回答第一个问题。

根据上文的案例描述,涉及到的业务对象有医生,患者,涉及到动作有短信发送,购买咨询服务。按照业务对象来识别微服务,那么我们可以设计出医生服务,患者服务;同时,结合动作来识别微服务,我们可以得到消息服务,订单服务,支付服务,以及咨询服务,当然延伸出来的还有验证码服务。

那么如何定义这些微服务之间的层次结构呢?

要回答这个问题,我们不妨先来看看下面的业务流程。

医生注册流程=医生填写基本信息——>发送验证码——>检测验证码的有效性——>创建医生账号

患者注册流程=患者填写基本信息——>发送验证码——>检测验证码的有效性——>创建患者账号

患者购买咨询服务流程=查看医生基本信息——>挑选服务——>下单——>支付——>给医生发送新订单短信通知——>给患者发送购买成功短信通知

很显然,一个完整的业务流程可能涉及到多个业务对象之间多次交互才能完

成。

根据上面3个业务流程,我们不难发现,发送验证码和检测验证码的有效性重复出现的几率很高,同样给医生发送新订单短信通知和给患者发送购买成功短信通知也是重复度很高,并且与验证码在短信发送方面也是功能重叠,而且,发送短信和验证码功能几乎独立于具体的业务场景,甚至独立于行业领域,因此,可以将验证码服务和消息服务作为服务体系的最底层,姑且称之为“技术组件服务”。

除了这两个技术组件服务之外,医生服务和患者服务也是可复用性较高,但还是局限于互联网医疗这个行业领域,因此这一类服务可以放置在服务体系的第二层,即“共享业务服务”。

此外,咨询服务则针对医生提供付费咨询这一具体的业务功能,本身涵盖很多具体的业务规则,譬如只有在购买的有效期内医生才提供服务,如果患者购买了服务并发起咨询,医生在约定的时间内有没及时响应,则自动提前结束并全额退费......很显然,这一类服务的可复用性较低,因此我们可以把这种面向具体功能的服务排列在服务体系的最顶层,即“功能服务”。

因此,在服务体系中,我们抽象出“技术组件服务”,“共享业务服务”和“功能服务”三层。当然,有一些服务本身通过组合其他服务的能力,并向外暴露更粗粒度接口的服务,因为他们也是面向具体的业务功能,所以,也可以归类到“功能服务”这一层次。

在这个层次中,“技术组件服务”处于最底层,一个技术组件服务可以以DAG的形式调用另一个技术组件服务。

共享业务服务之间不能互相调用,但是可以调用下一层的技术组件服务。

最上层的功能服务之间也是不能调用,但是可以直接调用下一层的共享业务服务,或者跨层调用最底层的技术组件服务。

确定好服务层次体系之后,我们将服务代入上面的业务流程,以患者购买咨询服务这个流程为例。

那么这个完整的业务流程的实现应该放到社么位置呢?很显然,当然是应用层。

那么还有一个问题。我们在案例描述中特意的提到了“运营人员”这个业务对象,可是在后面的微服务识别中,却再也没有提到,是遗漏了吗?其实不是遗漏,而是特意为之。

首先,我们要思考一下运营人员是否需要跟医生/患者一样,作为服务体系中的共享业务服务中的一个呢?或者说到底哪些业务对象适合放到服务体系中呢?

条件有两个,一是可复用;二是可运营。两个条件至少满足其中一个,才有资格进入服务体系,否则更明智的做法就是放到具体的应用层了。

可复用比较好理解,就是在多个业务场景或功能中都会用到的能力。因此,上图的服务体系中,技术组件服务和共享业务服务都满足这一点。

那么什么又是可运营呢?运营的本质是通过一系列的手段让一些业务对象的规模增长,从而使得公司的利润获得增长。一个可运营的对象,他的某些指标必然会影响公司的收益。

按照这个准绳,我们会发现医生规模的增长,会导致平台的影响力增长,吸引更多的患者前来咨询,从而正向影响公司的收益,因此医生是可运营的,所以医生可以被识别为服务。同理,患者也是一样。那么运营人员呢?首先运营人员只是公司内部员工,他是运营者而不是运营的目标,他们规模的增长对公司的利润没有很直接的必然联系,没有人会关注这个月新增了多少运营人员,也没有人会去分析运营人员的使用习惯,因此运营人员不是可运营的,因此不适合作为服务体系中的一部分,更适合作为运营平台这一款应用独有的业务对象。

说到这里,经验丰富的开发人员也许会提出,其实运营人员跟医生和患者一样,都可以通过手机号码注册,登陆。为什么不抽象出一个账户服务,并把他们三者的账号管理功能复用起来呢?

毫无疑问这是个非常值得深究的问题。

确实,医生/患者/运营人员都有账号和密码,使用各自的应用之前都需要进行身份验证和会话验证。从提供技术复用的思维出发,确实可以抽象提炼出账户服务和会话服务,其中账户服务负责存储账号/密码,会话服务负责验证一个会话是否有效。但是原本的医生服务和患者服务仍然必不可少,只是稍微瘦身了一点而已。譬如患者服务除了账号管理和会话验证的功能之外,还需要提供患者健康资料,饮食爱好,过往病史等信息的维护能力,医生服务也有职称信息,履历信息等需要维护。此外,针对患者服务和医生服务的运营策略也是不一样的,因此,无论是从业务支撑还是技术解耦的角度出发,医生服务和患者服务必然是分离的,而且必不可少的。

还有,账户服务和会话服务只是从技术复用的角度提炼出来的,而非业务关注的对象。从支撑业务运作来看,有没有账户服务和会话服务其实无关紧要,缺点只是复用性不够,仅此而已。

因此,在划分微服务时,很清醒的明白你是站在业务运营的角度,还是已经坠入技术思维的惯性圈,至关重要。

综合上述分析,我们的服务体系从应用出发,结合面向业务和面向技术两个维度,套用目前业界流行的前台/中台的理念,可以得出应用层——>业务前台服务——>业务中台服务——>技术中台服务这样的层次体系。其中业务前台服务=功能服务,业务中台服务=共享业务服务,技术中台服务=技术组件服务。业务前台服务+业务中台服务+技术中台服务构成了完整的服务体系。

而可复用和可运营决定了一个业务对象是否可以纳入服务体系还是只能驻留在具体应用中。

最后,我们利用上面的服务体系来分析一下雪松社区的用户体系。

超云平台WebPC的登陆用户(假设仅仅是管理员,下同),C端APP的用户,B端APP的用户(管家),员工哪些该纳入服务体系,哪些该作为应用特有业务对象呢?

首先,C端APP的用户无疑是可复用的,而且也是可运营的。C端APP的用户规模一方面决定了现在开展的工作业务价值,另一方面也会影响未来的战略规划,业务重要性不言而喻。他们与具体的行业领域相关,但与具体的功能场景无关,因此可划到业务中台服务。

其次,B端APP的用户显然也是行业领域相关,但与具体的功能场景/业务规则干系不大,其他终端(如C端)也需要访问B端APP的用户信息,而且B端APP的用户规模,活跃程度是运营人员的一项重要绩效指标,因此划为业务中台服务很合适。

再次,员工这个业务对象也是行业领域相关,与特定的功能场景干系也不大。但是物业管理中物业巡航,员工绩效等业务功能都需要员工信息,因此可复用,但是运营潜力不大,也可以纳入业务中台服务。

最后,超云WebPC登陆用户,行业领域相关,没有其他应用需要使用,因此可复用不高,而且不可运营。因此划分为超云WebPC这个应用的应用层较为恰当。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180806G1H2P900?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券