一 单体应用架构存在的问题
一个归档包（例如 war 格式）包含所有功能的应用程序，通常被称为单体应用。拿一个电影售票系统为例，架构图可能是这样的。
虽然该应用已经按照模块进行划分，但是最终UI和各模块都被打在了一个war包下，所以这样都应用也是一个单体应用。
在项目初期，单应用是非常普遍的，单体应用比较容易测试，部署，在项目的初期可以很好的运行，但是随着代码库的增大，开发人员的流动，单体应用会变得越来越臃肿，灵活性下降，维护成本也越来越高。
- 复杂性高：当所有的代码都在统一代码库中时，我们很难分清楚模块之间的联系，这就会导致我们每次修改代码都会心惊胆战。
- 部署频率低：随着代码的增多，构建和部署的时间也会增加，这样就会导致部署的风险非常大，都不愿意去部署，从而导致部署频率降低，一旦出现部署错误，修复成本会非常高。
- 可靠性差：一旦出现某个bug，整个系统都将不可用
- 拓展能力差
- 阻碍技术创新：团队人员都得使用同一语言去开发，很难更新技术
二 什么是微服务
那么为了解决单体应用所带来的问题，微服务就诞生了：
微服务架构风格是一种将单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务之间通信采用轻量级通信机制。这些服务围绕业务能力构建并且通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理，服务可用不同的语言开发，使用不同的数据存储技术。
微服务的一些特点：
- 每个服务可独立的运行在自己的进程里
- 一系列独立运行的微服务共同构建起整个系统
- 每个服务独立的业务开发，一个微服务只关注某一特定的功能。
- 微服务之间采用轻量级的通信技术进行通信。
- 可以使用不同的语言和存储技术
- 全自动的部署机制
对于单体应用的电影售票系统，使用微服务来架构该应用。
微服务架构的优点
- 易于开发和维护：一个服务只关注一个特定的业务功能，业务清晰，代码量少，开发和维护相对简单
- 单个服务启动较快
- 易于部署
- 技术栈不受限
- 按需伸缩：根据需求，实现细粒度的拓展
微服务架构面临的挑战
- 运维要求高：更多的服务意味着需要投入更多的运维投入
- 分布式的复杂性：微服务构建的是分布式系统，系统容错，网络延迟，事务等都会带来巨大都挑战
- 接口调整成本高：服务之间的通信
- 重复劳动：很多服务可能都会用到同一个功能，而这个功能又没能达到分解为一个微服务的程度，这个时候用到这个功能的服务都需要写一套这个功能，从而导致代码重复。如果使用的是同一技术栈，则可以将相同的功能抽成一个公共组件。
三 Spring Cloud 简介
Spring Cloud 则是微服务架构实现的一种框架，是在 Spring Boot 的基础上构建的，用于快速构建分布式系统的通用模式的工具集。
二 特点
- 约定优于配置
- 适用于各种环境
- 隐藏了组件的复杂性
- 开箱即用，快速启动
- 轻量级的组件。例如：Eureka、Zuul等
- 组件丰富，功能齐全
- 灵活，Spring Cloud 的组成部分是解藕的
四 版本
大多数 Spring 项目都是以 “主版本号.次版本号.增量版本号.里程碑版本号”的形式命名版本号。而 Spring Cloud 是一个综合项目，它包含很多子项目，由于子项目也都维护着自己的版本，为了避免混淆，Spring Cloud 是以 “单词SRX(X为数字)” 的形式命名版本号的。
其中“英文单词”叫做 release train， Angel、Brixton、Camden 等都是伦敦地铁站的名称。它们按照字母顺序发型，可将其理解为主版本的演进。“SR” 表示 Service Release 一般表示 Bug 修复。在 SR 版本发布之前，会现发布一个 Release 版本，例如：Camden RELEASE
