如何划分微服务

原文地址： https://itweknow.cn/detail?id=51 ,欢迎大家访问。

我们已经大概知道了微服务是什么东西了，如果你还不知道的话，可以点这里。这篇文章就主要了解一下怎么去划分微服务，确定服务边界。首先这里先介绍几个概念。

• 松耦合
  就是服务与服务之间的影响要尽量减少，想象一下如果如果服务之间做到了松耦合，那么就意味着修改一个服务就不需要修改另一个服务。这一点对与实现微服务来说是很重要的。
• 高内聚
  我们需要将相关的行为收集在一起，避免修改一个功能需要修改多个服务才能实现。
• 限界上下文
  任何一个给定的领域都包含多个界限上下文，每个界限上下文都中的东西都分为两个部分，一部分不需要与外部通信，另外一部分则需要、每个上下文都有明确的接口，该接口决定了它会暴露哪些模型给其他上下文。

一个例子

 现在有一家面向C端用户的公司，有自己的用户服务和财务服务。那么这两个服务其实就是两个单独的限界上下文。都会提供一些对外的接口（用户信息，会员，支付等），当然也会有一些东西在内部被消化（用户操作记录，支付过程等）。

两个界限上下文

共享数据模型

财务系统在核对会员费的过程中可能需要用户系统中的会员信息，所以这个时候会员模型就成了两个上下文的共享数据模型了。但是实际上用户系统不会将会员的所有信息都共享给财务系统，比如说用户密码性别这些可能就不会共享出去。也就是每个数据模型都会有内部和外部两种表现方式。

逐步划分

 我们可能会在系统规划的一开始就将微服务规划的好好的，但是随着时间的推移很有可能发现之前服务边界划分的有问题，这就会导致很多的跨服务修改，维护起来相当的困难。所以我们在实际的划分过程中应该是逐步的去划分服务，初期的时候可以在系统中使用模块来达到松耦合的目的，然后当我们发现了明确的界限上下文的时候再去拆分服务。
 在初期我们发现的可能是一些粗粒度的界限上下文，随着时间推移和业务的拓展可能会出现一些相对细粒度的上下文。还是刚刚例举的例子，我们可能会想将用户服务中的权限抽取出来作为一个单独的服务。实现这个目的的常用方式有两个：

• 嵌套界限上下文
   这种方式的具体实现就是将权限这种新识别出来的界限上下文不直接对外公开，也就是对于外界来说还是使用的用户系统的功能，但是实际的关于权限的请求可能会被映射到权限服务中。

嵌套界限上下文

• 提升界限上下文层级
   这种方式下，我们就是直接将权限服务拆分并且公开给其他界限上下文，也就是说拆分后的权限上下文和之前的用户上下文是同一级别。

提示界限上下文层级

错误的划分

 比较常见的错误划分就是在项目初期我们采用了技术边界作为服务拆分的标准，然后随着业务的不断扩展我们会发现这种拆分方式会产生很多的问题，因为可能不同的业务掺杂在不同的服务里面，这会导致很难进行修改。所以一般情况下我们要尽量避免使用技术边界作为服务划分的方式。