公司做的网站如何开启伪静态,wordpress导航不固定,wordpress 入侵视频,视频生成网址链接作为 Nacos 5W1H 的系列文章#xff0c;本文将围绕“Where”#xff0c;讲述 Nacos 配置管理的三个典型的应用场景#xff1a;
数据库连接信息限流阈值和降级开关流量的动态调度上一篇#xff1a;Nacos帮我解决了什么问题#xff1f; 数据库连接信息
曾经有朋友跟我聊过…作为 Nacos 5W1H 的系列文章本文将围绕“Where”讲述 Nacos 配置管理的三个典型的应用场景
数据库连接信息限流阈值和降级开关流量的动态调度上一篇Nacos帮我解决了什么问题 数据库连接信息
曾经有朋友跟我聊过一个问题“业务飞速发展团队越来越大人员流动也相对频繁起来怎么才能更好的保证数据的安全性不被泄露呢”。他提到这样一个场景公司创立初期服务后端的代码都是他一行一行码出来的当时只有他一个人后端与数据库的连接配置信息也就直接放置在项目的配置文件中。他使用的是 Spring Boot 框架配置信息就是存放在 application.properties 中使用 Spring 的 profile 属性保证不同环境连接不同的数据库。如下所示
生产环境application-prod.properties
spring.datasource.url生产环境的数据库连接地址
spring.datasource.username生产环境的数据库用户账号
spring.datasource.password生产环境的数据库用户密码开发环境application-dev.properties
spring.datasource.url开发环境的数据库连接地址
spring.datasource.username开发环境的数据库用户账号
spring.datasource.password开发环境的数据库用户密码测试、预发环境也是类似。这种将数据库连接信息直接放置在配置文件中跟着项目代码一起通过 Git 管理的确是有蛮大的数据泄露的风险。试想一个新来不久的小伙伴他一当要投入研发工作有 Git Pull 代码的权限之后代表他可能就拥有了直接操作线上数据库的权限了。当时的我给他建议可以通过以下几个方面去降低数据风险
将数据库连接信息等敏感配置从项目中剥离数据库增加 IP 白名单连接限制最小权限原则每个账号只配置所必需的权限避免删表删库等高危操作定期修改数据库账号、密码。
回想起来我当时给的建议并没有完全解决他的问题甚至还带来了其他一些问题。例如上述的第一点“将敏感配置从项目剥离”剥离出来的敏感配置存放到哪里怎么管理这些配置呢也许你会想到存放到应用部署机器的环境变量或某个文件中。不一样有风险说不定哪天开发同学必须得登录上机器排查问题就有泄露的风险总之得尽可能地做到在整个开发流程都不会有任何泄露的风险。应用中可能不只是连接一个数据源分库分表的情况不同数据存储如 MySQL / Redis / Elasticsearch 等的情况还有其他更多敏感配置项配置数据的增多会给管理带来不便。
另外“定期修改数据库账号、密码”修改后我能怎么方便快捷的下发到所有应用程序中呢既然是敏感配置其变更也会带来不少的风险我需要能先到小量的几台机器验证保证对业务无影响我再全部下发到其他所有的机器上去是否还得有“灰度发布”的功能呢账号密码修改下发后应用出现异常影响到业务了我要怎么快速地回滚呢是否还得有“版本控制”、“快速回滚”的功能呢不是所有的开发同学都有权限能修改敏感配置信息是否还需要有“权限管控”的功能对敏感配置的任何操作都应该被记录是否还需要有“变更审计”的功能呢
现在我有了更好的建议使用 Nacos 配置管理模块将敏感配置信息都存放到 Nacos 中。Nacos 配置管理其中一个立身之本就是为敏感配置保驾护航。它提供上述场景所需的功能通过命名空间区分不同环境开发、测试、预发、生产通过“版本控制”保证变更可追溯通过“快速回滚”保证错误变更时影响最小通过的“灰度发布”功能保障配置安全平稳地变更还有更多更全面功能权限管控、变更审计等即将支持。
那么怎么将敏感配置项目的配置文件中迁移到 Nacos 中呢下面以 Spring Boot 连接 MySQL 为例
添加依赖
dependency
groupIdcom.alibaba.boot/groupId
artifactIdnacos-config-spring-boot-starter/artifactId
version${latest.version}/version
注意 Spring Boot 1.x 使用 nacos-config-spring-boot-starter 0.1.x 版本Spring Boot 2.x 使用 nacos-config-spring-boot-starter 0.2.x 版本。
在 application.properties 中添加 Nacos 连接配置
nacos.config.server-addr127.0.0.1:8848这里是简单的示例在实际生产中还需配置 Nacos 命名空间信息区分环境、鉴权信息如 AccessKey、SecretKey 等即将支持的权限访问控制。而 Nacos 配置模块对应的阿里云产品 ACM借助于 ECS 实例 RAM 角色最终能到达连 AccessKey、SecretKey 都不需要填写的目的。
添加 NacosPropertySource 注解
SpringBootApplication
NacosPropertySource(dataId mysql.properties)
public class SpringBootMySQLApplication {public static void main(String[] args) {SpringApplication.run(Application.class, args);
}在本地启动的 Nacos 控制台上新增 dataId 为 mysql.properties 的配置配置内容为 MySQL 连接配置信息
通过这四个简单的步骤就将 MySQL 连接信息从原来的 application.properties 迁移到 Nacos 的让 Nacos 将敏感配置管控起来大大降低数据泄露的风险。同时Nacos 配置管理提供的“统一管控”、“版本控制”、“快速回滚”等强大的功能也为其运维管理带来极大的便利。
限流阈值和降级开关
限流、降级众所周知是在开发高并发系统过程中需要考虑的两大关键点是运行时保护系统的两大利器。限流阈值和降级开关最终是抽象为一个个的配置项要想实现运行时的动态调整阈值和开关的启停将这些配置项存放到 Nacos 的配置模块中最适合不过了。
在今年 8 月的时候阿里巴巴开源了 Sentinel以流量为切入点从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。在阿里巴巴内部Nacos 跟 Sentinel 就是多年携手相伴砥砺前行的好机油为双 11 等各种大促立下了功劳也为剁手党提供了良好的购物体验。
下面就以 Sentinel 流控为例演示如果通过 Nacos 来做到运行时的动态控制流量
添加依赖
dependency
groupIdcom.alibaba.csp/groupId
artifactIdsentinel-core/artifactId
version${latest.version}/version
/dependency
dependency
groupIdcom.alibaba.csp/groupId
artifactIdsentinel-datasource-extension/artifactId
version${latest.version}/version
/dependency
dependency
groupIdcom.alibaba.csp/groupId
artifactIdsentinel-datasource-nacos/artifactId
version${latest.version}/version
/dependency
dependency
groupIdcom.alibaba/groupId
artifactIdfastjson/artifactId
version${latest.version}/version
2.模拟并发请求
final class RunTask implements Runnable {
Override
public void run() {while (!stop) {Entry entry null;try {entry SphU.entry(resourceName);// token acquired, means passpass.addAndGet(1);} catch (BlockException e1) {block.incrementAndGet();} catch (Exception e2) {// biz exception} finally {total.incrementAndGet();if (entry ! null) {entry.exit();}}Random random2 new Random();try {TimeUnit.MILLISECONDS.sleep(random2.nextInt(50));} catch (InterruptedException e) {// ignore}}
}3.配置 Nacos 连接信息与 dataId 等并将其设置为 Sentinel 的数据源
public class NacosDynamicFlowDemo {private static final String KEY TestResource;public static void main(String[] args) {final String remoteAddress localhost;final String groupId DEFAULT_GROUP;final String dataId com.alibaba.nacos.demo.flow.rule;ReadableDataSourceString, ListFlowRule flowRuleDataSource new NacosDataSource(remoteAddress, groupId, dataId,source - JSON.parseObject(source, new TypeReferenceListFlowRule() {}));FlowRuleManager.register2Property(flowRuleDataSource.getProperty());// Assume we config: resource is TestResource, initial QPS threshold is 5.FlowQpsRunner runner new FlowQpsRunner(KEY, 1, 10000);runner.simulateTraffic();runner.tick();
}4.在本地启动的 Nacos 控制台中新建 dataId 为 com.alibaba.nacos.demo.flow.rule 的流控配置 5.运行 NacosDynamicFlowDemo你会看到如下标准输出信息 再到 Nacos 控制台修改刚刚新建的流控配置将限流阈值 count 的值修改为 1.0完整的标准输出信息如下 以上示例演示了如何通过 Nacos Sentinel 实现动态流量控制的能力核心就是用到了 Nacos 配置模块“动态推送”的能力。原理是 sentinel-datasource-nacos 集成了 nacos-client 其与 nacos-server 维持着连接当用户在 Nacos 控制台进行配置变更时nacos-server 会快速地将该配置的最新内容推送到 nacos-client 中Sentinel 一拿到最新的流控配置就转换了流控策略如示例将流控阈值调整为 1.0限制为更少的流量进入系统的业务处理流程。
流量的动态调度
业务发展壮大到一定的规模单一的集群已经承载不了全部的用户请求需要将用户的流量分流到不同的集群上。当然更进一步的方案是不同的集群位于不同的区域这样除了缓解业务处理的压力也给系统带来容灾的能力。
比如某电商系统有 1 亿用户量将系统的流量按照用户的 ID 进行切分ID 为 1-1000W 的用户请求分发到区域 A 的集群 a 上ID 为 10001W-2000W 的用户请求流量分发到区域 B 的集群 b 上以此类推最终将所有用户的请求流量打散到 10 个不同区域的集群上同时每个集群冗余了一些系统资源。当区域 A 的机房发生不可抗的灾难如地震时我们需要有动态调度流量的能力最好能秒级得将流量从区域 A 调度到另外可用的区域的集群上。
这正是 Nacos 配置管理大有作为的地方将用户 ID 的分片和对应的路由规则存放在 Nacos 的中配合统一接入层等的组件就能将流量打散到各个集群上进而让系统能承载更大的流量以更好的支撑业务的发展。另外将其存放与 Nacos 中也就具备了配置“动态化”的能力一旦某区域出现基础设施无法及时恢复的问题时只需在 Nacos 的控制台上修改 ID 分片的路由规则就能将有问题的区域流量快速切换到其他可用的区域上保障对业务几乎无损。Nacos 在阿里内部能做到秒级推送到十万级别机器上的推送效率。
总结
除了以上三个场景其实还有更多更大胆的应用场景如“大数据实时计算算法调整”、“异地容灾多活”、“应用业务场景动态推送”等等可以参看 Nacos 的阿里云产品 ACM 的使用场景 。Nacos 配置管理模块将敏感配置收拢管控起来极大降低数据泄露等风险并且提供如“动态推送”、“版本控制”、“快速回滚”等功能保障了敏感配置的变更安全平稳的执行。
在限流与降级的场景通过一个示例为大家演示了如何通过 Nacos Sentinel 实现流量的动态控制这也是 Nacos 配置管理的一个十分典型的应用场景。降级也一样大促高峰期间将某个非关键的系统组件进行关闭在过了高峰期后再开启这个也是可以通过 Nacos 的“动态推送”的功能来实现。
总之只要系统涉及到了“敏感的配置”、“动态的配置”都应该考虑将配置放入到 Nacos 中让 Nacos 管控起来。 原文链接 本文为云栖社区原创内容未经允许不得转载。
