微服务划分的原则

服务划分

服务的合理划分是微服务成功的重中之重，是所有项目实施之前必须认真思考，严肃对待的。那么怎样划分才算是合理呢？

以业务、技术、团队导向规划服务

我们必须明确的是：服务不是越细越好，服务划分的第一要素是先以业务域水平拆分，再以技术视角垂直拆分，结合团队的规模、能力确定服务的个数与边界。这之中技术上的垂直拆分比较容易实现，但业务域的拆分可能会存在模糊边界，这时可以考虑结合领域模型来划分业务域。

以笔者的经验，在复杂的系统架构中领域驱动设计（DDD）中的领域模型是比较好的业务导向服务划分方案，下图是笔者服务公司的领域模型示例，可以很直观地明确划分边界。关于DDD可参见^Jdon网站。

另外团队的整体能力也是要考虑一个重要因素，一般而言团队的整体能力与服务的数量成正比，反之极容易导致架构失控。

DAG检查

DAG在数学是有向无环图，这里借用此定义表明：服务间不应该存在双向依赖，双向依赖会导致灾难性的后果。

上图是某项目改造前的服务依赖，存在很严重的双向依赖，直接导致了无法自动化部署、需求响应慢等诸多问题。一个设计精良的系统会做服务分层，业务在上，基础能力在下，上层调用下层服务，下层不依赖于上层，各服务间不在于相互依赖。

分布式事务检查

分布式事务的成本很高，服务拆分尽量避免产生跨服务事务，能合则合。如无法合并则优先考虑TCC或基于MQ的柔性事务，尽可能规避2PC等对性能影响很大的事务方案。TCC可完全替换2PC，但开发成本偏高，需要调用各方都同步修改以支持Try、Confirm和Cancel操作，某些场景会调用三方服务，其代码不受我们控制，此时可以考虑使用MQ实现异步消息和补偿性事务。

性能分布检查

服务中对于特别耗资源的操作应尽量独立。比如笔者的团队中曾有项目使用了bcrypt，导致系统注册服务的TPS严重下降，这时就应该考虑把这个签名比对独立成服务，为这一服务部署更多节点，并且可以为其独立购买计算优化型云主机。

稳定（易变）性检查

一个服务中如存在稳定和不稳定的模块，应该将两者拆分。

比如笔者曾经为某电信10000号做服务化改造，10000号子系统——客服支撑系统(Customer Support System)有很多诸如本月套餐使用情况、销售品、IVR信息、通话足迹、故障分析等功能块，各个功能块要求可以动态添加、修改，此时在设计会把其独立成Widget服务，它的变更不会影响kernel服务。

调用链检查

服务间调用有IO消耗且不宜追踪，应控制调用链路的长度。以笔者的经验，一般的项目在4层以内比较合适，比如：应用服务网关——>应用服务——>公共服务网关——>公共服务。

服务的划分是微服务成败的关键，实践时遵循上述原则的同时更要灵活机动，因地制宜。