今天谈一下领域建模里面的微服务划分。微服务的发展和领域建模的一些思想应用到了微服务的划分过程中。首先回顾一下微服务划分这个概念。在微服务没有出现之前，我们也在谈要去规划一个it系统要去做业务模块的划分或者说是组建的划分。但是当时的划分有一个特点就是数据库没有做拆分，更多的是基于业务活动业务功能和业务逻辑去做上层业务的划分。所以从这个角度来将，微服务的一个核心区别点就是任何一个微服务划分都包含两个层面的划分，第一个就是我们常谈到的数据库要去走拆分，要将相应的数据表拆分到不同的数据库，每一个微服务模块都有他归属的一个数据库对象；第二个是上层业务的拆分，具体哪一些业务功能应该聚合在一起属于某个服务。这就是微服务划分的两个关键点。
原来我们做组件化开发的时候更多是偏业务功能的划分，但是当前在微服务下面这个领域建模重心就偏向具体数据库的拆分，这个时候大家对业务功能的拆分又不够重视了。特别是做互联网移动APP的时候，会发现底层数据库拆分了，每个数据库上层有一个业务逻辑层，或者是提供响应的API能力接口，但是更多都是提供标准的CRUD操作。具体的API能力组合即业务功能的实现全部放到前端去了。而我们的前端手机端并没有个拆分成一个个独立应用。这也是领域建模里面经常所说的贫血，贫血的领域服务层。所以要做好微服务的划分，一定要注意两个方面。第一个数据库要拆，第二个应用功能也要拆，两者缺一不可。我们会把一个大的it 运维系统，资源管理系统拆分成10多个组件包，然后将一个大的系统拆分给3-4个厂商来做，而且要求每个组件包都对应独立的数据库。每个组件之间必须通过接口去做集成。任何一个传统的大的单体系统在拆分的时候的颗粒度和难度是不一样的。任何业务系统我们可以发现能够归结为两类，第一类就是偏流程类的业务系统，类似OA和运维管理系统，还有一类是偏核心共性数据，底层有一个核心的共性数据层触发的上层业务协同系统，典型的就是类似资产管理和资源管理系统。
对于这两类系统的拆分，差异是千差万别。对于流程类的业务系统，比如一个it运维系统，上层有发布申请、申请问题变更管理等二三十个流程，我们即使把它拆分成二三十个微服务一点影响都没有。因为每个流程相对来收，纵向上是独立的，之间也什么耦合关系。但是类似资产资源管理这种底层重的数据共享智能系统，底层这个数据模型如果做了太细的拆分，往往却是灾难性的。这个直接导致上层所有业务都会出现大量跨库查询，大量分布式事务，极大增加了上层业务开发的难度和后期的管控治理难度。所以这也是我们做微服务拆分的时候必须要考虑的一个问题点。
再谈领域建模下的微服务拆分前，我们先看一下传统方式下微服务一般怎么拆分。传统方式下首先做好业务组件业务模块的拆分，这是做微服务拆分的基础，只是会增加一个能力，就是你拆分了业务功能以后，还要接着拆分数据库。传统方式下面，特别是传统的基于结构化的分析速度下面我们怎么去做拆分呢？其实我们仍然需要从端到端的流程入手。任何一个大的业务系统，业务流程可以分为几个大的阶段，实际上每个阶段，很可能就是我们的微服务拆分点。我们经常拿供应链管理系统为例，大的流程基本上包含了前期招投标，框架协议采购谈判，采购合同签订，采购的执行和监控后期的采购的退货或者是逆向物流。那这个大的阶段一定是你去做微服务拆分的一些关键的拆分点。
网友评论