软件开发架构-中台和微服务的基本概念，你知道吗？

今天准备再整理一篇文章谈下中台和微服务的基本概念。这篇文章我准备减少配图，重点是通过文字能够把关键的道理讲解明白。

首先还是看下中台的起源。

谈到中台一定会说到阿里提出的大中台小前台的概念，但是阿里中台概念实际来源于芬兰的一家游戏公司名字叫SupreCell，这家游戏公司5到7名员工就可以形成一个独立开发团队，称之为Cell独立单元细胞软件开发架构，这个独立开店决定做什么产品，如何推向市场，如何盈利。

但是如此小的团队如何做到快速孵化产品和变现？

这个核心就在于这个公司将游戏开发过程中常用的开发框架，引擎，公共的游戏素材，算法全部整合在一起，统一提供给前端的开发团队使用。

再打一个比方，就类似大家常说的航母作战群的例子。航母本身就是核心中台能力，可以通过起降，中转，补给等各种共性能力，但是航母本身笨重不灵活。因此围绕航母产生各种敏捷快速的作战编队，类似驱逐舰编队，战斗机编队等。

而现在一说中台，一定会谈到阿里提出的大中台，小前台这个概念。

还是举个场景来说，类似阿里这么庞大的互联网企业，内部组织架构，业务支撑能力极其庞大复杂。但是市场需求又需要你业务模式快速响应，IT应用快速迭代上线。比如你希望构建一个聚划算的APP，但是你发现这个APP用到的支付能力，物流配送能力，商品库，用户会员体系都可以用当前天猫淘宝电商平台已有的能力。你不用去重新构建。

你更多的是考虑聚划算这个应用的商业运营模式，团购会积分规则，折扣规则等。

再简单来说当前80%的能力你都可以复用底层已有能力，只需要考虑前端20%应用或个性化规则的定制开发，那么这种情况下才能够保证APP快速开发上线。

理解了这个后，就明白。

大中台就是各种业务共性能力下沉，这些能力可复用，要统一构建，然后开放给前端应用使用。而小前台就是前端应用做得尽量轻，尽量小，只考虑个性化内容，这样可以快速的将想法转变为产品上线，并敏捷适应变化。

注意，在谈中台这个概念之前，我们谈技术平台，PaaS平台，流程平台，集成平台这些概念比较多。平台这个词是一个技术词汇，也就是和业务无关的共性技术能力下沉到平台，提供给各类应用开发。

拿我们公司来说，平台部或技术中心就应该是提供类似微服务开发框架环境，流程引擎，4A，消息封装，缓存封装这些共性技术服务给各个应用系统开发使用。当你要开发一个新的业务系统的时候，最佳情况就是你只需要考虑业务功能和业务逻辑的实现，其它技术能力需求你都不需要考虑，统一由平台给你搞好，你只需要用即可。

而中台的本质不是技术能力，而是共性业务能力下沉。

当然你也可以理解为对于遗留架构，遗留IT环境下，已有的各种业务能力抽象出共性可复用的部分，统一朝上以服务化方式提供。谈到这就和经常谈的SOA架构思想完全一致。

再拿做财务类系统来说，我们可以构建一个财务中台。

因为发票管理，资金支付，预算管控，成本核算等这些能力也是可以复用的。我们可以去构建一个财务中台统一提供这些能力。

当有了这些能力后，你会发现你如果要新开发一个SaaS运营的报销云平台，如我们自己的夸父云，你会发现开发起来很简单，也很快速和敏捷，大的业务能力都是现成的，你需要考虑的个性化内容已经不多。

如果仅仅是技术平台复用，比如4A，流程引擎，开发框架复用，那么开发一个完整的报销云平台工作量并没有降低多少。因此构建中台目的是为了前端小团队作战，快速地开发前端应用，这才是中台价值。

当前中台业界一般会划分为业务中台和数据中台，也有将技术中台纳入的。但是对于技术中台这个词不太好，技术中台最好还是叫技术平台。中台本质就是业务能力提供，而非技术能力。

数据中台理解方式一样，即共性数据能力的下沉或聚合，同时聚合完成后以开发的数据服务方式提供给业务应用使用，注意不是提供给BI等辅助决策分析，而是实际业务协同中使用。举个最简单的例子，你在电商平台购买一个商品后，马上会附带一个推荐明显，告诉你可能还需要哪些商品。这个推荐信息获取实际来源于数据中台的能力。

