导读:本系列文章将经过介绍一个真实大型企业数字化转型过程当中遇到的层层困难,以及微服务架构如何落地,涉及到的各类真实的解决方案。不空谈,不泛谈,讲事实是本系列文章的原则。
企业数字化转型是近些年来很是火热的话题,而企业作数字化转型的必经之路就是微服务架构升级。微服务架构升级广泛都会说起DevOps、容器化、API网关、微服务治理、AKF扩展立方体等技术概念。在大型集团企业微服务架构升级的过程当中,每每会遇到如何扩展已有微服务应用,来适应不一样组织之间业务的多样性和集团的总体管控性的问题。针对这个问题,国内互联网行业的先驱阿里提出了“厚中台,薄前端”的概念。但若是实现呢?本文经过描述一个大型集团企业微服务架构升级的过程,如何经过微服务扩展来实现企业数字化转型的大中台业务。
第1步选定原型开始微服务之旅
大型企业在微服务架构升级的过程当中,通常会先选一个A组织(原型组织)为表明,基于这个A组织及企业数字化转型的目标,开发出一套原型产品,并在A组织内不断的优化和改进。这个过程,特别注重的是微服务架构的技术升级,例如须要引入微服务治理框架,DevOps平台、分布式事物等等。作出来的产品业务上和已有的系统没有什么本质的区别,只是咱们用了一套高大上的微服务架构。这时候企业的组织架构并无任何改变,由A组织负责的研发部门负责研发了一套基于微服务架构的新产品,这个研发组织负责这几十个微服务的开发和运维工做。老板以为这套系统很不错,这套产品基于微服务架构作的,那就开始全集团推广吧,让其它组织也用上这套系统,享受一下数字化带来的便利。
第2步产品推广微服务架构下如何“二开”?
A组织的信息化部门开始兴高采烈的去给B组织推广他们开发的这套产品,说这套系统是基于如今最前沿的微服务架构实现的,能够如何改进大家现有的流程,减小成本等。B组织以为很不错,那也试用一下吧,可是咱们在某些地方和这套产品的现有业务有点差异,能帮忙改一下,支持一下咱们的特有业务吗?A组织为了推广产品,爽快的答应了。可是在改的过程当中,发现原有的业务流程和代码和本身的一部分特有业务关联的比较紧密,修改起来要费很多功夫。为了推广给B组织使用,仍是硬着头皮给改完了,这其中带来了大量的业务代码修改及回归测试。
老板看着产品在B组织推广的也不错,那继续推广给其它组织使用吧。A组织在继续推广给其它C、D……组织的时候,发现都存在B组织相似的问题。他们80%的业务和A组织相同,可是有20%的业务有本身的特点。其它组织也要求A组织修改一下原有的微服务,来支持他们的特点业务。这时候A组织不干了,说大家都有本身的信息化部门,也有研发人员,大家基于我如今作的微服务去修改吧。那么问题来了,其它组织如何“二开”呢?把整套产品的源码都共享给其它组织,他们基于这套源码修改及开发本身的新产品,而后独立部署。这时候老板站出来不干了,大家这样搞下去,和原来的软件模式有什么区别,咱们微服务架构的优点去哪了,整个企业的集中管控如何作?这时候你们又想起了作数字化转型的“厚中台,薄前端”的业务架构,咱们的业务中台在哪里呢?如何实现业务中台?
第3步微服务扩展实现业务中台的利器
接下来我么该聊聊什么是微服务扩展?如何利用微服务扩展实现业务中台?
核心微服务 - 流程分解
功能域:能够简化理解为对应一个微服务
域服务:对应一个服务接口
能力:对应服务接口上的一个具体方法
扩展点:服务接口方法实现中插入的一个插件(接口)
以订单建立过程为例来谈谈什么是微服务扩展,以及如何用微服务扩展来实现订单的业务中台。订单建立的过程实际上是一系列功能的组合,如库存校验,商品价格计算订单校验等。每一个功能都对应到一个领域服务,如库存校验对应到库存领域服务,商品价格计算对应到价格领域服务。每一个领域服务都会提供一些核心的能力,如库存领域服务提供库存查询、校验、扣减等能力。而每一个能力能够提供一系列的扩展点,来根据不一样的业务走不一样的扩展实现。如库存查询的能力能够提供库存策略的扩展点,根据业务需求能够实现商品级库存,批次库存等的扩展实现。订单建立流程以及抽象出来的各类功能域及能力就是咱们须要的业务中台,而业务的差别化实现能够根据业务中台提供的能力扩展点去实现本身的业务扩展。下图是微服务扩展的基本概念图。
微服务扩展 - 基本概念图
那么须要如何抽象出业务中台呢?
1.首先须要梳理微服务的主业务流程,以及各组织之间可能存在的差别点。
2.根据梳理出来的主业务流程及可能存在的差别点,定义出上述的功能域、域服务、能力及扩展点。
3.业务基于现有的扩展点增长扩展实现,实现本身的个性化业务。
上述一、二、3步骤是一个按部就班的过程,不可能一蹴而就的。由于企业本身的业务流程会随着市场的变化而不断的变化,随着业务的变化,可能会新增一些扩展点和不一样的扩展实现。前端