从专栏上线发布到现在，不知不觉三个月时间过去了，感谢你的一路陪伴，今天到了说再见的时候，我想简单回顾一下专栏的内容，并且聊聊我的一些感受。

Tomcat和Jetty发展这么多年，已经比较成熟稳定。这些年技术发展迭代速度又很快，在一个“追新求快”的时代，Tomcat和Jetty作为Java Web开发的必备工具，似乎变成了“熟悉的陌生人”。对于很多新同学来说，虽然有些Tomcat和Jetty的知识点在面试中会碰到，但从侧面来说Tomcat和Jetty似乎没有那么“火”，那是不是说如今就没有必要深入学习Tomcat和Jetty了呢，只要会用就行呢？要回答这个问题，我先讲讲为什么我选择这个主题来写专栏吧。我写这个专栏的初心还是希望我们可以静下心来，细细品味经典的开源作品，从而进一步提升我们的“内功”。“内功”这个词有些抽象，具体来说就是学习大牛们如何设计、架构一个中间件软件系统，并且让这些经验可以为自己所用。作为一名IT从业者，我认为我们很有必要深入思考一下，这些大牛为什么能够创造出这些优秀的作品，并且能引领技术的发展呢。

不知道你发现没有，美好的事物往往是整洁而优雅的。但这并不等于简单，而是要将复杂的系统分解成一个个小模块，并且各个模块的职责划分也要清晰合理。与此相反的是凌乱无序，比如你看到一堆互相纠缠在一起的电线，可能会感到不适。

同样的道理，当我们在设计一个软件系统时，追求的目标也应该是整洁和优雅。我觉得首先需要合理划分功能模块，主要是分清楚“变与不变”的边界，因为变化往往会给系统实现带来混乱，因此需要将“变”的因素控制、隔离起来。如果你发现一个软件系统里有大量if else语句、大量的重复代码、大量的相互依赖，那么这个系统多半还有提高的空间，所以分清楚“变与不变”十分重要。

从宏观上看，中间件实现的功能基本上是稳定不变的，它们往往会实现一些协议和规范，比如Tomcat作为一个“HTTP服务器 + Servlet容器”，它向开发人员屏蔽应用层协议和网络通信细节，我们拿到的是一个标准的Request和Response对象；而具体业务逻辑则作为变化点，交给我们来实现。

从微观上来看，Tomcat内部也隔离了变化点和不变点，比如Tomcat和Jetty都采用了基于组件化的设计，其目的就是为了实现“搭积木式”的高度定制化，而组件的生命周期管理有一些共性，被提取出来成为接口和抽象类，而具体子类实现变化点。

其实当下流行的微服务也是这个思路，首先按照功能将单体应用拆成微服务，拆分的过程中要注意从众多微服务中提取一些共性，而这些共性就会成为一些核心的基础服务，或者成为一些通用库。

设计模式往往是封装变化的一把利器，我在专栏里也谈到不少Tomcat和Jetty所采用的设计模式，合理地运用设计模式能让我们的代码看起来优雅且整洁。

除此之外，我们在编写程序时应该时刻考虑到高性能，尤其是开发基础的中间件系统，在大数据量、高并发情况下，可能一行代码的改动会带来明显的性能提升。高效意味着合理的数据存储和流动方式，换句话说其实就是合理地运用数据结构和算法，举个最简单的例子，在某个场景是选择数组还是链表。如果你深入了解过Tomcat，你会发现在许多实际场景中，Tomcat都会有针对性的选择，所以对于一些常见的数据结构和算法，虽然我们不需要深入到实现细节，但是一定要知道在什么场景下用哪个。

此外写高性能程序，还意味着你需要掌握操作系统底层原理，并且深入到JVM底层的实现细节，比如我们调用了一个Java API，JVM和操作系统在背后为我们做了什么呢？挖得更深一点，我们对程序的理解也就更深刻，也许就是因为深入的这一小步，能够让我们在竞争中脱颖而出。

不知不觉，我从Tomcat和Jetty的学习谈到了如何优雅地设计一个复杂的系统。由点及面，你可以把Tomcat和Jetty当作一个支点，从我们身边“熟悉又陌生”的Tomcat和Jetty入手，不光掌握它们的使用，更能从它们的源码中汲取经验，提升自己的系统设计能力。学习这件事千万不能浮躁，很难做到一口吃成大胖子，最重要的是需要静下心慢慢体会和思考。我看到不少同学的留言，从提问的内容我能感受到你们的好奇心和思考，有些问题我也还要去查阅源码才能回答上来，在这个过程中我自己也主动或被动的学到不少东西，所以说多和同行们交流也非常有必要。

学习永远在路上，最后祝我们一起进步！