Nacos

背景阐述 前几天，有位同学问我一个关于 Dubbo 的问题。他的诉求是这样子的： 诉求一 第一个诉求是本地开发的时候想自己调用自己的服务，比如自己在改 A 服务，然后出问题了，本地再启动一个 B 服务，A 服务调用 B 服务直接排查问题。 目前的问题是用的同一个注册中心，所以会调用到其他的服务实例。 还有就是去网上找了一些文章的资料，按照资料上的配置没有效果，也就是在@Reference 配置 url 来指定调用的服务地址。 配置如下： @Reference(url="dubbo://localhost:20880") 诉求二 目前他们的测试环境没有使用 Docker 来部署，而且每个服务只部署了一个实例。问题就是当一个项目并行开发时有多个分支，这些分支得合并后一起部署测试。经常会出现代码冲突等问题。 还有就是快要上线时，需要下掉其他的分支做回归测试。但是会出现其他团队也要同一天上线，就只能协商等待来解决。 最好的方式就是可以实现一个分支部署一个实例，对于他们目前的这个规模和投入这个暂时做不了。所以他向我请教，有没有什么更好更快的方式。 解决方案 既然找了我，我还是给出一些建议吧，不一定很好，仅供参考。 诉求一解决方案 @Reference 在@Reference 中指定 url 是可以的，只是那位同学配置的地址有问题，在地址后面应该加上接口和版本的信息。 @Reference

最近做了两个事情相比在项目里面写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()

前面学习了单机模式下的启动，今天尝试下集群部署。 生产环境中部署nacos肯定是使用集群模式cluster保证高可用。 官方文档的集群部署推荐使用VIP+域名模式，把所有服务列表放到一个vip下面，然后挂到一个域名下面。 三种部署方式 官方推荐，nacos集群一般有3种方式，三种部署方式在访问形式的区别如下， http://ip1 :port/openAPI 直连ip模式，机器挂则需要修改ip才可以使用 http://VIP :port/openAPI 挂载VIP模式，直连vip即可，下面挂server真实ip，可读性不好 http://nacos.com :port/openAPI 域名 + VIP模式，可读性好，而且换ip方便，推荐模式 官方建议至少3个或3个以上的节点来实现集群模式。 修改启动端口 程序启动默认占用的端口是8848，我们可以对端口进行修改，打开conf文件下的application.properties，修改启动端口。 现在演示使用单机伪集群模式，所以通过修改端口的方式来部署这3个实例，端口分别为：8848、8858、8868。 配置集群配置文件 在nacos的解压目录nacos/的conf目录下，配置文件cluster.conf，请每行配置成ip:port。（请配置3个或3个以上节点） # ip:port 58.18.17.155:8848 58.18.17

什么是分布式事务问题？ 单体应用 　　单体应用中，一个业务操作需要调用三个模块完成，此时数据的一致性由本地事务来保证。 微服务应用 　　随着业务需求的变化，单体应用被拆分成微服务应用，原来的三个模块被拆分成三个独立的应用，分别使用独立的数据源，业务操作需要调用三个服务来完成。此时每个服务内部的数据一致性由本地事务来保证，但是全局的数据一致性问题没法保证。 小结 　　在微服务架构中由于全局数据一致性没法保证产生的问题就是分布式事务问题。简单来说，一次业务操作需要操作多个数据源或需要进行远程调用，就会产生分布式事务问题。 Seata 是什么? 　　Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。 　　官网： http://seata.io/ Seata 组成 Transaction ID(XID) 　　全局唯一的事务id 三组件 　　Transaction Coordinator(TC)：事务协调器,维护全局事务的运行状态,负责协调并驱动全局事务的提交或回滚 　　Transaction Manager(TM)：控制全局事务的边界,负责开启一个全局事务,并最终发起全局提交或全局回滚的决议 　　Resource Manager(RM)

Spring Cloud Alibaba介绍 　　Spring Cloud Alibaba为分布式应用程序开发提供了一站式解决方案。它包含开发分布式应用程序所需的所有组件，使您可以轻松地使用Spring Cloud开发应用程序。 　　使用Spring Cloud Alibaba，您只需要添加一些注释和少量配置即可将Spring Cloud应用程序连接到Alibaba的分布式解决方案，并使用Alibaba中间件构建分布式应用程序系统。 　　官网： https://spring.io/projects/spring-cloud-alibaba 特征 流量控制和服务降级 ：使用Sentinel进行流量控制，断路和系统自适应保护。 服务注册和发现 ：实例可以在Nacos中注册，客户可以使用Spring管理的bean发现实例。 支持通过Spring Cloud Netflix的客户端负载均衡器Ribbon。 分布式配置 ：使用Nacos作为数据存储 事件驱动 ：构建与Spring Cloud Stream RocketMQ Binder连接的高度可扩展的事件驱动微服务 消息总线 ：使用Spring Cloud Bus RocketMQ链接分布式系统的节点 分布式事务 ：支持高性能且易于使用的Seata分布式事务解决方案 Dubbo RPC ：通过 Dubbo RPC 扩展Spring

