Nacos

JeecgCloud部署 环境说明 JDK: 1.8 Maven: 3.5+ MySql: 5.7+ Redis: 3.2 + Node Js: 10.0 + Npm: 5.6.0+ Yarn: 1.21.1+ IDE插件 Lombok Plugin （必装） # 一、项目下载 git clone https://github.com/zhangdaiscott/jeecg-cloud.git # 二、配置本地hosts 建议使用 switchhost，进行本地host设置 软件下载 # 本地测试环境 127.0.0.1 jeecg-cloud-redis 127.0.0.1 jeecg-cloud-mysql 127.0.0.1 jeecg-cloud-nacos # 三、初始化数据库 脚本说明 jeecg-cloud/doc/db/jeecgcloud_mysql5.7.sql | 初始化库脚步 # 四、启动Nacos nacos 的环境搭建，参考 官方文档 启动 nacos , 访问： http://127.0.0.1:8848/nacos (默认账号密码 nacos/nacos) 参考截图创建两个属性文件 配置列表 ，注意类型选择YAML jeecg-cloud/doc/NACOSCONFIG/application-jeecg-cloud.yml jeecg-cloud

前言 在高速发展的时候，公司规模越来越大，老师人数越来越多，这时候公司不能铺太多人去做运营与服务，必须提高每个人效，这就需要技术驱动。因此掌门教育转变成一家技术驱动型的公司，如果被迫成为一家靠资金驱动的公司就活不下去了。 -- 张翼（掌门教育创始人兼CEO） 掌门教育自2014年正式转型在线教育以来，秉承“让教育共享智能，让学习高效快乐”的宗旨和愿景，经历云计算、大数据、人工智能、 AR / VR / MR 以及现今最火的 5G ，一直坚持用科技赋能教育。掌门教育的业务近几年得到了快速发展，特别是今年的疫情，使在线教育成为了新的风口，也给掌门教育新的机遇。 随着业务规模进一步扩大，流量进一步暴增，微服务数目进一步增长，使老的微服务体系所采用的注册中心 Eureka 不堪重负，同时 Spring Cloud 体系已经演进到第二代，第一代的 Eureka 注册中心已经不大适合现在的业务逻辑和规模，同时它目前被 Spring Cloud 官方置于维护模式，将不再向前发展。如何选择一个更为优秀和适用的注册中心，这个课题就摆在了掌门人的面前。经过对 Alibaba Nacos 、 HashiCorp Consul 等开源注册中心做了深入的调研和比较，最终选定 Alibaba Nacos 做微服务体系 Solar 中的新注册中心。 背景故事 基础架构部选择新的注册中心

配置中心预研 概述 随着程序功能的日益复杂，程序的配置日益增多：各种功能的开关、参数的配置、服务器的地址…… 对程序配置的期望值也越来越高：配置修改后实时生效，分环境、分集群管理配置，代码安全、审核机制…… 在这样的大环境下，传统的通过配置文件、数据库等方式已经越来越无法满足开发人员对配置管理的需求。 所以，配置中心应运而生。 选型思路 1、询问几个道友（多询问几个不同的群的道友，防止人云亦云） 2、百度大范围搜大致的看 选中几个使用广、文档多的 3、github对比issues、pull requests、insights、commits、branches、tags 4、语言对比、性能对比(通过CNCF对比) 询问道友 大致得出的可选组件为：apollo nacos eureka zk consul 百度大范围搜索 名词解释 CAP理论： CAP理论是分布式架构中重要理论 一致性(Consistency) (所有节点在同一时间具有相同的数据) 可用性(Availability) (保证每个请求不管成功或者失败都有响应) 分隔容忍(Partition tolerance) (系统中任意信息的丢失或失败不会影响系统的继续运作) CAP 不可能都取，只能取其中2个 原因是 如果C是第一需求的话，那么会影响A的性能，因为要数据同步，不然请求结果会有差异，但是数据同步会消耗时间

Springboot使用Nacos做配置中心 环境 项目配置 高级使用 配置dev,prod,test环境 微服务之间互相隔离配置 每个微服务创建自己的命名空间，使用配置分组区分环境，dev，test，prod 环境 jdk: 1.8 maven: 3.6.3 Idea 项目配置 新建一个Springboot项目，用Idea自动创建就可以，下面开始使用。 引入SpringcloudAlibaba依赖 < dependencyManagement > < dependencies > < dependency > < groupId > com . alibaba . cloud < / groupId > < artifactId > spring - cloud - alibaba - dependencies < / artifactId > < version > 2.2 .0 . RELEASE < / version > < type > pom < / type > < scope > import < / scope > < / dependency > < / dependencies > < / dependencyManagement > 然后再引入config依赖 < dependency > < groupId > com . alibaba . cloud

