梁晓勇 译 分布式实验室
微服务的趋势已经让人无法忽视。有些人可能会说它只不过是又一个故弄玄虚的流行词，而另一些人可能会列举出分解单体应用的优势，或者反其道而行，专注于其不足之处。
在本文中，我们将专注于Java生态系统，从务实角度看待我们所掌握的实际用于实现微服务的框架，来看看它们到底是什么。让我们开始吧。
这个画饼是个谎言
我们要问的第一个问题是，我们真的需要一个专门的框架用于构建微服务么？答案是否定的。你能用微服务框架构建一个单体应用么？是的。那么，如果真的由你来决定怎么做的话，微服务框架相比Java EE或Spring有什么好处？是什么让它值得采用？它们是否同时解决了内部架构和外部架构的问题？
在接下来的几节中，我们将进一步了解Java EE及其新的微型化方案：Spring及Spring Boot、使用Lagom的Lightbend栈，以及其他的开源解决方案，例如Spotify的Apollo。
在我们继续之前，有必要说明一下，关于什么是微服务架构并没有一个清晰的定义。ThoughtWorks首席科学家Martin Fowler在他第一篇讲述微服务的文章中曾尝试这么定义它：
“微服务架构风格是将一个单一应用程序作为一系列小服务来开发的一种方式，每个服务都运行在自己的进程中，并使用轻量级的机制进行通信，通常是HTTP资源API。这些服务围绕业务能力进行构建，并可通过全自动部署装置进行独立部署”。
本文不讨论微服务的优势和劣势，并假定你只是简单地对支撑它的底层技术感兴趣。另外一篇涵盖调试微服务的主要挑战的问题文章值得一看，这是很多人在考虑微服务架构时没考虑的常见错误。
我们将对下列技术/平台/框架进行逐一分析。
1. Java Enterprise Edition
构建应用程序的传统Java EE方法是针对单体应用的，后者随着时间推移往往会变成……意式代码怪兽。传统上，一个企业应用程序将被打包成一个单一的EAR（Enterprise Archive）部署单元，这包括了WAR（Web Archive）文件和JAR（Java Archive）文件。
是的，“老态龙钟”的Java EE也可以用于微服务架构。想深入了解将Java EE单体应用重构为微服务框架的示例，可参考Arun Gupta的这篇文章（http://blog.arungupta.me/monolithic-microservices-refactoring-javaee-applications/），他通过一个购物车的示例应用程序讲解了这个过程所需的步骤。
虽然Java EE 8的开发有所放缓，其背后的“非官方”社区依然活力十足。来自Java EE Microprofile的成员针对微服务架构提出了优化企业Java的一个新方案。你可以在此加入讨论（https://groups.google.com/forum/#!forum/microprofile）。
在思考Java EE微服务时可以考虑的另一个有趣的项目是Kumuluz。这个框架利用你现有的Java EE知识，提供了一个无痛的方式供你手工挑选应用程序所需的组件，而无须在配置上浪费过多时间。
综述：Java EE及它周边的项目完全适合微服务，但未解决运维方面的问题，并且其使用与最佳实践留给你个人解读。
2. Lightbend：Play、Akka、ConductR及Lagom
Lightbend（此前为Typesafe）提供了更多选项。与Kumuluz相比普通Java EE的优势类似，Lagom用其引擎中的Play、Akka和ConductR包装了Lightbend栈，提供了构建微服务的一种更简单的方法。它的底层组件还包括了Cassandra、Guice、Jackson、slf4j、Logback及传统的Lightbend组件。
Lagom（瑞典语“恰到好处”的意思）还处在起步阶段，不过它看起来像是Lightbend栈的一个可靠方向。在一次与InfoQ的访谈中，Lightbend的CTO Jonas Boner说道：“市面上多数的微服务框架致力于简化单个微服务的构建——这是比较容易的部分。Lagom将其扩展到微服务的系统上，大型系统——这是比较困难的部分，因为我们面对的是分布式系统的复杂性。”
综述：Lagom将Lightbend的功能包裹在一个框架中，包括了ConductR提供的运维功能。它不仅关注单一的微服务，还关注作为一个整体的系统。
3. Spring、Spring Boot及Spring Cloud
虽然Spring及Spring Boot未称呼它们自己为微服务框架，Spring网站在其首页也未提及微服务，但这不代表它们被排除在外。似乎他们是有意不叫它为微服务以远离流行词炒作。
在Spring Cloud中，Spring栈利用Netflix的Eureka和Ribbon来支持分布式系统（经常与“微服务”重叠的术语）的开发。这些功能包括配置管理、服务发现、智能路由、控制总线、领导者选举、分布式会话等等。
要深入了解如何使用Spring及几个额外的Netflix和其他开源项目来构建微服务，可阅读InfoQ的这篇文章（https://www.infoq.com/articles/spring-cloud-service-wiring）。
综述：Spring在微服务开发中处于有利位置，并且提供了解决运维角度问题的外部开源项目的方案。
4. Dropwizard
与Spring类似，Dropwizard也未过多地谈论微服务。它是一个Java框架，用于开发对运维友好的、高性能的、REST化的Web服务。它具有一套固有的Java库，能让构建适用生产环境的Java应用程序变得更简单。
Dropwizard Modules可以整合那些不在Dropwizard核心内的额外项目，其社区也开发了一些模块用以整合类似Netflix Eureka的项目，可与Spring Cloud媲美。
此前我们已经对Dropwizard和Spring Boot进行过一对一的比较，对彼此的功能进行考查。
综述：与Spring和Privotal、Java EE和Oracle、Lagom和Lightbend不同的是，由于Dropwizard是一个社区项目，没有大公司的支持，它的开发进度可能会比较慢，不过它背后具有一个强大的社区，不论是对大型公司或是小一点的项目来说，都是一个不错的框架。
5. Spotify Apollo、VertX及其他“微框架”
除了我们这里说的四个重量级选手，还有很多项目值得一提，也可用于编写微服务：
Vertx：用于在JVM上构建响应式应用程序的工具包。有人认为它应该在四巨头中占有一席之位。
Spotify Apollo：Spotify在编写Java微服务时使用的一组Java库。Apollo包括了类似HTTP服务器、URI路由系统的功能，可轻松实现REST化服务。
其他框架包括Spark、Ninja、Jodd、Restlet及Bootique.io。
综述：Java微服务的舞台如此巨大，那些轻量级选手也值得关注。
6. 微服务的必备条件
正如Martin Fowler在他的微服务的必备条件（http://martinfowler.com/bliki/MicroservicePrerequisites.html）文章中所说，“当你的监控指出一个问题时，确保你能快速响应就显得至关重要。特别是需要开发团队和运维参与的故障管理，既要修复直接的问题，又要进行根源分析以确保修复底层的问题”。与此类似的，Hackernews上的这个主题和文章分享了更多在你还没为微服务构架做好准备时可能碰到的问题。
在OverOps，我们正在构建一个工具来解决这个痛苦，它可显示生产环境中代码崩溃的时间、位置及原因。这是一个绝无仅有的工具，可展示完整的源代码，以及针对每个异常、记录的警告和错误跨越整个调用栈的变量状态。点这去瞧瞧（http://land.overops.com/why-overops/）。
综述：微服务是有代价的，并不适合每个系统。如果你正在选择微服务架构，在深入之前你应该要了解其代价，并确定你需要改进的流程。
结语
你正在使用的是哪个框架或平台并不重要，构建微服务与它们的耦合并不紧密。它只是一种思维及一种架构手段，你应该选择那些对你而言生产力更高的方案。
除此之外，成功实现一个微服务框架并不止于应用程序本身。围绕它的多数成本来自于所谓的DevOps过程、监控、CI/CD、日志变更、服务器配备等等。我们将在未来的文章中对这些方面进行阐述，我们乐于听取你的想法，并在未来的文章对其进行讨论。欢迎通过@overopshq进行联系。
