Spring Cloud 学习笔记(1)--Greenwich.SR4

 

什么是微服务？

微服务架构风格是一种将一个单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制（通常用HTTP资源API）。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理，服务可用不同的语言开发，使用不同的数据存储技术。
     微服务架构应该具备以下特性：

• 每个微服务可独立运行在自己的进程里。

• 一系列独立运行的微服务共同构建起整个系统。

• 每个服务为独立的业务开发，一个微服务只关注某个特定的功能，例如订单管理，用户管理等。

• 微服务之间通过一些轻量的通信机制进行通信，例如通过RESTful API进行调用。

• 可以使用不同的语言与数据存储技术

• 全自动部署机制

 

聚合器微服务设计模式 这是一种最常用也最简单的设计模式（见下图）

6种微服务设计模式参考： https://blog.csdn.net/stubborn_cow/article/details/50287597

 

微服务框架有哪些？

    Dubbo 是阿里开源的一款高性能 RPC 框架，特性包括基于透明接口的 RPC（Remote Procedure Call,即远程过程调用）、智能负载均衡、自动服务注册和发现、可扩展性高、运行时流量路由与可视化的服务治理。

    Dubbo是阿里巴巴内部使用的分布式业务框架，2012年由阿里巴巴开源。由于Dubbo在阿里内部经过广泛的业务验证，Dubbo就被许多互联网公司所采用，并产生了许多衍生版本，如网易，京东，新浪，当当等等。由于阿里2014年10月Dubbo停止维护。随后部分互联网公司公开了自行维护的Dubbo版本，比较著名的如当当DubboX，新浪Motan等。在2017年9月，阿里宣布重启Dubbo项目。随后Dubbo开始了密集的更新。2018.2月，阿里将Dubbo捐献给Apache基金会。

     

    Spring Cloud 基于 Spring Boot，使用 HTTP协议 为微服务体系开发中的架构问题，提供了一整套的解决方案——服务注册与发现，服务消费，服务保护与熔断，网关，分布式调用追踪，分布式配置管理等。

• 请求统一通过 API 网关（Zuul）来访问内部服务。
• 网关接收到请求后，从注册中心（Eureka）获取可用服务。
• 由 Ribbon 进行均衡负载后，分发到后端具体实例。
• 微服务之间通过 Feign 进行通信处理业务。
• Hystrix 负责处理服务超时熔断。
• Turbine 监控服务间的调用和熔断相关指标。

 

 官网： https://spring.io/projects/spring-cloud 

因为Spring Cloud不同其他独立项目，它拥有很多子项目的大项目。所以它的版本是版本名+版本号 （如Finchley SR4）。

版本名：是伦敦的地铁名

版本号：SR（Service Releases）是固定的 稳定版本。后面会有一个递增的数字。

所以 Finchley.SR4就是Finchley的第4个Release版本

 

 从上面这个图也可以看出，Spring Cloud 的子组件版本 也不是很统一.

 

使用Spring脚手架快速搭建应用

先编写服务提供方代码

在我们的工程当中，New --> Module... --> Spring Initializr（SDK 1.8)-->填写坐标(如下图)-->选择要引入的依赖

(Web---Spring Web; SQL---JDBC API,MyBatis Framework,MySQL Driver ； 别忘记了选择SpringBoot版本)-->下一步 Finish

 

修改pom.xml，手动增加通用Mapper的坐标(通用Mapper是中国人自己写的，故需要自己手动引入)

<dependency>
    <groupId>tk.mybatis</groupId>
    <artifactId>mapper-spring-boot-starter</artifactId>
    <version>2.1.5</version>
</dependency>
另外我在pom.xml文件中又增加了几个编码和编译版本的属性值，默认只生成了java.version

首次引入这些包需要网络下载，故需要一些时间，请耐心等待.

 对配置文件修改 

我们不再用properties文件，把生成的配置文件重命名成yml文件，我们看看yml的写法。

 代码编写（实体类，拷贝的之前的Spring boot里面的）

通用Mapper使用

 

引导类增加注解

 BaseUserService

 BaseUserController

 

启动测试

 

 

再编写服务调用方代码

在我们的工程当中，New --> Module... --> Spring Initializr（SDK 1.8)-->填写坐标(如下图)-->选择要引入的依赖

(Web---Spring Web； 别忘记了选择SpringBoot版本)-->下一步 Finish

 

 

***若右侧显示出来了 Run Dashboard面板，一定要显示起来，如果万一关闭了，请参考 IDEA关于 Run Dashboard的手动打开方法。，它可以快速启动Spring Boot应用，不要自己去找引导类。

 pom.xml文件基本不用改动

配置文件我们暂时就改个端口

 

 引导类，加上 RestTemplate

Spring提供的一种简单便捷的模板类用于在java代码里访问restful服务。其功能与HttpClient类似但RestTemplate更优雅使用更便捷。

 实体类

  Controller 调用服务提供者程序的接口

 测试

 以上方式是在没有使用 Spring Cloud 的前提下，以前的分布式服务调用的方式

 

存在什么问题？

• 在consumer中，我们把url地址硬编码到了代码中，不方便后期维护

• consumer需要记忆provider的地址，如果出现变更，可能得不到通知，地址将失效

• consumer不清楚provider的状态，服务宕机也不知道

• provider只有1台服务，不具备高可用性

• 即便provider形成集群，consumer还需自己实现负载均衡

其实上面说的问题，概括一下就是分布式服务必然要面临的问题：

• 服务管理

  • 如何自动注册和发现

  • 如何实现状态监管

  • 如何实现动态路由

• 服务如何实现负载均衡

• 服务如何解决容灾问题

• 服务如何实现统一配置

以上的问题，我们都将在SpringCloud中得到答案。

 

黑马用“滴滴平台”这样的例子

Eureka就好比是滴滴，负责管理、记录服务提供者的信息。服务调用者无需自己寻找服务，而是把自己的需求告诉Eureka，然后Eureka会把符合你需求的服务告诉你。

同时，服务提供方与Eureka之间通过“心跳”机制进行监控，当某个服务提供方出现问题，Eureka自然会把它从服务列表中剔除。

这就实现了服务的自动注册、发现、状态监控

 

 

• Eureka：就是服务注册中心（可以是一个集群），对外暴露自己的地址

• 提供者：启动后向Eureka注册自己信息（地址，提供什么服务）

• 消费者：向Eureka订阅服务，Eureka会将对应服务的所有提供者地址列表发送给消费者，并且定期更新

• 心跳(续约)：提供者定期通过http方式向Eureka刷新自己的状态

 

 市面上有哪些提供服务治理(注册中心)的服务？ Eureka Consul Nacos Zookeeper

 

编写注册中心工程代码

在我们的工程当中，New --> Module... --> Spring Initializr（SDK 1.8)-->填写坐标(如下图)-->选择要引入的依赖

(Spring Cloud Discovery---Eureka Server； 别忘记了选择SpringBoot版本)-->下一步 Finish

 

 

 pom.xml ,Spring Cloud的版本统一管理引入，它使用了dependencyManagement

 

Netflix（耐飞）是一家在线影片租赁提供商，对比国内的优酷 。 美国上市公司

覆盖默认配置:

 

 引导类增加注解