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