SpringBoot整合web容器
Spring是为简化Java开发而生的。与传统的如Sturts这样的框架相比，它采用最小侵入编程，让开发者更少的感知到它的存在。随着Spring越来越强大，Spring体系也越来越复杂。为了化解戴着镣铐跳舞的窘境，产生了SpringBoot。
SpringBoot的理念是约定大于配置。大家都这么用，有了规范，一切就容易多了。这就实现了一个标准化->流程化->工具化的跃迁。复杂度大大降低。但是一般一个web工具，引用一个jar包是搞不定的。依赖的冲突问题仍然是一个业界痛点。
一般一个web项目使用SpringBoot最好显示的引入5个jar包，其中最后两个是测试用的，请注意统一版本。
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-autoconfigure</artifactId> <version>${spring.boot.version}</version></dependency><dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> <version>${spring.boot.version}</version> <exclusions> <exclusion> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-logging</artifactId> </exclusion> <exclusion> <groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-tomcat</artifactId>
</exclusion> </exclusions></dependency><dependency> <groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-jetty</artifactId>
<version>${spring.boot.version}</version></dependency><dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-test</artifactId> <version>${spring.boot.version}</version> <scope>test</scope></dependency><dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <version>${spring.boot.version}</version> <scope>test</scope></dependency>注意上面红色部分，显示的去掉对tomcat的依赖，使用jetty做容器。
嵌入式web容器和非嵌入式web容器的差别
这里想起自己在硅谷时的一件事情。
那时候公司里有一批同事都是之前netflix一个团队的，我刚到硅谷的时候，明显能感觉到他们的高傲。开始时，我出于习惯，那些同事在做一些事情的时候，我看到有些问题，我会告诉他们更好的方法和其中的原理。确实有许多我可以指导的地方，不是我技术有多好，而是他们都不是java出身的。对java没有那么精通。每次被我指出来问题，他们处理完总要露出鄙夷的面容，以后我就学聪明了，看到问题我也不说。
有次，有个同事问我国内用的什么web容器，我说用的tomcat。结果这个同事突然大笑，笑完还特意拉过来其他同事过来啥也不干就是一起笑。我问他们用的什么，他们也回答不上来。好吧，笑就笑吧，都是中国人，也不涉及什么有辱国威。我的人生已经彪悍的不需要解释了，压根就不在乎你们怎么看我。
后来有次，这个同事以为发现了我写的一个bug。所以拉上我，拉上很多开发一起围观再现我的bug。我们围在一起看他调试，结果我发现原来是他参数传错了。在他灰头土脸的时候，我只说了一句：“有问题再找我吧，我先回去了。”
因为我总是面对他们的质疑和嘲讽很低调，加上能干活，所以他们非常喜欢我，对我很nice，临走还特意给我饯行。签证到期回国再回来时，第一天他们就来找我，说我应该坐在他们中间，我们都是开发（只有我一个开发，其他都是产品，运营啥的）。总结一个经验：做人要低调，不要专门寻求认同，事情做好了自然有人认同你。
OK，先说他们为什么要笑：那是几年前的事情，那时候嵌入式的web容器在美国已经很流行了。但是那时候在国内，因为公司统一的标准还都是使用普通的web容器。一个新型的标准在大公司里普及确实没有这么快的。而嵌入式的web容器只是更便于DevOps，并没有什么性能和稳定性的差别。DevOps需要建立在公司统一基础设施的基础上，公司大了就有历史包袱，也是挺正常的。
有人说中国的互联网是国际领先的。这种领先是建立在需求驱动的基础上的。好比小时候我读《水浒》特别羡慕他们大口吃肉，现在我家小鲜肉早上给他煎牛排都已经不怎么吃了，天天换花样，劝饭这个费劲。现在物质发达，我倒觉得从这个方面看我小时候更幸福些，现在的小孩无欲无求。好比是硅谷，没有很强的外部驱动，有精力练就很扎实的基本功，很多人40多岁还是普通程序员。在中国工作两三年就带团队的大有人在，对程序员还是刚需，好像一个有很强消化能力的孩子。说不上哪个好哪个不好。
Tomcat和Jetty的差别
Tomcat和Jetty可以算的上是目前全球范围内最著名的两款Servlet容器。它们的实现都遵循Java Servlet规范。所以对于多数Java Web应用部署任意一个都可以。对应用开发来说，飞行中互换几乎是无感的。
从趋势来看，Jetty人气越来越盛。很大部分原因，大家在做选型的时候，都有一个业界调研，调研一线公司都是怎么用的。而目前Google App Engine选择了Jetty。这相当于是在云环境下，这是个默认的选择。
区别对照表
| Jetty | Tomcat | |
| 轻量 | √ | × |
| 节省内存 | √ | × |
| 快速高效 | √ | × |
| 可插拔性 | √ | × |
| 可扩展性 | √ | × |
| 支持大规模企业级应用高级特性 | × | √ |
Jetty更满足分布式环境的需求，Tomcat有一些企业级环境使用的高级特性，一般用不到，用到时也是收费的。
结论：建议用Jetty。
相关阅读