springcloud实现增删改查操作 技术栈采用eureka+ribbon+feign+hystrix+mybatis+springmvc实现

springcloud的发展史

什么是微服务

微服务的概念源于 2014 年 3 月 Martin Fowler 所写的一篇文章“Microservices”。文中内容提到：微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。

每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。

另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。

微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。

微服务架构优势

01
复杂度可控

在将应用分解的同时，规避了原本复杂度无止境的积累。每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界。
由于体积小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率。

02
独立部署

由于微服务具备独立的运行进程，所以每个微服务也可以独立部署。当某个微服务发生变更时无需编译、部署整个应用。
由微服务组成的应用相当于具备一系列可并行的发布流程，使得发布更加高效，同时降低对生产环境所造成的风险，最终缩短应用交付周期。

03
技术选型灵活

微服务架构下，技术选型是去中心化的。每个团队可以根据自身服务的需求和行业发展的现状，自由选择最适合的技术栈。
由于每个微服务相对简单，所以需要对技术栈进行升级时所面临的风险就较低，甚至完全重构一个微服务也是可行的。

04
容错

当某一组件发生故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，形成应用全局性的不可用。
在微服务架构下，故障会被隔离在单个服务中。若设计良好，其他服务可通过重试、平稳退化等机制实现应用层面的容错。

05
扩展

单块架构应用也可以实现横向扩展，就是将整个应用完整的复制到不同的节点。当应用的不同组件在扩展需求上存在差异时，微服务架构便体现出其灵活性，因为每个服务可以根据实际需求独立进行扩展。

Spring Cloud 的基本组件

config 分布式/版本化配置。

eureka 服务注册和发现。

zuul 路由。

ribbon 服务和服务之间的调用。

feign 负载均衡。

Hystric 断路器。

创建服务注册中心

创建eureka客户端

本人为了方便,改用注解写的sql
@restController这个注解是@Controller+@ResponseBody注解的结合 在这个类中不需要在每个方法上声明@ResponseBody
如果是微服务项目,接受参数一定要加上注解@RequestParam或者@RequestBody这样才能接到参数

创建eureka2客户端

端口号改为8003 其余代码把第一个客户端的复制过来就可以

创建rabbion+Hystrix客户端实现服务间调用+负载均衡+服务熔断

studentinfo对象把客户端1的复制过来就可以使用

controller不在做详细描述 只需要注意参数前一定要加注解
调用http://localhost:8004/student/hi?name=test会看到页面交替显示

负载均衡就起到了作用 如果关闭8002和8003页面会出现

这样服务熔断的效果就达到了

创建feign客户端实现服务间调用+负载均衡+服务熔断

因为feign对ribbon做了一些封装,就不需要使用restTimplate对象来调用服务了,同时实现了负载均衡和服务熔断

实体类复制过来就可以使用了
@FeignClient是负载均衡客户端 参数value是声明要调用的服务,fallback是熔断之后返回的对象
实现的效果和上面的效果一样的 只不过使用两种不同的方式

结语

首先说声抱歉,因为代码量太多而导致我不能给你们复制源码.以后我会尽心尽力,希望大家可以开心,如果有哪些部分看不清楚或者看不明白的可以随时联系我,我一定会知无不言言无不尽。谢谢大家,喜欢java的朋友可以+我企鹅号1762683256 备注一下csdn 再次感谢大家能观看我的文章