[翻译]微服务设计模式 - 1. 单体应用模式

原文地址：https://microservices.io/patterns/monolithic.html

场景描述

假设你正在开发一个大型服务端企业应用，有以下需求：

• 必须支持多种客户端，包括：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团队、会计团队、库存团队等等。单块应用程序的问题在于它阻止了团队独立工做。小组必须协调他们的开发工做和从新部署。对于一个团队来讲，进行更改和更新生产要困可贵多。
• 须要长期使用同一个技术栈。一种单一的体系结构迫使您与您在开发开始时所选择的技术堆栈(在某些状况下，与该技术的特定版本)结合在一块儿。有了单体应用程序，就很难逐步采用一种较新的技术。好比你使用的框架中止更新，或者过期了，在单体应用下很难逐步采用一个新的框架实现。