第一步
在每个微服务中实现用户配置文件
第二种方法:用户配置文件服务
在单个微服务中实现用户配置文件检查
当我做决定时，我可能会考虑哪些其他因素?你会怎么做?
实际上你还没有提到另一种方法，我实际上可以推荐考虑:
引入网关——一个特殊的服务，它将负责"外部世界"之间的授权/认证。和你的后端服务:
Client ---> Gateway -----> Service 1
|-----> Service 2
...
不可能从"外部世界"直接访问Service1、2等。直接地，只有网关会被暴露，它也会负责路由。另一方面，所有到达后端的请求都将被认为是已经授权的(可能有附加的标头，带有"已验证")。角色列表，或者使用一些"标准"。(如JWT)
除了关注点分离(后端服务"think"仅关于业务逻辑实现)，此方法具有以下优点:
所有的逻辑在一个地方，容易修复，升级等。例如，你的第一种方法可能会受到更高级的生态系统的影响(如果服务是用不同的语言编写的，使用不同的框架，等等)——你将不得不在不同的技术堆栈中重新实现AuthZ。
用户不"意识到"在各种各样的服务中(只有网关是入口点，路由在网关中完成)。
没有"冗余"后台服务为authZ调用(读取CPU/内存/IO)。与第二种方法相比，您必须在每个请求时调用外部服务。
可以分别扩展authZ服务(网关)和后端服务。例如，如果你引入新的服务，你不必考虑它会给你的AuthZ组件(redis，数据库等)带来多少开销。因此，您只能根据业务需求进行扩展