Nacos

0. 前言 这是一个新的系列，来源于工作中的一个需求，领导准备新开一个项目线路，要求使用Java，项目符合现有主流技术，并要求对并发量有一定的承受能力 ，支持扩展。我和公司的几个小伙伴一起沟通了一下，这不就是标准的Spring Cloud微服务的系统架构吗。 之前读过小高之前发的文章的小伙伴也清楚我是C#开发，不过想当年我也系统学过Java，多年下来虽然手生，但也好歹没有落下技术。于是就揽下了这个活。毕竟学习是终身的。 不怎么简明的介绍了这个系列成立的原因，让我们言归正传，这个系列是我在搭建该项目过程的一个总结，如果后续开发中对框架有调整，也会在这个系列发布后续的更新。这也是为什么叫实战系列，而不是实战教程的原因。 那么，有兴趣的小伙伴，跟我一起来吧～ 1. 项目结构 项目采用maven作为软件包管理工具，Spring boot+Spring Cloud作为项目基础架构，设有配置中心、服务发现中心、网关中心和链路追踪中心以及服务集群，其中服务集群之间添加链路熔断和负载均衡机制。 当然，目前参照了几个系统都按照这种逻辑搭建的框架，所以我们大致上也参考了这个模型。具体如下图： 2. 主要技术组件使用 这里大概介绍一下，我在实践中选用的技术组件，选用这些技术没多少原因，很大程度上考虑到团队喜好以及后续维护的方便，还有就是官方团队的维护上考虑。 2.1 Maven Maven 翻译为"专家

本文源码： GitHub·点这里 || GitEE·点这里 一、注册中心简介 1、基础概念 在分布式架构的系统中注册中心这个概念就已经被提出了，最经典的就是Zookeeper中间件。 微服务架构中，注册中心是最核心的基础服务之一，注册中心可以看做是微服务架构中的通信中心，当一个服务去请求另一个服务时，通过注册中心可以获取该服务的状态，地址等核心信息。 服务注册主要关系到三大角色：服务提供者、服务消费者、注册中心。 2、流程和原理 基础流程 服务启动时，将自身的网络地址等信息注册到注册中心，注册中心记录服务注册数据。 服务消费者从注册中心获取服务提供者的地址，并通过地址和基于特定的方式调用服务提供者的接口。 各个服务与注册中心使用一定机制通信。如果注册中心与服务长时间无法通信，就会注销该实例，这也称为服务下线，当服务重新连接之后，会基于一定的策略在线上线。 服务地址相关信息发生变化时，会重新注册到注册中心。这样，服务消费者就无需手工维护提供者的相关配置。 核心功能 通过上面的基本流程，不难发现一个注册中心需要具备哪些核心功能： 服务发现 服务发现是指服务在启动后，注册到注册中心，服务方提供自身的元数据，比如IP地址、端口、运行状况指标的Uri 、主页地址等信息。 服务记录 记录注册中心的服务的信息，例如服务名称、IP地址、端口等。服务消费方基于查询获取可用的服务实例列表。

Sentinel ：把流量作为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。 Nacos ：一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。 RocketMQ ：一款开源的分布式消息系统，基于高可用分布式集群技术，提供低延时的、高可靠的消息发布与订阅服务。 Dubbo ：Apache Dubbo™ 是一款高性能 Java RPC 框架。 Seata ：阿里巴巴开源产品，一个易于使用的高性能微服务分布式事务解决方案。 Alibaba Cloud ACM ：一款在分布式架构环境中对应用配置进行集中管理和推送的应用配置中心产品。 Alibaba Cloud OSS : 阿里云对象存储服务（Object Storage Service，简称 OSS），是阿里云提供的海量、安全、低成本、高可靠的云存储服务。您可以在任何应用、任何时间、任何地点存储和访问任意类型的数据。 Alibaba Cloud SchedulerX : 阿里中间件团队开发的一款分布式任务调度产品，提供秒级、精准、高可靠、高可用的定时（基于 Cron 表达式）任务调度服务。 Alibaba Cloud SMS : 覆盖全球的短信服务，友好、高效、智能的互联化通讯能力，帮助企业迅速搭建客户触达通道。 来源： oschina 链接： https://my.oschina.net/u

背景 当我们使用 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

发布会传送门 点击了解产品详情 众所周知，注册中心和配置中心是Spring Cloud 和Dubbo 等微服务架构中的重要组件，往往采用 ZooKeeper/Nacos/Eureka/Apollo 等开源方案自建，但因其依赖复杂、变更频繁，往往给客户带来的较高的建设和运维成本，同时，在 Hbase、Spark或Kafka 等大数据的环境下，会依赖 ZooKeeper 进行分布式系统的协调，此时，基于云上的托管服务，可以极大的降低运维复杂度，并提高应用可用性。相比开源自建，微服务引擎MSE 通过提供的云上监控和运维能力、多机房和多区域容灾能力、自动宕机恢复能力，实现了99.9%的可用性保障，此外，MSE提供了多打25项的开源优化，提升了注册和配置中心的易用性和性能。3分钟便能完成接入，每月最低50.16元，更是从操作和价格上降低了企业的接入成本。 据微服务引擎MSE产品经理子墚介绍，“我们除了提供注册和配置中心的托管能力，还围绕困扰开发者微服务治理过程遇到的各类运维难题，提供了包括金丝雀发布、离群实例摘除、服务鉴权、无损下线、限流降级和全链路流控的高阶微服务治理能力，极大的降低了微服务的运维难度，其组件型的产品理念还帮助客户实现了云上应用的自主可控。“目前，已有包括陆德科技、吉递换电、趣练习、企迈云商等来自出行、物联网、在线教育、新零售等行业的客户正通过 MSE 来提升运维效率

