Microservice架构模式简介

例如在一个IaaS云中，一个用户所具有的角色可能会根据他所拥有的职责来划分：云上拥有一系列用于监控的用户，用来完成对云的整体运行监控等工作（不包含查看用户数据，这是个安全问题）。同时云上的用户又可以分为帐号管理员，Tenant管理员，资源管理员以及普通用户等。而在其上运行的应用即服务（AaaS，Application as a Service）中，其用户的职责划分可能是另一个样子：在AaaS上定义应用的是应用架构师，负责应用部署及维护的则是运维人员。在应用架构师设计一个应用的时候，其并需要拥有IaaS云上访问资源的权限，却并不需要分配资源的权限，但是运维人员需要拥有该权限以对应用进行部署和维护。

也就是说，IaaS云中的权限划定和AaaS服务中的权限划定并不一样。通常情况下，我们常常在业务集成时执行一次对权限的匹配：

从上图中可以看出，由于AaaS服务是运行在IaaS之上的，因此为了能够操作IaaS中所包含的各个资源，AaaS服务需要将自己的用户角色匹配到IaaS所定义的角色上。例如应用架构师需要能够在定义应用的时候需要知道IaaS上所具有的资源，并需要能够指定到底哪些人可以使用这些应用，因此其需要拥有IaaS的Tenant管理员，资源管理员及普通用户三种角色。而AaaS上的运维人员则只需要在部署和维护时察看IaaS上所拥有的资源，因此其只需要资源管理员及普通用户两种角色。

但是这么做有两点不好的地方：如果Microservice中只包含了几个服务，而且这种服务之间的依赖关系并不是很多，那么这种服务匹配还能够解决，但是如果整个系统之间各个子服务的沟通很多，那么在各个子服务之间进行角色匹配将变成一个噩梦：

解决该问题的方法就是使用我们上节所介绍的公共服务对它们进行管理。在提供一个集中的公共服务的情况下，我们就不再需要处理这么多的模型转化了：

除此之外，仅仅简单地对角色进行匹配实际上并不那么合适：就应用架构师而言，其需要的是查看当前的已有资源，却不需要对资源进行分配。因此其需要的是对资源的读权限。而运维人员则不仅仅需要能够读取资源信息，更需要对资源进行分配，因此其需要的是资源的读写权限。如果仅仅像上面那样在IaaS层为应用架构师赋予对资源的读写权限，那么应用架构师就可能拥有了错误的权限，进而执行了错误的操作。而相对地较为合适的方式则是对这些权限进行细分，即在权限中区分读写权限等：