也就是说数据中台的能力不仅仅是支撑决策分析，更加重要的是实时或准实时的支撑业务和运营，我们经常听到的业务能力数据化，数据能力业务化，或数据反哺业务就是这点。

接着谈下微服务

微服务简单来说就是传统的单体应用要拆分，大拆小，拆分后各个微服务之间本身有接口交互，这个接口也用标准轻量的Http Rest API接口交互。

为何要拆分？

其一是传统业务系统的扩展性方面去考虑。最早的应用扩展很简单，就是做集群扩展，数据库集群，应用中间件集群。但是发展到一定阶段后集群扩展出现困难，特别是DB数据库不容易集群扩展。

这个时候就出现两个关键点，一个是对业务功能进行纵向拆分，一个是对数据分区进行横向拆分。比如一个供应链系统，那么可以拆分为供应商，订单管理，库存管理等多个微服务，每个微服务就是一个小系统。这个是纵向拆分。当然也可以是数据分区横向扩展，比如这个供应链系统有母公司+3个子公司用户在用，你可以将不同组织的用户路由到不同的数据库分区上面去，这样数据库压力本身也可以降低。

而微服务要谈的则是业务功能的拆分，纵向拆分。

但是这个拆分不能只拆分业务功能，如果数据库还是一个DB，那么DB数据库的性能压力并没有降低下来。而且微服务也无法做到完全意义上的独立自治。因此理想微服务思路是数据库也要进行拆分，不同的微服务都有一个自己Owner的数据库。

也就是微服务从前端应用到逻辑层到数据库完全是独立的一套，高度自治。

在微服务发展中又出现一个关键概念即前后端分离开发。

因为微服务开发当前一般都推荐前后端分离，比如后端微服务只是提供API接口服务，而前端开发人员是调用API接口服务，通过API接口进行前后端的解耦。

所以很多人会将微服务理解为业务逻辑层或领域层，这个理解实际不准确。一个完整的微服务本身可以存在前端+后端+DB，前端，后端+DB的多种呈现方式。

微服务不是特指软件开发里面的业务逻辑层。

其次微服务这个概念应该叫微服务组件更合理，微服务本身不是指微服务API接口，而是微服务组件+微服务API接口。

其二是从本身快速的交付和应对变化考虑。微服务本质仍然是组件化和服务化，在原来大单体情况下，经常会持续修改一个变更，导致业务系统其它功能模块功能受到影响情况。而微服务拆分后，各个微服务都可以独立开发，构建，测试，部署上线。

管理的单位已经到单个微服务的粒度。

那么如果一个需求变更出现，只需要修改和变化的微服务接口。比如一个供应链应用中订单创建逻辑变更，那么只需要修改订单中心这个微服务。包括部署的时候你会发现其它供应商中心，库存中心这些微服务根本就不需要部署。也不需要重新测试。

同时微服务粒度更小，编译构建，交付部署都更加快，更加适应敏捷应对变化需求。

所以我前面谈了这么多，微服务重点是在于如何拆分微服务，如何设计粗粒度的API接口，这个是微服务架构设计的关键内容。其次才是微服务开发框架和环境。

微服务开发框架和环境

当前主流的SpingCLoud微服务开发框架环境，在上半年也准备了相关的基础培训。今天再把里面的一些关键点讲解一下。

首先解释下服务注册中心，简单来说A要调用B的接口，传统方法你可能觉得很简单，之间将B的调用地址写在A这边的一个配置文件就搞定。

但是你发现B这个微服务部署下去后是一个集群，本身集群节点还在动态扩展，那么A如何去调用B，如何确保调用到的B的某个节点是可用的。其次，当微服务和容器技术，DevOps自动化部署结合的时候，你会发现部署都是动态的，刚开始你都不清楚会部署到哪个容器里面去，也不知道部署下去的IP地址，你如何调用？

因此需要注册中心解决这个问题。

A去问注册中心，拿到调用B的地址，A在拿到B的地址后就和注册中心没有关系了，A直接点对点发起对B的调用。真正调用的时候消息数据流没有走注册中心，即使注册中心宕机了也不影响实际的调用过程。

