关于Spring Cloud的思考和总结

博主开发使用了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.