ASM实战

篇文章是一个ASM的实战篇，并没什么什么传统搜到的插桩System.currentTimeMillis()计算方法耗时的实战。而且为项目组件化实现一套服务发现的基础能力。

个人认为组件化是一个项目迭代到一定程度后势必要考虑的问题，不然整个项目势必变成一整坨shishan…

正文

一、组件化

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

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

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

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

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

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

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

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

二、服务发现

（编辑：开发网_开封站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!