Nacos

为什么需要使用网关 1.实现统一认证 2.统一一个域名，解决调用困难。 3.协议转换 将不友好的协议转成友好的协议。 spring cloud gateway 是什么 是spring cloud 的第二代网关，会替代zuul 第一代网关。 基于 netty,reactor,webflux 构建。 优点： 1.性能强劲 是 zuul 的1.6倍 2.功能强大 内置 监控，限流，转发等 3.设计优雅，容易扩展。 编写spring cloud gateway 增加依赖 < dependency > < groupId > org.springframework.cloud </ groupId > < artifactId > spring-cloud-starter-gateway </ artifactId > </ dependency > < dependency > < groupId > org.springframework.cloud </ groupId > < artifactId > spring-cloud-starter-alibaba-nacos-discovery </ artifactId > </ dependency > < dependency > < groupId > org.springframework.boot </ groupId > <

github 地址 https://github.com/seata/seata 本文使用的是 2020-04-21 日 四天前刚发版的最新版本 1.2.0 io.seata.server.Server 类启动 seata-server 需要在工程目录下执行 mvn clean install -DskipTests=true ，这样就会 根据 resources里面的proto文件生成代码，我这边用的maven 版本 是 apache-maven-3.1.0，执行的时候会报错 D:\workspace\idea\seata\serializer\seata-serializer-protobuf>mvn clean install -DskipTests=true [INFO] Scanning for projects... [WARNING] [WARNING] Some problems were encountered while building the effective model for io.seata:seata-serializer-protobuf:jar:1.2.0 [WARNING] 'version' contains an expression but should be a constant. @ io.seata:seata-parent:$

前言 上篇文章中，简单介绍了 如何在SpringCloud项目中接入Nacos作为注册中心 ，其中服务消费者是通过RestTemplate+Ribbon的方式来进行服务调用的。 实际上在日常项目中服务间调用大都用的是 OpenFeign , OpenFeign自身整合了Ribbon和Hystrix，为服务调用提供了更优雅的方式 那么接入了Nacos之后，服务调用还能用这一套吗？ 通过我在公司项目上的试水，这个大胆的设想是完全没问题的 本文在上一篇文章中的项目工程基础上 ，进行测试和演示，文章地址： 在SpringCloud项目中接入Nacos作为注册中心 <!-- more --> 创建项目 打开之前创建的工程Nacos，目前已经有两个子工程： nacos-provide：服务提供者 nacos-consumer：服务消费者（RestTemplate+Ribbon服务调用） 同样的操作，在Nacos项目下继续创建一个Springboot项目名为nacos-feign，创建时添加OpenFeign的依赖，如图： nacos-fegin的pom.xml文件如下： <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www

Spring Cloud Alibaba | Sentinel：分布式系统的流量防卫兵动态限流规则 前面几篇文章较为详细的介绍了Sentinel的使用姿势，还没看过的小伙伴可以访问以下链接查看： 《Spring Cloud Alibaba | Sentinel：分布式系统的流量防卫兵基础实战》 《Spring Cloud Alibaba | Sentinel：分布式系统的流量防卫兵进阶实战》 但是依然无法满足我们日常的生产需要，其中，非常重要的一点就是限流规则的配置是存在当前应用的内存中的，每次我们重启应用以后，我们在Sentinel控制台中配置的规则就丢失了，下面，我们就介绍一下Sentinel规则持久化的方式。 Sentinel为我们提供了两种方式对规则进行修改： 通过 API 直接修改 (loadRules) 通过 DataSource 适配不同数据源修改 loadRules() 方法只接受内存态的规则对象，但更多时候规则存储在文件、数据库或者配置中心当中。DataSource 接口给我们提供了对接任意配置源的能力。相比直接通过 API 修改规则，实现 DataSource 接口是更加可靠的做法。 DataSource 扩展常见的实现方式有: 拉模式：客户端主动向某个规则管理中心定期轮询拉取规则，这个规则中心可以是 RDBMS、文件，甚至是 VCS 等。这样做的方式是简单

系统介绍 spring-cloud-plus 是以spring-cloud-alibaba为基础并整合一些常用框架的分布式基础开发平台。 项目以组件模块的方式构建，实现项目模块可插拔组装。工作中遇到的一些常用框架，我都会整合到此项目，并持续更新。 项目地址 https://gitee.com/gourd-hu/spring-cloud-plus https://github.com/hxnlyw/spring-cloud-plus 目标 成为一个简单易用、快速高效、功能丰富、安全稳定的分布式项目脚手架。 让每个人都可以独立、快速、高效地开发一套分布式项目！ 技术架构图 技术栈 基础：springboot + springcloud 持久化：MybatisPlus 连接池：Druid 数据库：Mysql 项目构建：Maven API网关： Gateway 日志：Logback 注册、配置中心： Nacos 服务调用： Feign + Ribbon 熔断、降级：Sentinel 分布式事务：Seata 分布式锁：Redisson 鉴权： Shiro + jwt-token 缓存： Redis、springCache 工作流：Activiti 定时任务： Quartz 消息中间件：ActiveMq 文件操作：FastDFS、EasyExcel 搜索存储引擎：Elasticsearch

