博主开发使用了Spring Cloud，使用过程中的一些学习和经验，体会通过本博文进行记录。
以前的架构，单体应用：
加入ESB，通过总线进行调用：
微服务架构：
区别:
- SOA架构主要针对企业级，采用ESB服务(ESB企业服务总线），非常重，需要序列化和反序列化，采用XML格式传输。
- 微服务架构主要用于互联网公司，轻量级，小巧，独立运行，基于HTTP+Rest+JSON格式传输
- ESB可以说是传统中间技术与XML、Web服务等技术相结合的产物。
单体架构存在的缺点：
- 复杂性逐渐变高
- 技术债务主键上升
- 部署速度主键变慢
- 阻碍技术创新
- 无法按需伸缩
微服务概念论文翻译版参考：https://www.cnblogs.com/beanbag/p/9911452.html
- 简而言之，微服务架构风格[1]这种开发方法，是以开发一组小型服务的方式来开发一个独立的应用系统。其中每个小型服务都运行在自己的进程中，并经常采用HTTP资源API这样轻量的机制来相互通信。这些服务围绕业务功能进行构建，并能通过全自动的部署机制来进行独立部署。这些微服务可以使用不同的语言来编写，并且可以使用不同的数据存储技术。对这些微服务，我们仅做最低限度的集中管理。（去中心化）
- “微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间相互协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务和服务之间采用轻量级的通信机制相互沟通（通常是基于HTTP的Restful API).每个服务都围绕着具体的业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建"
- 微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。
微服务架构应该具备的特性
- 每个微服务可独立运行在自己的进程里。
- 一系列独立运行的微服务共同构建起整个系统。
- 每个服务为独立的业务开发，一个微服务只关注某个特定的功能，例如订单管理、用户管理等。
- 微服务之间通过一些轻量的通信机制进行通信，例如通过RPC或者RESTful API进行调用。
- 可以使用不同的语言与数据存储技术。
- 全自动的部署机制。
微服务优点：
- 易于开发和维护
- 启动较快
- 局部修改容易部署
- 技术栈不受限
- 按需伸缩
- DevOps
经验总结：
Spring Boot banner可以定制的
各种依赖后，Tomcat也引入了。
Spring Boot 可配置项很多，比如 context path 我们之前在Servlet 中可以配置的
Spring Boot可以通过gradle最终打成的是boot jar 全部依赖都在里面，非常独立。打成一个可执行的jar包。通过命令行可以直接运行。web.xml也没有了。但是也可以通过Spring提供的入口方式恢复，但是很多情况下是没必要的。
解压后：
Jar包里面的内容解释：
1.BOOT-INF:里面包含的是：
开发的编写的Java编译后的class字节码。 还有依赖的Jar包。 配置文件。
2.META-INF:
其中maven:
MANEFST.MF: 清单文件，描述可执行jar包的一些信息。
3. org的包结构里面的内容。非常重要。
Spring Boot集成 dubbo.在使用dubbo时候，dubbo会提供一个starter.