文章目录
你最好先了解微服务架构springcloud:https://blog.csdn.net/qq_52681418/article/details/113247805
此篇博客将被替换!!!!目前不完整!!!,将被合并到SpringCloud:https://blog.csdn.net/qq_52681418/article/details/113247805
微服务架构SpringCloud Alibaba
在 Netflix 体系不再继续提供新特性更新的大背景之下,Spring Cloud Alibaba 的出现,不 仅提供了更符合中国开发者使用习惯的组件,也为 Spring Cloud 生态的其他使用者提供 了更丰富的组件选择,承接了因 Netflix 体系不再更新导致的发展活力问题。相信在未来 Spring Cloud Alibaba 获得更多开发者的亲睐与应用,这也将成为 Java 开发者必不可少 的技能之一。
《Spring Cloud 微服务实战》:https://developer.aliyun.com/topic/download?id=940
同 Spring Cloud 一样,Spring Cloud Alibaba 也是一套微服务解决方案,包含开发分布式应用微服务的必需组件,方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。
使用IDEA来开始一个SpringCloud Alibaba项目:https://blog.csdn.net/qq_52681418/article/details/113547629
springcloud alibaba方案组件于springcloud相比显得更少,下面为了于springcloud 对比,所以列出同样的目录。
- Sentinel:把流量作为切入点,从流量控制、熔断降级、系统负载保护等多个维度保护 服务的稳定性。
- Nacos:一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。
- RocketMQ:一款开源的分布式消息系统,基于高可用分布式集群技术,提供低延时 的、高可靠的消息发布与订阅服务。
- Dubbo:Apache Dubbo 是一款高性能 Java RPC 框架。
- Seata:分布式事务
使用Spring Cloud Alibaba需要在父项目中引入依赖:
<dependencyManagement> <dependencies> <!--引入Alibaba实现的springcloud--> <dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-alibaba-dependencies</artifactId> <version>2.2.1.RELEASE</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement>
服务注册与发现是微服务架构体系中最关键的组件之一。如果尝试着用手动的方式来给每一个客户端来配置所有服务提供者的服务列表是一件非常困难的事,而且也不利于服务的动态扩缩容。Nacos Discovery 可以帮助您将服务自动注册到 Nacos 服务端并且能够动态感知和刷新某个服务实例的服务列表。除此之外,Nacos Discovery 也将服务实例自身的一些元数据信息-例如 host,port, 健康检查URL,主页等内容注册到 Nacos。Nacos 的获取和启动方式可以参考Nacos 官网。
Dubbo 服务调用
Apache Dubbo,Spring Cloud Alibaba 引入了 Dubbo Spring Cloud,扩展了分布式服务调用能力,不仅能使 Apache Dubbo 和 OpenFeign 共存,还允许 Spring Cloud 标准调用底层通过 Dubbo 支持的通讯协议传输。
- 使用 Dubbo Spring Cloud 实现 Spring Cloud 分布式服务调用
- 使用 Dubbo Spring Cloud 替换 Spring Cloud 分布式服务调用底层协议
- 理解 Dubbo Spring Cloud 高级特性:服务订阅、元数据、Actuator
使用注解 @DubboTransported 适配 Spring Cloud OpenFeign 和 @LoadBalanced RestTemplate,使其底层调用走Dubbo调用协议,而服务提供方则只需在原有@RestController类上追加 Dubbo@Servce注解(需要抽取接口)即可,
可通过 Apache Dubbo 注解@Service和@Reference暴露和引用 Dubbo 服务,实现服务间多种协议的通讯。
生产者、消费者引入Dubbo依赖:
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-dubbo</artifactId>
</dependency>
通过Openfeign可以知道,服务调用是在调用者内部创建一个接口,使用时调用该接口即可。
dubbo也是如此,创建一个接口,服务提供者实现接口,服务调用者使用接口。推荐将这个接口独立出来。提供者、调用者添加接口的maven依赖即可。
此时由3个角色:提供者、调用者、接口
1.创建接口模块,
无需依赖,创建服务调用接口类:
public interface MyService {
String echo(String message);
}
使用maven命令将接口模块部署到本地:
cd 项目名 && mvn clean install
此时,调用者、提供者均可引入此依赖。
2.服务调用者、服务提供者引用此接口依赖:
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>dubbo-sample-api</artifactId>
<version>0.0.1-SNAPSHOT</version>
</dependency>
服务调用者、服务提供者添加配置暴露Dubbo服务:
# dubbo 协议
dubbo:
protocol:
id: dubbo
name: dubbo
port: -1 # dubbo 协议端口( -1 表示自增端口,从 20880 开始)
# Dubbo 消费端订阅服务端的应用名,多个服务提供者用逗号分隔
cloud: # 这里订阅"自己",会被忽略掉,请根据实际情况添加
subscribed-services: dubbo-provider-sample
scan: # dubbo 服务扫描基准包,可以使用注解@DubboComponentScan 指定
base-packages: com.alibaba.cloud.dubboprovidersample
3.提供者实现接口
@Service //Dubbo 服务注解
public class SimpleEchoService implements MyService {
@Override
public String echo(String s) {
return "服务提供者实现了接口";
}
}
4.调用者修改订阅:
dubbo:
...
cloud:
subscribed-services: 要调用的服务名 #多个用, 号隔开
...
调用服务:
@RestController
public class DubboConsumerSampleController {
@Reference
private MyService myService;
// http://127.0.0.1:8080/echo?message=somemessage
@GetMapping("/echo")
public String echo(@RequestParam(name = "message", defaultValue = "no message") String message) {
return myService.echo(message);
}
}
可以发现,实现用@Service、调用用@Reference。
Sentinel 服务容错
参考:https://blog.csdn.net/qq_52681418/article/details/113351447
Seata 分布式事务
官网:https://seata.io/zh-cn/?spm=5176.12026607.tutorial.1.9c7732e2pjYXCa
分布式一致性是分布式系统亟需解决的关键问题之一,根据过去一年的调查问卷,在微服务的实践中分布式事务是用户遇到的最大痛点。目前市面缺少经过洪荒流量验证的分布式事务组件,Seata 在阿里经济体内部经过了漫长的孵化,承载了双11洪荒流量,实践证明 Seata 是一款解决分布式数据一致性的的优秀组件。Seata 于 2019 年正式对外开源,开源后就受到了大家的热情追捧,一度蝉联 GitHub 活跃排名榜首。
什么是事务?
事务指在计算机应用中一套完整操作,这套操作要么全部执行完,要么一点也不执行。
特性如下:
- 一致性:执行前后的状态一致。
- 隔离性:多个事务直接不能干扰。
- 原子性:要么成功提交,要么失败回滚。
- 持续性:提交后不能撤回。
执行
分布式事务往往产生在分布式系统中(单体应用也存在),假设一个事务请求调用某个大服务,由多个小服务来相互调用共同实现这个大服务,