问题请教：为什么auth模块不同样开发为privider、consumer模式？

[micyo202]

问题请教：为什么auth模块不同样开发为privider、consumer模式？

[micyo202]

auth服务是整套微服务体系中的统一授权认证服务，只有服务鉴权使用，跟业务处理无关，不需要进行服务拆分，否则过于繁琐
demo中是模拟服务拆分，可根据业务场景拆分多个服务，增加系统业务处理容错，支撑峰值业务处理

[huaxuehuaxue]

非常感谢大佬，祝大佬天天开心。

[huaxuehuaxue]

auth服务是整套微服务体系中的统一授权认证服务，只有服务鉴权使用，跟业务处理无关，不需要进行服务拆分，否则过于繁琐
demo中是模拟服务拆分，可根据业务场景拆分多个服务，增加系统业务处理容错，支撑峰值业务处理

大佬，最近又在考虑这个问题，能否指点一下这样拆分的情况下，是如何做到业务处理容错、支撑峰值业务处理 的？

[micyo202]

服务拆分后，单独的某一个服务挂了不会最影响到整个系统（如：[订单] - [产品] 2个服务，当订单服务挂了不会影响到，产品查看管理等功能，同样当产品服务挂了，不会影响到订单信息查看等功能），服务拆分后原本由一个服务处理复杂的业务变成多个服务分布式处理，这样就增加了服务的吞吐，整体是分治法的**

[huaxuehuaxue]

服务拆分后，单独的某一个服务挂了不会最影响到整个系统（如：[订单] - [产品] 2个服务，当订单服务挂了不会影响到，产品查看管理等功能，同样当产品服务挂了，不会影响到订单信息查看等功能），服务拆分后原本由一个服务处理复杂的业务变成多个服务分布式处理，这样就增加了服务的吞吐，整体是分治法的**

这个道理是理解的，就是 如果按照demo中的模式，将consumer拆出来，对业务处理容错、支撑峰值业务处理 会有多大的提升和好处？

[micyo202]

我不太明白你这边是不明白服务拆分的方式，还是不明白服务拆分后带来的效果？

拆分方式：

• 若按业务逻辑进行服务拆分，会增加服务的容错性，拆分的粒度越细，服务的容错性就会越好，但同时性能的开销就会越大，所以服务的拆分要适当。
• 若按性能维度进行服务拆分，会增加服务的性能，如将对性能压力大的模块拆出来，避免影响整体服务，而且能对其单独做性能提升、高可用等优化。
  服务拆分可以按照多种维度进行，包含但不限于以上列出的种类

拆分后的好处：

• 单独的团队可以负责单独的服务开发，无需关注整体服务，更专注于特定领域的服务开发，提高开发效率、精细化责任划分。
• 各服务模块的功能维护或BUG修复无需重新部署整套系统，只对修改的一个小服务进行发布即可，便于系统的维护扩展。
• 各服务可以采用不同的架构风格针对特有的业务场景，服务实现方式更加灵活、自由。

至于会提升多大单从应用服务无法评估，还要取决于硬件资源的分配情况

[huaxuehuaxue]

我不太明白你这边是不明白服务拆分的方式，还是不明白服务拆分后带来的效果？

拆分方式：

• 若按业务逻辑进行服务拆分，会增加服务的容错性，拆分的粒度越细，服务的容错性就会越好，但同时性能的开销就会越大，所以服务的拆分要适当。
• 若按性能维度进行服务拆分，会增加服务的性能，如将对性能压力大的模块拆出来，避免影响整体服务，而且能对其单独做性能提升、高可用等优化。
  服务拆分可以按照多种维度进行，包含但不限于以上列出的种类

拆分后的好处：

• 单独的团队可以负责单独的服务开发，无需关注整体服务，更专注于特定领域的服务开发，提高开发效率、精细化责任划分。
• 各服务模块的功能维护或BUG修复无需重新部署整套系统，只对修改的一个小服务进行发布即可，便于系统的维护扩展。
• 各服务可以采用不同的架构风格针对特有的业务场景，服务实现方式更加灵活、自由。

至于会提升多大单从应用服务无法评估，还要取决于硬件资源的分配情况

非常感谢大佬这么认真、耐心的解答。收获很多。谢谢。