Microservice架构模式简介

除了各个服务所提供的API的粒度，服务分割的粒度也是在服务分割过程中需要考虑的因素。如果一个服务的粒度太小，那么它所提供的API的粒度也不会高。一个较为普遍的看法是，在Microservice架构模式中，一个服务需要能够独立地完成特定的业务逻辑，至少是某个独立资源的CRUD操作。例如在电子商务网站中，我们需要一个服务能够独立地完成对商品相关信息的读取，如商品的主要信息，商品的价格，参与的优惠活动等。

这里有一个例外，那就是公共功能的处理。试想在一个应用中，我们常常需要一个权限管理组件来管理用户所具有的各个权限。权限管理组件常常实现了一种公用的安全模型（Security Model），如ACL（Access control list），RBAC（Role-based access control）等。在每次访问一个子服务的时候，这些服务都需要检查用户所具有的权限：

发现问题了么？是的，每次对一个产品系统及订单系统的调用都需要从权限系统中得到当前用户的权限，才能决定用户是否能够访问特定信息。如果这样的公共服务很多，那么该系统的性能将会变得非常差。

解决该问题的一种方法就是在各个系统中将下次还能够使用的信息缓存起来，也就是在这些系统中为用户创建一个会话。由于每个系统可能由多个服务实例所组成，为了能够重复利用会话中所储存的信息，减少向公共服务发送请求的次数，我们需要通过负载平衡技术让系统中的同一个服务实例处理同一个用户的请求。有关如何实现该功能，请见我的另一篇文章《企业级负载平衡简介》。

除了性能问题之外，公共服务还会与各个服务产生一种逻辑上的依赖关系。让我们继续通过权限系统这个例子进行讨论。当权限管理的组成存在于各个服务中的时候，我们可以直接通过传入用户的信息以及需要访问的资源就能判断出到底用户是否能够访问特定资源。也就是说，从权限管理组成所返回的实际上就是一个布尔类型的数据。但如果权限管理不再是一个组成，而是一个服务，那么为了避免每次都调用权限管理服务，我们需要在用户的会话中记录用户所具有的权限。在用户下次访问该服务的时候，我们可以通过直接检查该用户所具有的所有权限就能决定其是否能够访问特定资源了。这些在用户会话中记录的权限常常具有其特定的表现方式，例如特定形式的字符串，而这种字符串表示需要同时被服务和权限管理服务所理解，从而造成了这两个服务之间的耦合：