最近做了两个事情相比在项目里面写CRUD有意思些，就是看一些优秀框架的源代吗，然后发现问题并修改提交PR。因为SpringCloud组件Eureka的闭源，所有我们项目有必要看看其他相关的优秀开源的项目,刚好Alibaba Nacos这个开源项目现在比较火热，所以我也花时间简单的看了看他们的框架，有意思的是我在看源码的过程也发现了一些问题，加上我本人有代码洁癖，所以把我最不能忍的一个问题拎出来给修改了，并提交的PR给到Alibaba Nacos团队review，最后Alibaba Nacos 团队采用的我的修改建议并合并了代码。中间还有个小插曲，因为不知道给开源项目贡献代码需要签订CLA，而有过几次沟通。然而比较碰巧的是，我在查看公司内部中间件团队的代码时也发现的类似的可能会造成性能问题的代码，这也是促成我这今天随笔的原因。 先说下我争对公司中间件团队的项目代码修改经历，因为不太方便放项目的代码，所以只能简单描述下，修改了什么 伪代码大概如下： xxxx()..stream().forEach(e -> { addApi(e.getxxx())}); addApi(Api api) { versionMap.put(api.getVersionNumber(), new ArrayList<> (Arrays.asList(api))); } 主要修改的的是把 addApi()

背景 当我们使用 spring boot 在多环境打包，配置属性在不同环境的值不同，如下： spring: profiles: active: @project.profile@ #根据maven 动态配置profile --- spring: profiles: dev demo: lengleng_dev --- spring: profiles: prd demo: lengleng_prd 或者使用 spring cloud 配置中心 （nacos/config）等 再有就是 应用配置的同一个属性，值的来源可能来自 配置文件、环境变量、启动参数 等等。 很多情况由于 如上配置的复杂性，应用在读取配置的时候，并不是我们预期的值 ，比如我们想使用是配置文件 dev 环境的值，却被环境变量的 或者其他的数据覆盖等，这些往往只有等我们运行时，输出日志才能发现错误原因。 解决方案 spring boot 2.3 Actuator 提供 /actuator/configprops 端点 （之前版本也有此端点，但是行为发生变化了 /actuator/env 保持一致 ），提供对配置文件属性跟踪功能， 方便我们在 spring boot 应用中，实时的获取配置文件实际加载值 。 如何使用 引入 actuator 依赖 <dependency> <groupId>org

pom配置： <!-- nacos配置中心 --> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId> </dependency> <!--Spring Cloud Alibaba--> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId> </dependency> yml配置： server: port: 8021 spring: application: name: product-server cloud: nacos: discovery: server-addr: 127.0.0.1:8848/ config: server-addr: localhost:8848 #配置中心地址 file-extension: yaml #指定yaml格式的配置 group: CLOUD-TEST profiles: active: dev 其中 nacos配置规则如下： ${prefix}

一、sentinel的持久化配置 上一章中我们通过Dashboard来为Sentinel客户端设置各种各样的规则，但是这些规则默认是存放在内存中，极不稳定，无法用于生成环境，所以需要将其持久化。 DataSource 扩展常见的实现方式有: 拉模式 ：客户端主动向某个规则管理中心定期轮询拉取规则，这个规则中心可以是 RDBMS、文件，甚至是 VCS 等。这样做的方式是简单，缺点是无法及时获取变更； 推模式 ：规则中心统一推送，客户端通过注册监听器的方式时刻监听变化，比如使用 Nacos 、Zookeeper 等配置中心。这种方式有更好的实时性和一致性保证。 Sentinel 目前支持以下数据源扩展： Pull-based: 文件、 Consul Push-based: ZooKeeper , Redis , Nacos , Apollo , etcd 生产环境中一般常用的就是 推模式 。这里我们使用Nacos存储规则。推送模式的正确做法应该是 配置中心控制台/Sentinel 控制台 → 配置中心 → Sentinel 数据源 → Sentinel 。 1.1 sentinel同步nacos配置 增加sentinel的依赖和nacos存储扩展依赖 <dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring

记录下搭建nacos集群过程中遇到的坑：（集群机子代号这里列为：nacos-a，nacos-b，nacos-c） 1. 集群搭建，需要建立数据库 nacos_config（该数据库在nacos官网集群安装有提到，sql文件已经放到github了）。当 创建nacos_config数据库的 nacos-a 启动正常， nacos-b 和 nacos-c 启动失败 。 可能是 nacos-b 和 nacos-c 无法远程连接 nacos-a 的数据库，导致启动失败。这时候需要开启 nacos-b 和 nacos-c 访问 nacos-a 的权限即可。 ========​​​​​​​========​​​​​​​========​​​​​​​========>>>>>>>> 2. 启动nacos集群（通过集群命令启动的 sh startup.sh），start.out日志文件提示启动成功，访问三台nacos也成功，服务也能注册上去，配置文件也能共享，但是查看 "集群管理 - 节点列表"，却发现没有显示集群的三台机器的信息。 可以断定，集群是没跑起来。只是单纯的单机运行。配置文件之所以能共享，是因为公用了同一个数据库。后来去查看了下 nacos.log 日志。发现启动之后一直报一个错误： unable to find local peer: 122.123.68.456:8848, all

pom配置 <dependencies> <!--gateway--> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-gateway</artifactId> </dependency> <!--Spring Cloud Alibaba--> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-hystrix</artifactId> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> <dependency>