一、Nacos 介绍 Nacos 是 Alibaba 公司推出的开源工具，用于实现分布式系统的服务发现与配置管理。英文全称 Dynamic Naming and Configuration Service，Na 为 Naming/NameServer 即注册中心，co 为 Configuration 即配置中心，Service 是指该注册/配置中心都是以服务为核心。服务（Service）是 Nacos 世界的一等公民。 ❝ 官网是这样说的：一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。 ❞ Nacos 致力于发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，可以快速实现动态服务发现、服务配置、服务元数据及流量管理。 Nacos 可以更敏捷和容易地构建、交付和管理微服务平台。 Nacos 是构建以“服务”为中心的现代应用架构的服务基础设施。 使用 Nacos 简化服务发现、配置管理、服务治理及管理的解决方案，让微服务的发现、管理、共享、组合更加容易。 Nacos 官网：https://nacos.io/zh-cn/ Github：https://github.com/alibaba/nacos 二、Nacos 安装 1、环境准备 Nacos 依赖 Java 环境来运行。如果您是从代码开始构建并运行 Nacos，还需要为此配置 Maven 环境

springboot 版本 2.0.8.RELEASE <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-dependencies</artifactId> <version>2.0.8.RELEASE</version> <type>pom</type> <scope>import</scope> </dependency> 参考文章： https://nacos.io/zh-cn/docs/quick-start-spring-cloud.html 是使用Nacos Spring Cloud方式配置的，为什么是不使用springboot ,因为springboot加代码，自己手动注册。 服务端用的是1.1.4，因为1.2.0要用户认证 1、配置 1.1添加依赖包 <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId> <version>0.2.1.RELEASE</version> </dependency> 1.2添加文件bootstrap.properties，内容

consul、eureka、nacos对比 配置中心 eureka 不支持 consul 支持 但用起来偏麻烦，不太符合springBoot框架的命名风格，支持动态刷新 nacos 支持 用起来简单，符合springBoot的命名风格，支持动态刷新 注册中心 eureka 依赖：依赖ZooKeeper 应用内/外：直接集成到应用中，依赖于应用自身完成服务的注册与发现， ACP原则：遵循AP（可用性+分离容忍）原则，有较强的可用性，服务注册快，但牺牲了一定的一致性。 版本迭代：目前已经不进行升级 集成支持：只支持SpringCloud集成 访问协议：HTTP 雪崩保护：支持雪崩保护 界面：英文界面，不符合国人习惯 上手：容易 consul 依赖：不依赖其他组件 应用内/外：属于外部应用，侵入性小 ACP原则：遵循CP原则（一致性+分离容忍） 服务注册稍慢，由于其一致性导致了在Leader挂掉时重新选举期间真个consul不可用。 版本迭代：目前仍然进行版本迭代 集成支持：支持SpringCloud K8S集成 访问协议：HTTP/DNS 雪崩保护：不支持雪崩保护 界面：英文界面，不符合国人习惯 上手：复杂一点 nacos 依赖：不依赖其他组件 应用内/外：属于外部应用，侵入性小 ACP原则：通知遵循CP原则（一致性+分离容忍） 和AP原则（可用性+分离容忍） 版本迭代

曹工杂谈：分布式事务解决方案之基于本地消息表实现最终一致性 前言 为什么写这个？其实我这边的业务场景，严格来说，不算是典型的分布式事务，需求是这样说的：因为我这边负责的一个服务消费者consumer，是用户登录的入口；正常情况下，登录时候要走用户中心，这是个单独的服务；如果用户中心挂了，我这边自然是没法登录的。 现在的需求就是说，假设用户中心挂了，也要可以正常登录。因为我这个consumer其实也是缓存了用户的数据的，在本地登录也可以的，如果在我本地登录的话，我就得后续等用户中心恢复后，再把相关状态同步过去。 基于这样一个需求，我这边的实现方案是： 1.配置文件里维护一个开关，表示是否开启：故障转移模式。暂不考虑动态修改开关（如果要做，简单做就提供个接口来改；复杂做，就放到配置中心里，我们现在用的nacos，可以改了后推送到服务端） 2.如果开关是打开的，表示需要进行故障转移，则登录、退出登录等各种需要访问用户中心的请求，都存储到数据库中；数据库会有一张表，用来存放这类请求。大致如下： CREATE TABLE `cached_http_req_to_resend` ( `http_req_id` bigint(20) NOT NULL COMMENT '主键', `req_type` tinyint(4) NOT NULL COMMENT '请求类型，1

一、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