华为技术专家谈微服务分布式架构的服务配置管理

本文涉及的产品
云原生网关 MSE Higress,422元/月
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
注册配置 MSE Nacos/ZooKeeper,118元/月
简介: 单体应用只需管理一套配置,而微服务架构后,每个系统都有自己的配置,并且各不相同,有些配置还需要能够动态改变,以动态降级、切流量、扩缩容,那微服务架构下,到底服务配置该如何管理。本地配置最简单的,在代码里写配置。

单体应用只需管理一套配置,而微服务架构后,每个系统都有自己的配置,并且各不相同,有些配置还需要能够动态改变,以动态降级、切流量、扩缩容,那微服务架构下,到底服务配置该如何管理。

本地配置

最简单的,在代码里写配置。

比如下面这段代码用到Hystrix,并且在代码里定义了几个配置:

  • 线程的超时时间是3000ms
  • 熔断器触发的错误比率是60%
@HystrixCommand(fallbackMethod = "getDefaultProductInventoryByCode",
    commandProperties = {
       @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "3000"),
       @HystrixProperty(name = "circuitBreaker.errorThresholdPercentage", value="60")
    }
)
public Optional<ProductInventoryResponse> getProductInventoryByCode(String productCode)
{
    ....
}

还有一种方式,就是抽取到配置文件

使配置与代码分离,比如下面这段代码。

@HystrixCommand(commandKey = "inventory-by-productcode", fallbackMethod = "getDefaultProductInventoryByCode")
public Optional<ProductInventoryResponse> getProductInventoryByCode(String productCode)
{
    ...
}

相应的配置可以抽离到配置文件中,配置文件的内容如下:

hystrix.command.inventory-by-productcode.execution.isolation.thread.timeoutInMilliseconds=2000
hystrix.command.inventory-by-productcode.circuitBreaker.errorThresholdPercentage=60

以上方案都相当于把配置存在应用程序的本地。这样如果需要修改配置,就要重新走一遍代码或配置的发布流程。这往往需要一次新的上线发布过程,且权限更繁琐。

倘若能有一个集中管理配置的地方,若要修改配置,只需在这个地方修改一下,线上服务就自动从这个地方同步过去,不需要走代码或配置的发布流程,不就简单多了?


这就是配置中心


设计思想就是把服务的各种配置,如


代码里配置的各种参数

服务降级的开关

依赖的资源等

都集中统一管理。服务启动时,可自动从配置中心中拉取所需配置,且若有配置变更,同样可自动从配置中心拉取最新配置信息,服务无需重新发布。


配置中心一般包含如下功能:


配置注册

配置反注册

配置查看

配置变更订阅

那配置中心的这些功能是如何实现的呢?


配置存储结构


一般配置中心存储配置按Group存的,同类配置放在一个Group下,以K, V键值对存储


配置注册


配置中心对外提供接口/config/service?action=register完成配置的注册功能,需要传递的参数包括配置对应的分组Group,以及对应的Key、Value。


比如调用下面接口请求就会向配置项global.property中添加Key为reload.locations、Value为/data1/confs/system/reload.properties的配置。

curl "http://ip:port/config/service?action=register" 
-d "group=global.property&key=reload.locations&value=/data1/confs/system/reload.properties"

配置反注册

配置中心对外提供接口config/service?action=unregister,传递参数包括配置对象的分组Group、对应的Key。

比如调用下面的接口请求就会从配置项global.property中把Key为reload.locations的配置删除。

curl "http://ip:port/config/service?action=unregister" -d
"group=global.property&key=reload.locations"

配置查看

配置中心对外提供接口config/service?action=lookup,需传参配置对象的分组Group、对应的Key。

比如调用下面的接口请求就会返回配置项global.property中Key为reload.locations的配置值。

curl "http://ip:port/config/service?  
  action=lookup&group=global.property&key=reload.locations"

配置变更订阅

