Netty：可能是世界上最好的包装结构

通过优锐课的java学习，在依赖项和包结构方面，Netty可能是首屈一指的。 看看是什么使它如此出色

Netty的包装结构很棒。
每个程序员都应该研究它。 每个系统都应该模仿它； 每个项目经理都应将其打印出来，打在墙上，然后对开发人员说：“那样”。
Netty是一个“ …用于快速开发可维护的高性能协议服务器和客户端的异步事件驱动的网络应用程序框架”，但这并不重要，因为我们没有分析其行为。 而是看图1。

图1：Netty的包装结构历时7年。

图1展示了Netty不断发展的软件包结构的spoiklin图（圆圈是包；直线是页面下的依赖关系；曲线是页面上的依赖关系），如果你不能立即看到它的结构如何， 然后查看Junit，Struts或Ant。

“旁观者眼中的良好结构”也不是唯一的情况。 结构障碍为程序的结构化程度提供了客观的衡量标准：结构障碍越低，结构越好。
Netty的疾病远低于其他疾病，请参见表1。

表1：本系列中所有程序的结构紊乱。
此外，图2显示了这种最终的结构异常并非偶然。 Netty在整个七年的生命周期中一直处于低水平。

图2：通过11个发布发布的Netty的结构混乱（与其他发布者进行比较）。
那么，为什么这个包结构这么好？

给定如图1所示的图，我们可以提出两个快速问题来粗略地评估所描述结构的优点。

在商业软件开发中，“良好的结构”仅表示“便宜的更新”。 此外，证据表明每位掌握波纹效应的程序员都知道：X依赖的东西越多，涟漪效应的影响就越大，因此X的成本就越高。

因此，选择一个严重依赖他人的软件包并询问：
1.我们可以轻松地确定所依赖的软件包吗？
2.这些依赖软件包的整体中有多少子集？

结构不良的程序会掩盖这些依赖关系，仔细检查通常会发现几乎整个系统都存在依赖关系。 但是，结构合理的程序显然会提供依赖的程序包，而且数量很少。

让我们先问一个结构不好的程序的两个问题。
图2显示了詹金斯噩梦般的90％结构性混乱，然后显示了来自五个软件包（工具提示）中最依赖其他软件包的突出传递依存关系。

Figure 2: Jenkins, oh Jenkins.
显然，在Jenkins中跟踪依赖关系是一个挑战，许多软件包取决于系统其余部分的75％以上。

图3重复了该实验，显示了五个Netty软件包的传递依赖关系，这五个软件包最依赖其他软件包：epoll，spdy，websocketx，http和nio。

图3：以蓝色突出显示Netty中最差的传递依赖项。
与詹金斯形成鲜明对比的是，我们可以看到Netty软件包所依赖的数量以及数量。 Netty有55个软件包，但其他任何人所依赖的最大数量仅为12。这只是系统的22％。

Netty的包装结构是否完美？当然不是。特别是，内部和并发之间的循环依赖关系在该核心内部/并发/通道/缓冲区/实用程序包集群中创建了令人遗憾的强耦合。

从表面上看，Netty的类结构确实不好。 Netty的设计师在建立班级级别时显然放弃了一些出色的结构原理。丢人现眼。

但是看看那个包装的结构……哇。
最后，没有分析Netty的关键版本，而是提出了自己的架构观察。 Netty的架构师似乎已经决定了一个相当出色的部署策略。下载Netty既可以提供一个一体的JAR文件，又可以提供13个JAR文件，其中包含系统的各个部分。据推测，你可以加载所有Netty或仅加载所需的部分。

一个JAR文件（即公共''jar）包含内部/并发/通道/缓冲区/实用程序包群集，而其他文件则包含例如编解码器’’，tcnactive''，传输’'等，建议后者JAR是公共JAR的客户端，但不是彼此的客户端，因此彼此之间没有依赖关系。因此，在他们的部署中，Netty的设计师可能已经将子系统的分离和封装包含在内，从而导致了这种行业领先的封装结构。

剩下的唯一问题是：为什么没有更多的项目跟随Netty的领导？为什么詹金斯有90％的结构异常？ Jenkins的设计者为什么不适当地划分他们的系统以减少包装间的耦合？为什么软件开发领域如此愿意接受这些不良结构所产生的成本？

我们不是比这个更好吗？

喜欢这篇文章的可以点个赞，欢迎大家留言评论，记得关注我，每天持续更新技术干货、职场趣事、海量面试资料等等
如果你对java技术很感兴趣也可以交流学习，共同学习进步。
不要再用"没有时间“来掩饰自己思想上的懒惰！趁年轻，使劲拼，给未来的自己一个交代

文章写道这里，欢迎完善交流。最后奉上近期整理出来的一套完整的java架构思维导图，分享给大家对照知识点参考学习。有更多JVM、Mysql、Tomcat、Spring
Boot、Spring
Cloud、Zookeeper、Kafka、RabbitMQ、RockerMQ、Redis、ELK、Git等Java干货