常见的微服务boundary划分考虑因素

我们在前文中介绍了DDD在微服务boundary划分中的指导意义，但显然它并不是唯一的划分准则，本文就来介绍几个其它在微服务划分的时候经常需要的考虑因素，我们通常会把它们和DDD集合起来做最终的决定。

波动性（Volatility）

这个世界变化很快，我们有时需要提前考虑系统某一个部分是否会频繁修改，以及是否需要把相应的功能抽象出来成为服务，从而使他们的执行更有效。

一个简单的例子，早期的购物网站可能不支持线上支付，那么在支付页面只需要留一个订购电话，用户只能拨打电话进行订购。这个时候的支付功能是否需要独立一个service来处理呢？也许不一定。而随着时间的推移，支付的方式不断进行演进，比如开始支持信用卡的支付，支持微信支付宝的支付，这个时候把支付独立出来成为一个新的微服务是否更加合理？假设后来每种支付方式开始出现不同的后续操作，比如微信支付之后有了微信购物抢红包的功能，或者使用支付宝支付有了其特有的couple和额外操作等等，是否需要把微信，支付宝都进行独立微服务处理呢？这些都是需要考虑的，总得来说，考虑服务的波动性也就是改变频率是一个不错的建议。

数据

涉及到数据就无法避免敏感数据这个话题，很多时候因为数据的特殊性，我们需要对相应处理数据的服务做一些额外的操作，那么就有理由把涉及这些数据的服务独立开来了。

同样以支付系统来考虑，比如我们需要处理用户的信用卡信息，而这些信息是很敏感的，按照相关的要求，对处理信用卡信息的服务需要进行额外的监管，这时一种比较好的做法就是把凡是能看到信用卡信息的流程都放到一起（下图中的红色虚线内），把别的不涉及到信用卡信息的服务放到绿色虚线框内，这样的划分就是考虑到了数据的因素，如下图所示：

技术栈

在早期的三层架构中（如下图所示），就是前后端，数据库的架构中，我们会根据这个来进行划分。同样的在微服务中，不同的技术栈也是我们划分不同微服务的一个需要考虑的因素，比如说你想把系统中的一部分用Rust来写，以提高开发的性能，那么很显然就需要考虑是否把这部分独立出来成为一个服务。

组织架构

现实中很多时候组织架构对最终微服务的划分起到了决定性的影响，比如说多个team来管理一个微服务有时就没法得到我们想要的benefit，这也是为什么我们经常看到一些公司在monolith到微服务的转变过程中也同时伴随着组织架构的调整。

也许你会问，假如我们的组织架构经常变化，是不是也意味着我们的服务架构需要变化呢。假如说组织架构的变化只是让微服务的owner发生了变化，那其实还好；假如另外一个方面，组织架构的变化让一个服务被两个多个团队管理了，也许我们也需要进行重新思考微服务的划分。

举个例子，比如说你以前的仓库管理系统包含了两个方面，一个方面是给相应的订单进行发货，另一个方面是分析还差哪些货物，并进行采购。原本他们是一个team处理，也是一个微服务进行处理，现在订单处理和采购分成了两个部门，那我们可能也需要考虑是否把微服务也拆分开来。

总结

微服务的拆分其实是一个很麻烦的事情，有很多因素需要考虑，本文尝试列出除了DDD之外的一些常见考虑因素，希望能够对你有所帮助。