配置中心对外提供接口config/service?action=getSign来完成配置变更订阅接口,客户端本地会保存一个配置对象的分组Group的sign值,同时每隔一段时间去配置中心拉取该Group的sign值,与本地保存的sign值做对比。一旦配置中心中的sign值与本地的sign值不同,客户端就会从配置中心拉取最新的配置信息。比如调用下面的接口请求就会返回配置项global.property中Key为reload.locations的配置值。

curl "http://ip:port/config/service?
  action=getSign&group=global.property"

配置中心便于我们管理服务的配置信息,并且如果要修改配置信息,只需要同配置中心交互,应用程序会通过订阅配置中心的配置,自动完成配置更新。


哪些场景适合使用配置中心呢?


资源服务化


应用规模不大时,所依赖的资源如Redis缓存或者RabbitMQ消息队列的数量不多,对应IP可直接写在配置。


但随公司赚到钱后,所依赖资源数量也开始骤增,比如上千个。这时就经常会遇到个别节点不可用,若还采用本地配置,就需要去更改本地配置,把不可用的IP改成可用IP,然后发布新的配置,太麻烦了!


可采用资源服务化,把对应缓存统统归为一类配置,然后若有个别机器不可用,只需在配置中心把对应IP换成可用的IP,应用程序会自动同步到本机,也无须发布。


业务动态降级


微服务架构下,拆分的服务越多,出现故障的概率就越大,因此需要有对应的服务治理手段,比如要具备动态降级能力,在依赖的服务出现故障的情况下,可以快速降级对这个服务的调用,从而保证不受影响。为此,服务消费者可以通过订阅依赖服务是否降级的配置,当依赖服务出现故障的时候,通过向配置中心下达指令,修改服务的配置为降级状态,这样服务消费者就可以订阅到配置的变更,从而降级对该服务的调用。


分组流量切换


为保证异地多活以及本地机房调用,一般服务提供者的部署会按照IDC维度进行部署,每个IDC划分为一个分组。此时,若一个IDC出现故障,可以把故障IDC机房的调用切换到其他正常IDC。为此,服务消费者可以通过订阅依赖服务的分组配置,当依赖服务的分组配置发生变更时,服务消费者就对应的把调用切换到新的分组,从而实现分组流量切换。


开源配置中心选型


Spring Cloud Config

Spring Cloud中使用的配置中心组件,只支持Java语言,配置存储在git中,变更配置也需要通过git操作,如果配置中心有配置变更,需要手动刷新。

Spring Cloud Config作为配置中心的功能比较弱,只能通过git命令操作,而且变更配置的话还需要手动刷新,如果不是采用Spring Cloud框架,不建议选择。


Apollo

携程开源的分布式配置中心,支持Java和.Net语言,客户端和配置中心通过HTTP长连接实现实时推送,并且有统一的管理界面来实现配置管理。

Apollo功能强大,在国内许多互联网公司内部都有大量应用,其中Apollo对Spring Boot的支持比较好,如果应用本身采用的是Spring Boot开发的话,集成Apollo更容易。


