微服务架构设计模式
第一章 逃离单体地狱
1.1 单体架构的好处
开始阶段，应用程序相对较小的背景下，单体架构拥有以下好处：
- 应用的开发相对简单
- 易于对应用程序做大规模的修改
- 测试相对简单
- 部署简单明了
- 横向扩展简单
1.2 什么是单体地狱？
随着时间的推移，当程序不断的向巨无霸式单体应用程序演进的时候，就会暴露出很多问题。
- 过度的复杂性会吓退开发者。系统过于复杂与庞大，以至于开发者很难理解它的全部。
- 开发速度缓慢。编辑、构建、部署、自测流程时间拉长。
- 从代码提交到实际部署的周期很长，而且容易出问题。同一代码库，拉取合并分支的方式。
- 难以扩展。应用的不同模块对资源的需求是有冲突的。有些需要大内存，而有些需要多CPU。
- 交付可靠的单体应用是一项挑战。缺乏故障隔离，一个模块的问题可能导致整个程序不可用。如内存泄露
- 需要长期依赖某个可能过时的技术栈。团队在单体地狱中采用一套相同的技术方案，尝试采用新技术都是高风险和高代价。
1.3 拯救之道：微服务架构
软件架构其实对功能性需求影响不大，架构的重要性在于它影响了应用的非功能性需求，也称为质量需求。
现在针对大型复杂应用的开发，越来越多的共识趋向于考虑使用微服务架构。尝试考虑下怎么定义微服务的概念？
1.3.1 扩展立方体和服务
扩展立方体模型描述了扩展一个应用程序的三种维度：X、Y和Z。