背景
你正在开发一个服务端的企业应用程序。它必须支持不同的客户端，包括桌面浏览器，移动端浏览器和原生手机应用。它需要暴露一个API接口给第三方消费。它需要通过web service或者消息机制与其他应用程序集成。它接受请求（HTTP请求和消息）；执行业务逻辑；访问数据库；与其他系统交换数据；返回HTML/JSON/XML响应。这个应用中，不同的功能区域都对应着不同的逻辑组件。
问题
该应用的部署架构？
限制
一个团队的开发人员正在开发这个应用
新的团队成员应该迅速上手
该应用应该容易理解和修改
你想尝试持续部署
你必须在不同机器上运行该应用的拷贝，以满足可扩展性和可用性的需求
你想尝试新的技术（框架，编程语言等）
解决方案
构建一个单体架构的应用程序，例如：
单个Java WAR文件
单个包含Rails或者NodeJS代码的文件夹
示例
设想以下，你正在构建一个商城应用程序，为客户生成订单，验证库存和可用积分，快递商品。这个应用程序由以下几个组件构成：商城前端UI，它包括了用户界面；后端服务，包括检查积分，管理库存和运送商品。
这个应用程序被部署成一个单体应用程序。比如，一个包含单一WAR文件，运行在Tomcat之类的Web容器下的Java网站项目。一个Rails应用，包含单一文件夹，用Phusion Passenger部署在Apache/Nginx上，或者用JRuby部署在Tomcat上。为了实现扩展性和可用性，你可以在一个负载均衡容器后面运行应用的多个实例。
单体架构应用程序
结果
该解决方案有以下几个优势：
- 开发简单 - 当前使用的开发工具和IDE可以支持单体应用的开发
- 部署简单 - 只需要简单的将WAR文件（或者一整个文件夹）部署在适当的运行环境
- 扩展简单 - 通过在负载均衡容器后运行应用的多个副本，可以实现扩展
但是，一旦该应用变得庞大，并且团队规模不断扩大，这种方法就会存在日益显著的弊端：
- 大型单体应用代码吓跑了开发人员，尤其是新进团队的成员。应用可能很难被理解和修改。带来的后果是，开发速度降低。而且，由于没有明显的模块边界，模块化会随着时间的推移而崩溃。此外，由于很难理解如何正确的实现一个修改，代码质量随着时间的推移也会下降。这是一个漩涡。
- 超载的IDE - 代码体量越大，IDE越慢，开发人员效率越低
- 超载的web容器 - 应用越大，启动时间越长。由于时间浪费在等待web容器启动，开发人员的效率受到巨大的影响。同时也影响了部署。
- 持续部署困难 - 大型单体应用也是频繁部署的障碍。为了更新一个组件，你需要重新部署整个应用程序。不管后台任务（例如：Java应用里的Quartz任务）是否被这次变更影响，他们都会被中断，这通常会导致故障。还有可能就是未更新的组件可能无法正确启动。带来的后果是，重新部署的风险上升，因此不鼓励频繁更新。这对开发用户界面的开发者是个问题，他们通常需要快速迭代和频繁部署。
- 扩展应用困难 - 单体应用仅能在同一纬度扩展。一方面，它可以通过运行更多副本来提升交易量。一些云甚至可以根据负载动态调整实例数量。另一方面，这种架构无法随着数据量的增加而扩展。应用程序的每个实例都去访问数据库，这会导致缓存效率降低，增加内存消耗和I/O流量。而且，不同的应用组件有不同的资源需求 - 某些可能是CPU密集型，而其他可能是内存密集型。在单体应用中，我们无法独立扩展每个组件
- 扩展开发的障碍 - 单体应用也是扩展开发的障碍。一旦应用程序达到一定规模，就可以将工程师组建为团队专注于特定功能区域。例如，我们可能希望拥有UI团队，会计团队，库存团队等等。单体应用的问题是它组织了团队独立工作。团队之间必须协调他们的开发成果和重新部署。一个团队更改或者更新产品会更困难。
- 需要对一个技术栈的长期支持 - 单体应用强迫你与最初开发时选择的技术栈结合（某些情况下，与该技术栈的特定版本）。使用单体应用，很难逐步采用更新的技术。假如，设想下你选择了JVAM。你可以选择一些语言，除了Java外，还有其他与Java很好交互的JVM语言，例如Groovy和Scala。但是非JVM语言编写的组件在你的单体应用中没有一席之地、还有，如果你的应用使用的框架随后过时了，迁移应用到一个更新更好的框架会是一大挑战。很可能为了采用一个新的框架，你不得不重写整个应用程序，这是一个冒险。
关联的模式
微服务模式是解决单体模式局限性的替代模式
已知案例
知名的互联网服务，例如Netflix, Amazon.com和eBay最初都有一个单体架构。作者开发的大部分web应用程序都是单体架构。
网友评论