目录
相关文章
|
1月前
|
Kubernetes Cloud Native 微服务
探索云原生技术:容器化与微服务架构的融合之旅
本文将带领读者深入了解云原生技术的核心概念,特别是容器化和微服务架构如何相辅相成,共同构建现代软件系统。我们将通过实际代码示例,探讨如何在云平台上部署和管理微服务,以及如何使用容器编排工具来自动化这一过程。文章旨在为开发者和技术决策者提供实用的指导,帮助他们在云原生时代中更好地设计、部署和维护应用。
|
1月前
|
弹性计算 API 持续交付
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程,分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性,然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构,指出微服务化转型的必要性和实施策略。最后,讨论了微服务架构实施过程中可能遇到的问题及解决方案。
|
26天前
|
监控 安全 API
使用PaliGemma2构建多模态目标检测系统:从架构设计到性能优化的技术实践指南
本文详细介绍了PaliGemma2模型的微调流程及其在目标检测任务中的应用。PaliGemma2通过整合SigLIP-So400m视觉编码器与Gemma 2系列语言模型,实现了多模态数据的高效处理。文章涵盖了开发环境构建、数据集预处理、模型初始化与配置、数据加载系统实现、模型微调、推理与评估系统以及性能分析与优化策略等内容。特别强调了计算资源优化、训练过程监控和自动化优化流程的重要性,为机器学习工程师和研究人员提供了系统化的技术方案。
146 77
使用PaliGemma2构建多模态目标检测系统:从架构设计到性能优化的技术实践指南
|
20天前
|
NoSQL 前端开发 测试技术
👀探秘微服务:从零开启网关 SSO 服务搭建之旅
单点登录(Single Sign-On,简称SSO)是一种认证机制,它允许用户只需一次登录就可以访问多个应用程序或系统。本文结合网关和SaToken快速搭建可用的Session管理服务。
75 8
|
16天前
|
存储 缓存 负载均衡
从零到一:分布式缓存技术初探
分布式缓存通过将数据存储在多个节点上,利用负载均衡算法提高访问速度、降低数据库负载并增强系统可用性。常见产品有Redis、Memcached等。其优势包括性能扩展、高可用性、负载均衡和容错性,适用于页面缓存、应用对象缓存、状态缓存、并行处理、事件处理及极限事务处理等多种场景。
42 1
|
20天前
|
分布式计算 大数据 数据处理
技术评测:MaxCompute MaxFrame——阿里云自研分布式计算框架的Python编程接口
随着大数据和人工智能技术的发展,数据处理的需求日益增长。阿里云推出的MaxCompute MaxFrame(简称“MaxFrame”)是一个专为Python开发者设计的分布式计算框架,它不仅支持Python编程接口,还能直接利用MaxCompute的云原生大数据计算资源和服务。本文将通过一系列最佳实践测评,探讨MaxFrame在分布式Pandas处理以及大语言模型数据处理场景中的表现,并分析其在实际工作中的应用潜力。
57 2
|
1月前
|
运维 Cloud Native 持续交付
云原生技术深度探索:重塑现代IT架构的无形之力####
本文深入剖析了云原生技术的核心概念、关键技术组件及其对现代IT架构变革的深远影响。通过实例解析,揭示云原生如何促进企业实现敏捷开发、弹性伸缩与成本优化,为数字化转型提供强有力的技术支撑。不同于传统综述,本摘要直接聚焦于云原生技术的价值本质,旨在为读者构建一个宏观且具体的技术蓝图。 ####
|
1月前
|
弹性计算 Kubernetes API
构建高效后端服务:微服务架构的深度剖析与实践####
本文深入探讨了微服务架构的核心理念、设计原则及实现策略,旨在为开发者提供一套系统化的方法论,助力其构建灵活、可扩展且易于维护的后端服务体系。通过案例分析与实战经验分享,揭示了微服务在提升开发效率、优化资源利用及增强系统稳定性方面的关键作用。文章首先概述了微服务架构的基本概念,随后详细阐述了其在后端开发中的应用优势与面临的挑战,最后结合具体实例,展示了如何从零开始规划并实施一个基于微服务的后端项目。 ####
|
2月前
|
设计模式 Java API
微服务架构演变与架构设计深度解析
【11月更文挑战第14天】在当今的IT行业中,微服务架构已经成为构建大型、复杂系统的重要范式。本文将从微服务架构的背景、业务场景、功能点、底层原理、实战、设计模式等多个方面进行深度解析,并结合京东电商的案例,探讨微服务架构在实际应用中的实施与效果。
151 6
|
2月前
|
设计模式 Java API
微服务架构演变与架构设计深度解析
【11月更文挑战第14天】在当今的IT行业中,微服务架构已经成为构建大型、复杂系统的重要范式。本文将从微服务架构的背景、业务场景、功能点、底层原理、实战、设计模式等多个方面进行深度解析,并结合京东电商的案例,探讨微服务架构在实际应用中的实施与效果。
57 1