微服务之服务拆分

背景

随着新功能的增加，代码库越来越大，当我们部署新功能时，需要将整个系统完整同步到生产环境，如果某同事的问题代码被发布到生产环境，可能会导致整个系统瘫痪，很难快速定位问题，这也是单块系统最大的弊端。

为了解决该问题，人们便想方设法的模块化、清晰化自己的项目，将整个系统拆分为若干个小而单一的功能，以服务的方式提供给上层业务部门，每类服务有专人负责，通过单独部署某个服务来避免发布无关的代码导致的系统瘫痪。这就是微服务。

那如何拆分服务呢？

如何拆分服务

我们先从几个原则说起。

单一职责原则

了解过面向对象的人应该都听说过“单一职责原则”，即每一个类都拥有一个职责。比如一个搬砖类，它既可以盖房子，也可以用来拍人，这时搬砖就拥有了两个职责，所以我们应该把类拆分为两个。微服务也是一个道理，我们应该做到一个服务是用来做一件事情的。我们怎么样才能做到该原则呢？

松耦合

在工作中，当我们修改了一个服务就不需要再去修改其他的服务，那么我们就做到了松耦合。

一个松耦合的服务应该尽可能少地知道与之协作的那些服务的信息。这也意味着，应该限制两个服务之间不同调用形式的数量，因为除了潜在的性能问题之外，过度的通信可能会导致紧耦合。

高内聚

当我们想要修改某个行为的时候，最理想的方式就是修改某一个服务然后尽快上线，如果需要部署多个服务的时候会增大风险性。所以要遵守高内聚与松耦合才能尽可能的实现单一职责原则。

我们现在了解了高内聚、松耦合，那应该把什么聚在一起，什么隔离