因此注册中心下的微服务间调用是一种去中心化的架构模式。

其次谈下网关，网关本身也有服务注册功能，有了注册中心为何还需要网关，网关本质仍然是一种路由代理。类似Ngnix也可以当最简单的网关使用。

在传统微服务下，各个微服务间往往可以采用增加注解和声明式调用方式，像调用本地API接口一样去调用远程其它微服务提供的API接口。

但是当你有一个前端移动APP的时候，你发展采用的是VUE框架，或其他前端框架，这种前端框架没有办法附件微服务组件的本地SDK代理包，业务服务声明式调用，只能够提供Http地址路径调用。因此必须通过网关接入来进行代理。

通过网关接入的微服务，注意所有的服务请求消息数据流全部要通过网关，网关本身和传统ESB总线在架构思路上一致，也是一种中心化的集成架构模式。当然也正是因为中心化模式，可以对消息流进行拦截，也方便后续在网关上间安全，限流熔断，日志审计等能力扩展。

最后再简单谈下API接口驱动下的新开发模式。特别是在当功能开发前后端分离情况下，更加应该推荐API接口驱动开发模式。

接口驱动开发的核心思路就是在微服务开发过程中优先定义和设计接口，确定API接口模型和接口契约，然后后端，前端，基于同样的接口标准并行开展工作。

一个新需求或变更需求过来后，重点就是需求，前端开发，后端开发，测试几方要在需求讨论清楚后，快速的明确和定期清楚接口契约。

接口定义清楚后，可以生成相应的代码框架或开发框架，前端和后端基于同样的开发框架进行接口开发工作。对于后端人员应该优先实现接口，再实现非接口部分内容，后端人员实现的接口可以自己进行单元测试。而对于前端在进行开发的时候，由于有了接口契约，可以通过Mock的方式提供模拟接口数据，方便进行前端功能开发和测试。

只有这样，才能够真正做到全并行开发和开发后的集成工作。

最后再来思考一下常见的问题

中台架构中的前台应用是否就是开发框架中的前端，注意不能这样对比，中台架构中的前台应用本身同样存在前端，领域或业务逻辑层，后端数据库能力。

中台和微服务什么关系？实际本质没有必然关系，只是中台你不能按照一个大的单体系统来建设，如果这样的话这个系统异常难以维护和扩展，因此场景的中台建设方法是按微服务思路进行拆分了建设，如阿里中台里面的用户中心，订单中心，支付中心，库存中心等各个中心，每个中心可以理解为独立的微服务。

也正是整个原因中台可以理解为SOA思想和微服务思想的一个融合。

微服务和前后端分离什么关系？实际上也是没有必然联系，你前后端分离开发，不一定就进行了微服务拆分，而进行了微服务拆分也不一定必须前后端分离开发。当然如果你是中台和微服务思想融入，那么一定是微服务+前后端分离模式的。

微服务是不是一定是去中心化架构？注意，如果一个微服务不和外界打交道，也没有类似移动APP等前端应用，那么可以做到完全去中心化。但是存在前端应用和对外协同的时候一般涉及到微服务网关或API网关，网关本质是中心化的架构模式。所以微服务不能彻底地说完全去中心化，但是可以将微服务注册中心本身是去中心化的。

每个微服务对应的数据库是否一定拆分？注意我在前面文章也提到，要引入一个业务域的概念，一个业务域里面还可能拆分多个微服务，但是数据库不要再拆分。类似财务共享项目，报账，预算，资金管理是业务域。但是报账本身还拆分为多个微服务，这些微服务对应的数据库不用再拆分，以减少带入大量的分布式事务问题。

为何当前很多中台建设不成功？简单来说如果你是从0开始建设中台，那么你如何清楚后续有哪些业务场景，业务模式需要支撑，也就是需要下沉哪些共性能力你并不清楚，包括对于中台规划，微服务划分整体方法论也不清楚，中台建设不是一个技术问题，而是一个业务规划软件开发架构，组织架构重塑的问题。再者，如果是遗留系统改造来构建中台，那么更多的是偏传统SOA架构思想构建共享服务平台，而非全新的微服务架构下的中台。就当前很多企业实际情况来看，第二种方式往往更实际。