Nacos是什么？ nacos 是微服务架构中的一种注册中心，与之相同的还有其他注册中心：Eureka（Apache产品） nacos属于阿里巴巴开源项目，具有比Eureka更好的功能性 Nacos的特点： 当消费方从nacos注册中心获取过一次生产方提供的服务后，下次就不需要nacos也能获取生产方的这个服务 但是没经过nacos获取过的服务是不能的 这点相比Eureka比较友好，Eureka需要每次获取服务都经过注册中心 目录 Nacos安装（Windows） Nacos账号修改 Nacos集群-Windows Nacos安装（Windows） 中文文档： http://dubbo.apache.org/zh-cn/docs/user/references/registry/nacos.html git下载： http://https://github.com/alibaba/nacos 解压安装，解压到合适的目录（路径不包含中文） 通过 /bin/目录下的 startup.cmd 启动即可 通过 shutdown.cmd 关闭或直接关闭运行窗口 初次使用： 成功启动nacos服务后，浏览器访问：localhost:8848/nacos（8848为默认端口） 当出现以下画面登录即可，初始的默认用户名：nacos，密码：nacos Nacos账号修改 默认的初始账户为 nacos

在微服务的分布式项目架构中，存在很多子模块、很多服务、也包括承载他们的很多服务器主机 如此，每个模块的配置文件都在模块中，将使得 系统整体配置难以维护，不方便运维操作！ 而且，我们作为开发人员，在实际工作中往往有专业的运维人员来管控这些配置文件 这是为了配置安全（并不是所有配置信息都能给开发人员知道的）、为了方便管理（集中交给运维统筹管理） 所以我们需要把配置文件都集中化管理，有以下好处： - 整体配置一目了然，方便更改、维护 - 可以区分环境的使用配置文件（比如一个配置文件常分为dev、prod、test） 目录 基于Nacos集中管理配置 配置感知 基于Nacos集中管理配置 参与配置文件集中管理的项目需要的依赖： 注意 以下的依赖选择二选一，因为不同的依赖采取的配置将会不同！（在这儿踩过坑请注意） 推荐使用alibaba的！本篇笔记只记录关于这个依赖的配置项！ <dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring

背景阐述 前几天，有位同学问我一个关于 Dubbo 的问题。他的诉求是这样子的： 诉求一 第一个诉求是本地开发的时候想自己调用自己的服务，比如自己在改 A 服务，然后出问题了，本地再启动一个 B 服务，A 服务调用 B 服务直接排查问题。 目前的问题是用的同一个注册中心，所以会调用到其他的服务实例。 还有就是去网上找了一些文章的资料，按照资料上的配置没有效果，也就是在@Reference 配置 url 来指定调用的服务地址。 配置如下： @Reference(url="dubbo://localhost:20880") 诉求二 目前他们的测试环境没有使用 Docker 来部署，而且每个服务只部署了一个实例。问题就是当一个项目并行开发时有多个分支，这些分支得合并后一起部署测试。经常会出现代码冲突等问题。 还有就是快要上线时，需要下掉其他的分支做回归测试。但是会出现其他团队也要同一天上线，就只能协商等待来解决。 最好的方式就是可以实现一个分支部署一个实例，对于他们目前的这个规模和投入这个暂时做不了。所以他向我请教，有没有什么更好更快的方式。 解决方案 既然找了我，我还是给出一些建议吧，不一定很好，仅供参考。 诉求一解决方案 br/>@Reference 在@Reference 中指定 url 是可以的，只是那位同学配置的地址有问题，在地址后面应该加上接口和版本的信息。

部门新来了个架构师，BAT背景，住在三环，开宝马上班，有车位。 小伙话不多，但一旦说话斩钉截铁，带着无法撼动的自信。原因就是，有他着数亿高并发经验，每一秒钟的请求，都是其他企业运行一年也无法企及的。这就让人非常羡慕，毕竟他靠这个比我赚的钱要多。 俗话说，要想在公司不出事故，那就不要写代码。干活多了容易出事，一身轻松无人问津，这就是现实。 但有时候还是要看成果的。新来的研发领导不懂技术，但他懂技术指标，所以就统计大家提交git的数量，如果git活动是一片绿色如A股，那就算过关了。 架构师思来想去，决定领一个 并发量最高的需求 ：统计接口的平均响应时间和启动以来的请求数。 为什么说它的并发量高呢？这是因为，它是统计所有接口的，自然比每一个接口的请求量都要大。AOP代码一包，每个接口都得从他这里走一圈。 该我们的架构师上场了。代码如图。 架构师说，我的代码不需要做注释。所谓的注释，都是给垃圾代码用的。我深以为是，他明显是受到了 Netflix 公司的影响。 程序考虑到了高并发场景，使用了线程安全的 ConcurrentHashMap ，然后每次通过监控key取出相应的数据，然后在value上递增。这么简单的代码，确实不需要增加什么注释。 作为项目里 并发量最高 的代码，出于对高级架构师的信任，我们并不需要做什么代码review，也不需要做什么测试。大家都很忙，代码您呐，到线上遛一遛吧。

之前学习了nacos注册中心,今天继续看看nacos的其他功能。 注册中心链接 https://www.imooc.com/article/305289 配置的发布与订阅 我们先来看看如何使用nacos提供的api来实现配置的发布与订阅 发布配置: public class ConfigPub { public static void main(String[] args) throws NacosException { final String dataId="test"; final String group="DEFAULT_GROUP"; ConfigService configService= NacosFactory.createConfigService("localhost:8848"); configService.publishConfig(dataId,group,"test config body"); } } 订阅配置: public static void main(String[] args) throws NacosException, InterruptedException { final String dataId="test"; final String group="DEFAULT_GROUP"; ConfigService