Chris Richardson 的微服务架构网站
本站由 Kong 提供支持微服务架构咨询和培训服务
本站点由 Chris Richardson 编写和维护，他是经典技术著作《POJOS IN ACTION》一书的作者，也是 cloudfoundry.com 最初的创始人。Chris 的研究领域包括 Spring、Scala、微服务架构设计、领域驱动设计、NoSQL 数据库、分布式数据管理、事件驱动的应用编程等。Chris 是一位连续创业者，eventuate.io 是他的最新创业项目，一个微服务应用和数据服务平台。
Chris 定期为企业提供微服务设计培训和实战项目的架构咨询服务。近年来 Chris 多次访问中国，为包括华为、SAP、惠普、东风汽车等大型企业提供微服务架构相关的技术咨询服务。如您希望与 Chris 深入交流，建立合作，请点击下方按钮跟他取得联系。
模式库
核心模式
服务拆分
部署模式
需要关注的边界问题
通讯模式
数据管理
安全模式
- 访问令牌new
可测试性
可观测性
UI 模式
- 服务器端页面碎片化元素构建new
- 客户端 UI 构建new
全新的微服务应用支撑平台，成功解决微服务架构下分布式数据管理的难题。
加入 微服务架构的 Google 讨论组（需要翻墙）
模式: 单体架构
背景
在开发服务端企业应用时，应用需要支持各种不同类型的客户端，比如桌面浏览器、移动浏览器以及原生移动应用。应用还需要向第三方提供可访问的API，并通过Web Service或者消息代理与其它应用实现集成。应用通过执行业务逻辑、访问数据库、与其它系统交换信息、并返回一条HTML/JSON/XML响应，来处理请求（HTTP请求与消息）。
应用采用多层架构或者六角架构，主要由以下几类不同组件构成：
- 展现组件——负责处理HTTP请求并响应HTML或者JSON/XML（对于web Services APIs）
- 业务逻辑——应用的业务逻辑
- 数据库访问逻辑——用于访问数据库的数据访问对象
- 应用集成逻辑——消息层，例如基于Spring Integration
不同逻辑组件分别响应应用中的不同功能模块。
问题
应用的部署架构是什么？
需求(Forces)
- 应用需要由一个开发者团队专门负责
- 团队新成员需要快速上手
- 应用应该易于理解和修改
- 对应用能够进行持续部署
- 需要在多台设备上运行应用副本，从而满足可扩展性与可用性的要求
- 使用各种新技术（框架、编程语言等）
方案
使用单体架构构建应用。例如：
- 单个Java WAR文件。
- 单个Rails或者NodeJS代码目录层级。
举个栗子
假设需要构建一款电子商务应用程序，使其能够接收来自客户的订单、验证库存信息与可用信用额度，而后进行发货。该应用程序会包含多个组件，其中StoreFrontUI负责实现用户界面，而其它后端服务则分别负责检查信用额度、维护库存信息以及发送订单。
应用被当作一个单体进行部署。例如：一个 Java Web 应用仅包含一个运行在 Tomcat 之类的 Web 容器上 WAR 文件。一个 Rails 应用由单一目录层级构成，该目录层级的部署通过在 Apache/Nginx 上使用 Phusion Passenger，或者在 Tomcat 上使用 JRuby 得以实现。为了提高扩展性和可用性，你可以在负载均衡器之后运行此应用的多个实例。
结果（Resulting context）
这类解决方案拥有以下优势：
- 易于开发 — 当前开发工具与IDE的设计目标即在于支持单体应用的开发。
- 易于部署 — 你只需要将该WAR（或者目录层级）部署在合适的运行环境中即可。
- 易于扩展 — 你可以在负载均衡器后面运行多个应用副本实现扩展。
然而，一旦应用变大、团队扩大，这种方案的弊端将会变得愈发明显：
- 单体应用巨大的代码库可能会让人望而生畏，特别是对那些团队新成员来说。应用难以被理解和进行修改，进而导致开发速度减慢。由于没有清晰的模块边界，模块化会逐渐消失。另外，由于难以正确把握代码变化，导致代码质量逐步下滑，陷入恶性循环。
- 过载的IDE——代码库越大，IDE速度越慢，开发者的生产效率越低。
- 过载的Web容器——应用越大，Web容器启动时间越长。容器启动耗费时间，极大影响到开发者的生产效率。对部署工作也有负面影响。
- 持续部署困难——巨大的单体应用本身就是频繁部署的一大障碍。为了更新一个组件，你必须重新部署整个应用。这会中断那些可能与更改无关的后台任务（例如Java应用中的Quartz任务），同时可能引发问题。另外，未被更新的组件有可能无法正常启动。重新部署会增加风险，进而阻碍频繁更新。因为用户界面开发者经常需要进行快速迭代与频繁重新部署，所以这对用户界面开发者而言更加是个难题。
- 应用扩展困难——单体架构只能进行一维伸缩。一方面，它可以通过运行多个应用副本来增加业务容量，实现扩展。一些云服务甚至可以根据负载量动态调整实例数量。但在另一方面，数据量增大会使得该架构无法伸缩。每个应用实例需要访问所有数据，导致缓存低效，加大内存占用和I/O流量。另外，不同的应用组件有不同的资源需求——有的是CPU密集型的，另外一些是内存密集型的。单体架构无法单独伸缩每个组件。
- 难于进行规模化开发——单体应用是规模化开发的障碍。应用一旦达到特定规模，需要将现有组织拆分成多个团队，每个团队负责不同的功能模块。举例来说，我们可能需要设立UI团队、会计团队、库存团队等等。单体应用的问题在于它使团队无法独立展开工作。团队需要在工作进度和重新部署上进行协调。对于各团队而言，这使得变更和更新产品变得异常困难。
- 需要长期关注同一套技术栈——单体架构迫使我们长期使用在开发初期选定的技术堆栈（在某些情况下，可能是某些技术的特定版本）。单体应用是渐进采用新技术的障碍。举例来说，如果我们选择了JVM，那么我们可以选择Java以外的一些语言，因为Groovy和Scala等基于JVM的语言也可以和Java进行良好的互操作。但此时以非JVM语言编写的组件就无法在该单体架构中使用。另外，如果大家所使用的应用平台框架已经过时，那么我们将很难将应用迁移到其它更新并且更完善的框架当中。有时候为了采用一套新型平台框架，我们甚至需要重写整个应用，这是风险很大的工作。
相关模式
微服务架构 是一种能够解决单体架构各种局限的备选模式。
已知案例
知名的互联网服务商最初皆采用单体架构，包括 Netflix、Amazon.com 以及 eBay 等等。作者开发的大多数 Web 应用也是用单体架构。
变体
无
致谢
为了避免重复翻译，本文根据中国普元公司宋潇文先生的译文整理修订，在此向宋潇文先生表示感谢！