0、前言 　　gateway是spring的二代网关， 作为Netflix Zuul的替代者，是异步非阻塞网关 ，ZUUL2也是异步非阻塞的，但未纳入spring cloud整合计划 　　基于WebFlux ，与 spring-boot-starter-web冲突，要排除该依赖；ZUUL1是阻塞io的API Gateway，使用简单方便； 　　性能上，自然是异步非阻塞的gateway胜出； 　　如何取舍，见仁见智了，不要盲目认为gateway比ZUUL1好，适合项目才是最好的； 　　实际项目中建议选择gateway； 1、集成gateway 1-1、添加依赖 　　新建gateway模块，添加依赖，注意要排除spring-boot-starter-web依赖，不能添加该依赖 <!-- 集成nacos --> <dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId> <version>2.0.1.RELEASE</version> </dependency> <!-- 集成gateway --> <dependency> <groupId>org.springframework.cloud</groupId

前言 使用 API 网关作为内部服务面向客户端的单一入口，是一种普遍采用的架构模式。企业组织通过良好定义的 API 将内部系统向内部和外部用户公开，通常都会采用 API 网关来处理横向的关注点，包括访问控制、速率限制、负载均衡等等，来实现安全可控的 API 开放。而被广泛实践的微服务架构在提供高度灵活性和弹性的同时，也给 API 网关带来了更多的挑战。 阿里云云服务总线（Cloud Service Bus）新推出微服务网关服务（CSB Micro Gateway），针对微服务架构下 API 开放的特点，提供能与微服务环境的治理策略无缝衔接的网关服务，实现高效的微服务 API 开放。 API 网关的作用 API 网关典型作用 相信许多人都熟悉 API 网关的概念。作为内部服务面向客户端的单一入口，API 网关有两个最典型的作用： 1、内外解耦：对客户端屏蔽内部服务的动态多样化实现细节，如技术框架、拆分粒度、接口结构、实例状态等 2、切面控制：让内部服务能专注在业务逻辑上，集中处理横向的关注点，如路由、安全、限流、日志、监控等 API 网关使用类型 实际使用中，对应 API 网关所在位置和针对场景的不同，可分成两种类型： 1、企业级网关：位于企业组织的外围，面对外部的 API 消费者或服务提供者。通常将企业自身的数据和能力 API 化，对外开放，也有允许外部服务入驻的情况。总的来说

前言 前面的系列文章已经介绍了Nacos的如何接入SpringCloud，以及Nacos的基本使用方式 之前的文章中都是基于 单机模式 部署进行讲解的，本文对Nacos的 集群 部署方式进行说明 环境准备 JDK8 Centos7.5(ip: 10.1.8.27 ) MySQL 5.6.5+ Nacos-server：1.0.1 请提前下载Nacos-server：1.0.1压缩包并解压至相应目录 本次的Nacos-server在linux服务器上进行启动。 集群模式部署 Nacos文档中提供了三种集群部署方案 http://ip1:port/openAPI 直连ip模式： ip+端口进行部署，客户端直接连接Nacos的ip http://Vip:port/openAPI 挂载虚拟IP模式： 配合KeepAlive，Nacos真实ip都挂载虚拟Ip下 客户端访问Vip发起请求 当主Nacos宕机后，备用Nacos接管，实现高可用， http://www.nacostest.com:port/openAPI 挂载虚拟IP+域名模式： 为虚拟ip绑定一个域名，当Nacos集群迁移时，客户端配置无需修改。 这三种方案都是为了尽可能实现高可用，后两种方案除了基本的部署流程外更多侧重于实现高可用的工作上 本文以第一种ip+端口的方式为大家介绍集群部署方式 当然 ip+端口 也有多种部署方式

Alibaba Nacos 学习（一）：Nacos介绍与安装 Alibaba Nacos 学习（二）：Spring Cloud Nacos Config Alibaba Nacos 学习（三）：Spring Cloud Nacos Discovery - FeignClient,Nacos 服务注册与发现 Alibaba Nacos 学习（四）：Nacos Docker Alibaba Nacos 学习（五）：K8S Nacos搭建,使用nfs 准备环境 Centos7 192.168.50.21 k8s-master 2G Centos7 192.168.50.22 k8s-node01 2G Centos7 192.168.50.23 k8s-node02 2G K8S集群搭建参考 https://www.cnblogs.com/woxpp/p/11875547.html master安装好Git ,yum install git master,node01,node02 安装 nfs-utils yum install nfs-utils master,node01,node02添加nfs exports配置，为了解决后续的nfs报错异常 /data/mysql-slave *(insecure,fsid= 0 ,rw, async ,no_root_squash)

配置 Nginx 可以把.conf 文件拉到本地，配置好再传上去 #gzip on; upstream cluster{ server 192.168.0.113:8848; server 192.168.0.110:8848; server 192.168.0.109:8848; } server { listen 8848; server_name localhost; #charset koi8-r; #access_log logs/host.access.log main; location / { #root html; #index index.html index.htm; proxy_pass http://cluster; } 改动如下 [root@localhost sbin] # pwd /usr/local/nginx/ sbin [root @localhost sbin] # ./nginx -c /usr/local/nginx/conf/nginx.conf 网页可以正常访问，再添加一个配置信息，验证一下，能否成功保存到数据库 来源： oschina 链接： https://my.oschina.net/u/4259850/blog/3275839