尽管应用有一个逻辑模块化架构,但它被作为一个单体进行打包和部署。实际格式取决于应用所用的语言和框架。比如,许多 Java 应用被打包成 WAR 文件部署在如 Tomcat 或者 Jetty 之类的应用服务器上。还有部分 Java 应用被打包成自包含(self-contained)的可执行 JAR。类似地,Rails 和 Node.js 应用被打包成有一定层次结构的目录。

使用这种风格编写的应用很常见,也很容易开发,因为我们的 IDE 和其他工具本身就专注于构建单体应用。这些应用也很容易测试,你可以通过简单地启动并使用如 Selenium 测试包来测试 UI 以轻松地实现端到端(end-to-end)测试。单体应用同样易于部署,你只需拷贝打包好的应用到服务器上。你还可以通过运行多个副本逼并结合负载均衡来扩展应用。在项目的早期阶段,它可以良好地运作。

使用这种风格编写的应用很常见,也很容易开发,因为我们的 IDE 和其他工具本身就专注于构建单体应用。这些应用也很容易测试,你可以通过简单地启动并使用如 Selenium 测试包来测试 UI 以轻松地实现端到端(end-to-end)测试。单体应用同样易于部署,你只需拷贝打包好的应用到服务器上。你还可以通过运行多个副本并结合负载均衡来扩展应用。在项目的早期阶段,它可以良好地运作。

<a id="marching-toward-monolithic-hell"></a>

单体应用的另一个问题是可靠性。因为所有模块都运行在同一进程中。任何模块的一个 bug,比如内存泄漏,都可能会拖垮整个进程。此外,由于应用的所有实例都是相同的,错误将影响到整个应用的可用性。

最后但同样重要,单体应用使得采用新框架和语言变得非常困难。例如,我们假设你有 200 万行代码使用了 XYZ 框架编写。如果使用较新的 ABC 框架来重写整个应用,这将非常昂贵(时间和成本方面),即使框架非常好。因此,这对于新技术采用是一个非常大的障碍。在项目开始时,你无论选择何种新技术都会感到困扰。

最后同样重要的是,单体应用使得采用新框架和语言变得非常困难。例如,我们假设你有 200 万行代码使用了 XYZ 框架编写。如果使用较新的 ABC 框架来重写整个应用,这将非常昂贵(时间和成本方面),即使框架非常好。因此,这对于新技术采用是一个非常大的障碍。在项目开始时,你无论选择何种新技术都会感到困扰。

总结一下:你有一个成功的关键业务应用,它已经发展成为一个只有少数开发人员能够理解的巨大单体。它使用了过时、非生产性技术编写,使得招聘优秀开发人员变得非常困难。应用变得难以扩展,不可靠。因此敏捷开发和应用交付是不可能的。

部署基于微服务的应用也是相当复杂的。一个单体应用可以很容易地部署到基于传统负载均衡器的一组相同服务器上。每个应用实例都配置有基础设施服务的位置(主机和端口),比如数据库和消息代理。相比之下,微服务应用通常由大量的服务组成。例如,据 [Adrian Cockcroft][22] 了解到,Hailo 拥有 160 个不同的服务,Netflix 拥有的服务超过 600 个。

每个服务都有多个运行时实例。还有更多的移动部件需要配置、部署、扩展和监控。此外,你还需要实现[服务发现机制](4-service-discovery.md),使得服务能够发现需要与之通信的任何其他服务的位置(主机和端口)。比较传统麻烦的基于票据(ticket-based)和手动的操作方式无法扩展到如此复杂程度。因此,要成功部署微服务应用,需要求开发人员能高度控制部署方式和高度自动化。

每个服务都有多个运行时实例。还有更多的移动部件需要配置、部署、扩展和监控。此外,你还需要实现[服务发现机制](4-service-discovery.md),使得服务能够发现需要与之通信的任何其他服务的位置(主机和端口)。相比较,传统的基于票据(ticket-based)和手动的操作方式无法扩展到如此复杂的程度。因此,要成功部署微服务应用,需要求开发人员能高度控制部署方式和高度自动化。

一种自动化方式是使用现成的平台即服务(PaaS),如 [Cloud Foundry][23]。PaaS 为开发人员提供了简单的方式来部署和管理他们的微服务。它让开发人员避开了诸如采购和配置 IT 资源等烦恼。同时,配置 PaaS 的系统人员和网络专业人员可以确保达到最佳实践以落实公司策略。