Spring Boot vs Web Container

以前我们构建 Web 服务的方法是将程序打包后交给 Web 容器，让容器启动服务进程，加载程序包，然后对外提供进程。

现在我们有更方便快捷的方法来构建 Web 服务：用一些轻量级的 Web 框架，让我们的程序包内嵌 Web 服务能力，直接运行一个 main 方法就能启动进程提供 Web 服务。

这类轻量级的 Web 框架有很多。如，Spring Boot、Dropwizard、Vert.x、Grails、Play Framework 等。其中 Spring Boot 最常见。

 

这类框架工具的特点如下：

 

优点

1. 容易部署

Web 容器的安装、配置、部署都是巨麻烦的事。为了实现业务而不得不去了解这么一堆垃圾信息是非常浪费的。

内嵌 Web 服务能力的方式使我们运行一个 main 方法就能启动服务，有巨大的优势。

 

2. 运行环境维护成本低

内嵌 Web 服务能力这个特性让我们耗费在维护运行时环境上的资源更少，原理Web容器那堆麻烦事。开发、测试、产品等环境的维护工作都大大简化

 

3. 容易实现持续交付

没了Web容器这类环境上的耦合且难配置场景，持续交付的实现也容易得多

 

4. 研发周期短

更容易启动服务也就意味着研发过程中可以将更多时间用于处理业务。

如，“打包交给 Web 容器再启动”这个步骤的消失极大地解放了程序员。在调试的时候这种优势非常明显。

 

与开发本地桌面程序相比，Web程序开发时的运行时环境处理简直就是噩梦。

旗帜鲜明地反对“不讲Web服务原理，直接照猫画虎上手搭建Web服务”的教学方式。

就如同旗帜鲜明地反对“不手把手带学生入门，直接放羊式从自学C语言找编程入口”的教学方式。

 

5. 对第三方库版本的替换更方便

如果多个服务寄宿在同一个Web容器中，且它们共用了一个某服务想替换的第三方库。那么对这个第三库版本替换的操作几乎就成了“瞎赌”，对其它服务的影响无法估计。

 

6. 对依赖组件的管理更清晰

Web 容器不可能包含服务所依赖的所有组件。所以打包服务程序时，我们还是得将这些 Web 容器未提供的必要组件一起打包。

这就形成部分依赖组件来自 Web 容器，部分来自服务程序包自带。这会增加管理复杂度。

而 Spring Boot 这类框架则是将所有依赖的组件一起打包，管理起来方便多了。

 

7. 资源隔离更彻底

寄宿在同一个Web容器中的多个服务会共享一些CPU、内存、文件等资源。

当它们被拆分成独立的进程，由操作系统直接提供资源时，资源隔离更彻底。这有利于规划资源分配。

 

 

缺点

1. 运维工作量增加

没了Web容器，原来寄宿其中的服务被拆分到多个独立的服务中，这就需要对它们分别进行监控管理。

虽然工作复杂度可能会因为服务的彻底分离而降低，但工作量会增加——每个服务来一套。

当然，因为复杂度的降低，运维效率提高，总体工作时间可能反而降低，幸福感会提升。

 

2. 研发组织架构需要围绕服务进行重构

服务的彻底分离，也就意味着每个服务需要有一套完整的班子伺候它。每个对应的小组都是跨职能跨技能的。

所以原先专职开发组、测试组、运维组需要被拆分，围绕具体的服务应用进行重构。

当然，这种变动也许是好事。但是组织架构变动也是要成本的。

 

3. 研发成本增加（短时间内）

为每个服务配置一整套资源（包括人力、软硬件、定制的规章流程等）很可能是原有资源不能满足的。

如，某些类型的资源可能过剩，但某些类型的资源却极度缺乏。

 

4. 项目资源配置不足导致出错几率增大

原先通过 Web 容器管理这些服务时，某些安全性配置、异常处理机制等一般都有专人跟进统一把控。

当拆分给各小组完全复制时，这些与业务主逻辑关联度较低的事项很可能因为人力不足而被遗漏。

像数据冗余策略、超时机制、回滚机制等都是需要考虑的。这也是分布式系统经常会出问题的地方。