概念模型为何如此重要？

最近我思考比较多的一个词就是概念模型，不管新知识的学习，新事物的认知，新领域的快速切入还是面对新问题的快速分析和解决，认识和理解概念模型都是相当重要的一个步骤。

概念模型本身是我们认知事物核心框架和基础逻辑的自我可理解的最简模型。

这里面有几个关键点，其一是对事物形成基础认知，其二是最简和最容易模型，其三则是对我们自己最佳适用的模型。

每个人的知识积累和经验不同，最适用于他们的概念模型就是不一样的。因此对于有理论和实践经验积累的人，你可能并不需要用简单的方式阐述事物，有时候连比喻都不需要，而对于初次接触陌生领域的人来说，那么对核心逻辑的形象比喻就显得相当重要了。

一个事物只有在自己脑海里面形成了初步的概念模型的时候，才能够算对该事物有了初步的认识，接下来才谈得上如何层层剥茧和分解，深入到内部机理进行深入了解。这和我们在学习方法和模式里面谈到一开始的学习应该是不求甚解是一个道理。

只有搭建了大框架，理清主脉络，你才可能有目标和有兴趣深入。

但是实际我们仍然看到，包括很多人员头脑里面仍然是采用了SpringCLoud框架，采用了Http Rest接口服务集成或API网关就是微服务了。而对微服务架构思想的本质并没有形成完整的理解，这些都是我们在学习新知识，认识新事物时候必须要避免的。

从微服务基本定义说起

我们先看下当前互联网上对微服务的主流定义。

微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来。在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程。

微服务不需要像普通服务那样成为一种独立的功能或者独立的资源。定义中称，微服务是需要与业务能力相匹配，这种说法完全正确。不幸的是，仍然意味着，如果能力模型粒度的设计是错误的，那么，我们就必须付出很多代价。

看完上面的图后，估计还是很难真正抓住微服务的关键点。

在我很早就谈到过，在理解和认识一个概念的时候，你一定要用和你已有的知识概念做对比，进行差异分析，你就很容易抓住要点在哪里。

而要了解微服务一样，你了解了和传统单体应用的差别，基本微服务核心就了解了。简单来说微服务本身就是将传统的单体应用大拆小，然后通过一种轻量高效的标准接口进行协同的架构模式。

举一个单体应用到微服务的例子说明

为了更好地解释微服务，包括后面对微服务很多关键组件的解释，我们需要准备一个业务系统功能常见来进行举例说明，具体的背景如下。

当前我们准备构建一个SRM供应商关系管理业务系统，这个系统经过前期业务和需求分析，包括了供应商管理，物料管理，招投标，供应商绩效评估四个功能模块。当然在构建整个系统的时候还有类似底层的系统管理，流程引擎等技术模块组件。

我们要构建的SRM系统就是典型的单体应用，那么我们来看这个单体应用构建模式转变到微服务构建模式后究竟带来了哪些变化。如下图，我们从开发态和运行态去分析。

从这个图我们基本就把微服务核心的关键点看清楚了。即：

一个单体变多个微服务模块，而且从数据库到逻辑层到前端完全独立

微服务模块间通过Http Rest接口高效集成协同

各个微服务完全独立部署，扩展的时候数据库，集群都单独扩展

以上实际上就是我们经常谈到的微服务区别于单体架构最关键的几个点。在掌握了这个核心概念后你才清楚哪些不是微服务基本特征。比如微服务必须容器化部署，没有这个说法，微服务也可以传统方式部署。还有就是微服务开发必须前后端分离，实际上也没有这个说法，前后端不分离只要微服务间完全纵向解耦就是微服务架构。

基于SOA和中台思想对上面拆分进行重构

如果按照上面的模块拆分进行独立的设计，开发和部署，完全是符合微服务架构的思想的。但是是否符合SOA和中台能力共享思想呢？

将数据提供和形成数据的流程分开形成分层

我再强调下SOA和中台里面的一个关键思想，即：

你要去找到你的核心业务能力提供，而不是马上去关心你的能力或最终数据是如何形成的。能力最终提供属于中台能力，能力如何形成的可以属于前台应用能力。

比如上面谈到的供应商，物料两个微服务，我们发现核心就是提供可共享的供应商和物料数据能力。但是这两个数据如何形成的? 一方面是可以直接在后台录入，一个方面还是可以是供应商自己进行供应商认证申请，我们审核通过后进入到供应商库。

那么供应商数据本身属于中台能力，供应商信息的申请流程可属于前台应用功能。

是否严格的逻辑层和数据库1对1对应？

这个是我今天想拿出来讨论的第二个问题，即很多人在进行微服务架构设计的时候往往走两个极端。或者是数据库不拆分就一个大库，或者就是数据库完全按微服务1对1拆分。那么我们上层规划的20个微服务，是否就一定有20个对应的数据库实例ID？

在数据库拆分太细时一定带来我们在设计实现时候两个问题

其一是我们常说的分布式事务处理问题，有用库拆分无法再用数据库层事务

其二是原来一个关联sql搞定的事情，全部变成了逻辑层多次服务调用后进行服务组装

以上两个问题不仅仅是带来的开发工作量，而且更重要的是影响到数据一致性。

正是由于这个原因，我们提出一个微服务集的概念。

微服务集的意思可以理解为逻辑层仍然按照标准的微服务要求去构建，每个逻辑层都可以编译可独立部署的Jar包。但是对应微服务集里面的多个微服务可共用一个数据库。

而基于上面场景，供应商和物料本身关联业务场景相当多，放在一个数据库显然是更加适合。经过重新思考后，我们整体的逻辑架构变化为：