ASM实战之如何理解服务发现

这篇文章主要讲解了“ASM实战之如何理解服务发现”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“ASM实战之如何理解服务发现”吧！

一、组件化

因此当项目足够庞大复杂，需求足够垂直之后，项目整体架构如何演进就变得颇为重要，如果拆分项目就是一个亟待解决的问题。而组件化则是其中较为正确的一种解决方案。

本质的思路：按需求类型维度(或其他的抽象维度)对整个项目进行模块上的拆解，每个模块按照对扩展开放，对修改关闭的原则进行依赖隔离的设计。在如此的指导下项目自然而然的就分而治之，化繁为简，化整为零。这也就是常说的模块化(组件化)。

个人看法：叫组件还是模块，只是抽象的维度的不一样罢了，没什么好纠结的。

组件化的意义对于项目来说在于宏观上的解耦，具体下的内聚。这种思想在设计模块中经常被提到：高内聚低耦合。

这样带来的“好处”也是显而易见的，复杂的工作被拆的足够简单，那么团队的划分便会更科学，执行也会更高效，毕竟只需要负责自己的一亩三分地，“锅也就比较好分了”…

这似乎也是流水线模式下的一种应用吧，是好还是坏，作为打工人的我也不好评判什么，毕竟我也是被流水线上的一员。人生在世又有谁是自愿背上枷锁的呢…

明确组件化的内核和意义，接下来我们就要思考如何去落地。想要彻底拆分和解耦，除了接口上的设计，编译隔离也是必须要考虑的问题。而走到这一步，很多有经验的同学应该意识到这其中的棘手的问题：既然面向的是接口，又是编译隔离，那么如何拿到接口背后的实现呢?

路走到这里，也就该面对服务发现(或者接口发现)的问题了。

二、服务发现

咱们用一张图来描述一下上述环节聊的这些内容：

从图中，我们可以看到这里对组件化的方案，是增加了一个接口层，这层往下都是实现层。为了实现编译隔离，所有的实现层只能依赖接口层，这样对于实现层来说，就无法看到其他模块的实现，也就不会干预到其他模块。

因此如何方便的让模块彼此能够方便的通过服务发现感知到其他模块的实现便尤为重要。

感谢各位的阅读，以上就是“ASM实战之如何理解服务发现”的内容了，经过本文的学习后，相信大家对ASM实战之如何理解服务发现这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是亿速云，小编将为大家推送更多相关知识点的文章，欢迎关注！