DropWizard是在SpringBoot或WildFlySwarn(我们在本书中讨论的另外两个微服务框架)之前就已经有啦。它的第一个版本，v0.1.0，于2011发布。在撰写本文时，v0.9.2是最新版本，1.0即将面世。DropWizard是Coda Hale创建的，目的是为公司的分布式系统体系结构(现在称为微服务！)提供动力，极大地利用JVM。它最初是一组胶水代码，用来组合一些强大的库来编写 rest web 服务，自那时以来一直在发展，尽管它仍然保持其作为最低限度的、生产就绪的、易于使用的web框架工作的身份。
DropWizard是一个自成体系的框架，就像SpringBoot；但是，它比SpringBoot有更多的说明性。有些组件只是框架的一部分，不容易更改。甜蜜的使用用例是编写基于REST的web应用程序/微服务，而不需要太多花哨的装饰。例如，DropWizard为您选择了servlet容器(Jetty)、REST库(Jersey)以及序列化和反序列化(Jackson)格式。如果您想切换的话(例如，将servlet容器更改为Undertto)，将它们更改出来并不是很简单的事情。
DropWizard也不附带依赖注入容器(如Spring或CDI)。您可以添加一个，但DropWizard倾向于保持微服务开发的简单性，而不需要任何魔法。Spring Boot向您隐藏了许多潜在的复杂性，因为Spring非常复杂(也就是说，将Spring运行所需的所有bean都管理起来并不简单)，并且隐藏了大量带有Java注释的bean连接。虽然注释可以很方便，并且在某些方面可以节省很多样板，但是在调试生产应用程序时，魔力越大，效果就越显著。DropWizard更喜欢公开所有的东西，并且非常明确地说明什么是连接起来的，以及如何将它们组合在一起。如果您需要进入调试器，行号和堆栈跟踪应该与源代码非常匹配。
就像SpringBoot一样，DropWizard更喜欢将整个项目捆绑到一个可执行的 jar 中。这样，开发人员就不必担心需要在哪个应用服务器中运行以及如何部署和配置应用服务器。应用程序不是以 war 的形式构建的，也不受复杂的类装入器的影响。DropWizard应用程序中的类加载器是平面的，这与尝试在应用程序服务器中运行应用程序是完全不同的，在应用服务器中可能有许多类加载器的层次结构或图形。计算不同服务器之间的类负载顺序可能会导致一个具有依赖冲突和运行时问题(例如nosuchMethod Error)的COM部署环境。在自己的进程中运行微服务可以隔离应用程序，这样您就可以根据需要单独调优每个JVM，并使用操作人员非常熟悉的操作系统工具监视它们。GC或OutOfMemyExceptions已不复存在，它们允许一个应用程序删除整个应用程序集，因为它们共享相同的进程空间。
The Dropwizard Stack
DropWizard在这些强大的库之上提供了一些非常直观的抽象，使编写生产就绪的微服务变得非常容易：
• Jetty 作为 servlet容器
• Jersey 作为 REST/JAX-RS实现， Jackson 作为 JSON 序列化和反序列化
• HibernateValidator
• Guava
• Metrics
• Logback + SLF4J
• JDBI 处理 databases
DropWizard非常固执己见，认为“只要开始写代码就行了”。折中的是，如果你想修补底层堆栈，这不是很容易.。另一方面，快速启动和运行以便交付业务价值要比自己配置组件容易得多。Jetty、Jeresy和Jackson都是著名的生产级库，用于编写基于REST的服务。谷歌的Guava库提供实用程序和不可变的编程。DropizerMetrics库是一个非常强大的度量库，它提供了足够的洞察力来管理生产中的服务。事实上，Metrics库是如此强大和流行，它被衍生为自己的项目，可以与SpringBoot或WildFlySwarn一起使用。
DropWizard公开了开发人员应该熟悉的以下抽象。如果您能够理解这些简单的抽象概念，那么使用DropWizard就会非常有效率：
Application（应用）
包含我们的 public void main() 方法
Environment（环境）
我们把servlet、资源、过滤器、健康检查、任务、命令等放在哪里
Configuration(配置)
如何注入特定环境和应用程序的配置
Commands （命令）
告诉DropWizard启动微服务时要采取的操作(例如，启动服务器)
Resources（资源）
REST/JAX-RS
Tasks
管理应用程序时要执行的管理任务(如更改日志级别或暂停数据库连接)
当在开箱即用的情况下运行DropWizard应用程序时，创建一个Jetty服务器使用两个处理程序：一个用于应用程序(默认情况下为8080)，另一个用于管理接口(默认情况下为8081)。该向导这样做是为了让您可以公开您的微服务，而无需在同一端口上公开管理详细信息(例如，可以将8081保留在防火墙之后，因此无法访问)。像度量和健康检查这样的事情会通过管理端口公开，所以要注意适当地保护它。
原文：
作者源码：https://github.com/redhat-developer/microservices-by-example-source