场景描述
假设你正在开发一个大型服务端企业应用，有如下需求：
- 必须支持多种客户端，包括：WEB 端浏览器、WAP 端浏览器以及原生移动 APP。
- 对外暴露公共 API 用于调用
- 处理 HTTP 请求，或者消息，执行对应的业务逻辑。
- 访问数据库，缓存或者持久化响应的数据
- 与其他系统进行通信，交换所需的信息
- 返回 HTTP 响应，指定好特定的序列化方式，例如 JSON、 XML 等等
- 根据业务逻辑与功能，设计并划分出不同逻辑模块
这样的一个应用，你会如何设计架构并部署呢？
考虑因素
- 这是一个团队开发的项目，有一个独立团队负责
- 团队成员会发生变化，新加入的成员必须快速上手项目
- 应用程序必须易于理解并修改
- 期望能实现应用的持续集成与部署
- 必须可以多实例部署应用程序，以满足可伸缩性和可用性要求。
- 想用比较新的技术（框架、编程语言等）
解决方案
使用单体架构，例如：
- 一个 Java WAR 文件启动的程序
- 一个单目录 Rails 或者 NodeJS 程序
举例
假设现在正在设计一个电商应用，功能包括接收来自客户的订单（StoreFrontUI），验证并维护库存余额（Inventory Service），验证并维护用户可用余额（Accounting Service），下单成功并发货（Shipping Service）。这个应用被设计成一个单体架构应用，例如：JavaWeb 应用程序由运行在Web容器(如 Tomcat )上的单个 WAR 文件组成。Rails 应用程序由部署在 Nginx 或 Tomcat 上的 JRuby 或 Nginx 上的单一目录层次结构组成。可以在负载均衡器后面部署多个实例，以扩展和提高可用性。
分析
这种解决方案的好处有：
- 开发简单，当前的 IDE 基本都是按照开发单体应用程序开发的。
- 部署简单，只要把一个文件或者目录部署到 Web 容器里即可。
- 扩容简单，通过在负载均衡器后面部署多个实例就能实现扩容。
但是，随着产品不断迭代，这个单体应用程序将会变得越来越大，团队的规模也越来越大，这种单体设计就会有一些缺点，并且这些缺点会变得越来越严重：
- 单体应用代码在同一个代码库，这个代码库会越来越大，使开发人员感觉会很头大，特别是那些刚加入团队的开发人员。应用程序将很难理解和修改，因此，开发速度通常会被减缓。另外，由于没有明确的模块边界，代码内部的模块化会随着时间的推移而越来越模糊。此外，由于很难理解如何正确实现更改，并且可能还需要兼容老版本的错误，因此代码的质量会随着时间的推移而下降，慢慢堆积成为屎山。
- IDE 的压力会很大。代码库越大，IDE 会更慢，IDE 一般为了智能补全代码的功能，会对代码做索引并加载到内存中。臃肿的代码会拖慢 IDE，降低开发效率。
- Web 容器压力变大。程序越臃肿，启动时间会被拖长，导致代码调试变慢，同时部署时间也会变长。
- 持续集成部署难度越来越大。为了更新一个组件，您必须重新部署整个应用程序。这会导致所有业务，不管是否有更新，都被影响或者中断。同时，如果出现问题，回滚时间也会增长。因此，这限制了程序不能持续频繁更新。
- 不能灵活扩展。不同业务模块可能压力不同，以及压力大的时间段可能也不同，但是每次扩容，都需要所有模块一块扩容，造成了浪费。
- 故障扩散。如果有一个模块出了问题导致内存泄漏，那么整个业务都会受到影响。
- 团队分工的障碍。例如，我们可能希望有UI团队、会计团队、库存团队等等。单块应用程序的问题在于它阻止了团队独立工作。小组必须协调他们的开发工作和重新部署。对于一个团队来说，进行更改和更新生产要困难得多。
- 需要长期使用同一个技术栈。一种单一的体系结构迫使您与您在开发开始时所选择的技术堆栈(在某些情况下，与该技术的特定版本)结合在一起。有了单体应用程序，就很难逐步采用一种较新的技术。比如你使用的框架停止更新，或者过时了，在单体应用下很难逐步采用一个新的框架实现。
