1. Antecedentes
En la actualidad, cada equipo de nuestra empresa utiliza diferentes centros de configuración. La empresa de comercio electrónico utiliza Spring Cloud Config, el pago utiliza Apollo y el equipo de APP utiliza Apollo+Nacos. Para hacer frente mejor al desarrollo del negocio de la empresa, es esencial contar con una pila de tecnología de infraestructura unificada.
Fuente de la imagen: Transmisión en vivo "Cómo hacer un buen trabajo en la selección de infraestructura de microservicios" – Li Yunhua
Además, Spring Cloud Config que utiliza el equipo de comercio electrónico se enfrenta a los siguientes problemas técnicos:
- Modificar la configuración requiere reiniciar el servicio
- La gestión de configuración no es amigable (modificada a través de gitlab)
- Falta de funciones como control de permisos, inspección de formato y configuración de seguridad
2. Selección del centro de configuración
Análisis de productos de código abierto
- Configuración de la nube de primavera
De código abierto en septiembre de 2014, los componentes ecológicos de Spring Cloud se pueden integrar perfectamente con el sistema Spring Cloud.
- Apolo
En mayo de 2016, Ctrip abrió un centro de administración de configuración distribuida confiable. Puede administrar de forma centralizada la configuración de diferentes entornos y diferentes grupos de aplicaciones. Una vez que se modifica la configuración, se puede enviar al lado de la aplicación en tiempo real y tiene las características de permisos estandarizados y gobernanza de procesos. Es adecuado para microservicios. escenarios de gestión de la configuración.
- Nacos
En junio de 2018, Ali abrió una plataforma de gestión de servicios, gestión de configuración y descubrimiento de servicios dinámicos que es más fácil de crear aplicaciones nativas de la nube. Se incubó en Alibaba y creció en la prueba máxima de Double Eleven en diez años. Ha acumulado la competitividad central de ser fácil de usar, estable y confiable, y un excelente rendimiento.
| artículo de comparación | Nacos | Apolo | Configuración de la nube de primavera | |
|---|---|---|---|---|
| Actividad comunitaria | hora de código abierto | 2018.6 | 2016.5 | 2014.9 |
| seguir | 20.5k | 26K | 1.7K | |
| documento | Completo | Completo | Completo | |
| actuación | Lectura independiente (QPS) | 15000 | 9000 | 7 (debido a la limitación actual) |
| Escritura independiente (QPS) | 1800 | 1100 | 5 (debido a la limitación actual) | |
| disponibilidad | Impacto del cierre del servicio (servicio de configuración) | Los clientes iniciados no afectan | Los clientes iniciados no afectan | Los clientes iniciados no afectan |
| modo de despliegue | grupo | grupo | grupo | |
| facilidad de uso | Tiempo efectivo de configuración | tiempo real | tiempo real | Reiniciar para que surta efecto, o actualización manual para que surta efecto |
| consistencia de los datos | Notificación asíncrona HTTP | La base de datos simula la cola de mensajes y Apollo lee regularmente el mensaje durante un minuto para que surta efecto en tiempo real. | Git garantiza la coherencia de los datos y el servidor de configuración lee los datos de Git | |
| interfaz de configuración | apoyo | apoyo | no apoyo | |
| Comprobación del formato de configuración | apoyo | apoyo | no apoyo | |
| reversión de la configuración | apoyo | apoyo | Compatible (reversión basada en git) | |
| gestión de versiones | apoyo | apoyo | Soporte (administración de versiones basada en git) | |
| Idiomas admitidos por el cliente | Java oficial No oficial Go, Python, NodeJS, C++ | Oficial java .net No oficial Go, Python, NodeJS, PHP, C++ | ||
| uso del cliente | cliente nacos | cliente apolo | cliente de configuración en la nube | |
| seguridad | gestión de autoridad | apoyo | Los permisos de datos completos son relativamente completos | apoyo (git) |
| Autorización/Auditoría/Revisión | apoyo | Operación directa en la interfaz y compatibilidad con la separación de permisos de modificación y publicación. | Confíe en la administración de permisos de git | |
| cifrado de datos | no apoyo | no apoyo | Cifrar y descifrar valores de propiedad | |
| complejidad arquitectónica | Costo de operación y mantenimiento | Nacos+MySQL (implementación sencilla) | Config+Admin+Portal+MySQL (implementación compleja) | Config-server+Git+MQ (implementación compleja) |
| dependencia del servicio | Es el centro de registro y descubrimiento de Alibaba Cloud.Las dos funciones están separadas. | Distribuido requiere centro de registro con eureka incorporado | Registro requerido | |
| Lanzamiento gris | Admite la configuración del cliente y el acoplamiento informático de la regla de enrutamiento del cliente es alto y engorroso | Admite la configuración del lado del servidor y las reglas de enrutamiento. El cliente de cálculo del lado del servidor es transparente y simple. | apoyo | |
| servicio de correo | no apoyo | apoyo | no apoyo | |
| Supervisión de la configuración de consultas | apoyo | apoyo | apoyo |
- Desde la perspectiva del rendimiento: rendimiento de lectura y escritura Nacos > Apollo > Spring Cloud Config.
- Desde la perspectiva de la función: integridad de la función Apollo > Nacos > Spring Cloud Config.
- Desde la perspectiva de la actividad de la comunidad: resulta que el Netflix ecológico de Spring Cloud básicamente no mantiene mucho, porque no genera dinero; pero el ecosistema de microservicios de Spring Alibaba siempre será de código abierto y se mantendrá, porque Ali gana dinero después de convertir este pieza de SaaS.
- Ventajas de Nacos: Sencillo. Integra las funciones de centro de registro y centro de configuración, y su despliegue y operación son más intuitivos y sencillos que Apollo, por lo que simplifica la complejidad de la arquitectura y reduce el trabajo de operación y mantenimiento y despliegue.
comparación de rendimiento
- Información de prensa
Procesador: CPU Intel® Core™ i5-9500 a 3,00 GHz 3,00 GHz
Sistema: ventanas 10
Prueba interna: 16G
- Herramienta de medición de presión: JMeter
- Estrategia de prueba de presión: 100 usuarios solicitan subproceso 10 abierto incrementalmente, duración 100s
Escenario 1: Llamar al servidor
Los resultados de la prueba son los siguientes:
A través de la prueba de presión, se encuentra que el TPS de la configuración de lectura de Nacos es de aproximadamente 11000, el TPS de la configuración de escritura es de aproximadamente 1800, mientras que el TPS de la configuración de lectura de Apollo es de aproximadamente 1100 y el TPS de la configuración de escritura es de aproximadamente 310. Nacos tiene ventajas obvias en el rendimiento de lectura y escritura.
Escenario 2: llamar al cliente
Los resultados de la prueba son los siguientes:
Se puede ver que el rendimiento de lectura no es muy diferente.
en conclusión
| Motivo de la selección | Razón para no elegir | |
|---|---|---|
| Nacos | La pila de tecnología unificada puede resolver los puntos débiles de las tecnologías existentes Bajos costos de operación y mantenimiento | |
| Apolo | Confía en Eureka | |
| Configuración de la nube de primavera |
Documentos de referencia:
3. Uso rápido
Documento de referencia: https://nacos.io/en-us/docs/quick-start-spring-boot.html
dependencias de actualización
Eliminar la dependencia de spring-cloud-config:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-config</artifactId>
</dependency>
Agregue la dependencia de Nacos:
<dependency>
<groupId>com.alibaba.boot</groupId>
<artifactId>nacos-config-spring-boot-starter</artifactId>
<version>0.1.8</version>
</dependency>
Reemplazar la configuración de Nacos
Reemplace la configuración de configuración en el archivo bootstrap.yml original con la configuración de nacos.
spring:
application:
name: {
应用名}
cloud: # 移除
config: # 移除
uri: http://config-center.alpha-intra.dbses.com/conf # 移除
label: alpha # 移除
Los resultados del reemplazo son los siguientes:
spring:
application:
name: {
应用名}
nacos:
config:
server-addr: http://ec-nacos.dbses.com
namespace: alpha
group: {
组名}
Agregar anotaciones a la clase de inicio
// dataId 对应服务的配置
@NacosPropertySource(groupId = "${nacos.config.group}", dataId = "${spring.application.name}.yml", first = true)
public class WebApplication {
public static void main(String[] args) {
SpringApplication.run(WebApplication.class, args);
}
}
4. Practica
Configurar actualización dinámica
Método 1: usa @NacosValue
Para usar este método, debe agregar autoRefreshed=true a @NacosPropertySource. El código de ejemplo es el siguiente:
@NacosPropertySource(groupId = "infra", dataId = "zebra-service.yml", first = true, autoRefreshed = true)
public class WebApplication {
public static void main(String[] args) {
SpringApplication.run(WebApplication.class, args);
}
}
Nacos se configura de la siguiente manera:
test1:
config: 2
El código de la interfaz es el siguiente:
@RestController
public class TestController {
@NacosValue(value = "${test1.config}", autoRefreshed = true)
private String config;
@GetMapping("/config")
public String getConfig() {
return config;
}
}
Método 2: Utilice @NacosConfigurationProperties
El código de ejemplo es el siguiente:
@Configuration
@Data
@NacosConfigurationProperties(prefix = "test2", dataId = "zebra-service.yml", groupId = "infra", autoRefreshed = true)
public class TestConfig {
private List<String> config;
private Map<String, String> map;
@Override
public String toString() {
return "TestConfig{" + "config=" + config + ", map=" + map + '}';
}
}
Nacos se configura de la siguiente manera:
test2:
config:
- yang
- wang
map:
courier: yang
zebra: wang
El código de la interfaz es el siguiente:
@RestController
public class TestController {
@Autowired
private TestConfig testConfig;
@GetMapping("/config2")
public String getConfig2() {
return testConfig.toString();
}
}
Aviso
Actualice el mapa dinámicamente, la clave modificada se acumulará y la clave original no se eliminará. Por ejemplo, después de cambiar test2.map.zebra en la configuración de zebra-service.yml a test2.map.zebr, los resultados obtenidos son los siguientes:
TestConfig{config=[yang, dinero], map={courier=yang, zebra=dinero, zebr=dinero}}
Método 3: Utilice @NacosConfigListener
Nacos se configura de la siguiente manera:
test1:
config: 2
El código de ejemplo es el siguiente:
@RestController
public class TestController {
@Value(value = "${test1.config}")
private String config;
@GetMapping("/config")
public String getConfig() {
return config;
}
@NacosConfigListener(dataId = "zebra-service.yml", groupId = "infra")
public void testConfigChange(String newContent) {
YamlPropertiesFactoryBean yamlFactory = new YamlPropertiesFactoryBean();
yamlFactory.setResources(new ByteArrayResource(newContent.getBytes()));
Properties commonsProperties = yamlFactory.getObject();
this.config = commonsProperties.getProperty("test1.config"));
}
}
Importación de múltiples configuraciones
Descripción del problema
Nuestro proyecto ha leído muchas configuraciones públicas antes, y ahora queremos leer configuraciones públicas, ¿qué debemos hacer?
problema resuelto
Se pueden agregar varios archivos de configuración mediante la anotación @NacosPropertySources.
Código de muestra:
@NacosPropertySources({
@NacosPropertySource(groupId = "infra", dataId = "captcha-service.yml", first = true),
@NacosPropertySource(groupId = "commons", dataId = "__common_eureka_.yml")
})
public class WebApplication {
public static void main(String[] args) {
SpringApplication.run(WebApplication.class, args);
}
}
Aquí first = true significa que la prioridad de configuración de este archivo es la más alta.
anulación de la configuración local
Descripción del problema
Como desarrollador, es posible que necesitemos iniciar el programa localmente para la depuración, pero en este momento el programa iniciado localmente está conectado a la configuración del entorno alfa. Si modifica la configuración del entorno alfa, puede afectar el funcionamiento de alfa y otros programas.
Ante esta situación, ¿cómo gestionamos la prioridad de configuración?
Tomemos como ejemplo la configuración test1.config. El archivo de configuración de nacos es el siguiente:
La configuración de inicio es la siguiente:
El código de prueba es el siguiente:
@RestController
public class TestController {
@NacosValue(value = "${test1.config}", autoRefreshed = true)
private String config1;
@GetMapping("/config1")
public String getConfig1() {
return config1;
}
}
El resultado de la ejecución es:
La configuración local no logra el efecto de cobertura.
análisis del problema
También podríamos transformar primero la clase de inicio del programa.
Se puede ver desde el punto de interrupción que la prioridad de la configuración de la aplicación (aquí se refiere a zebra-service.yml en nacos, lo mismo a continuación) es anterior a la configuración pública, que es necesaria.
La configuración de la aplicación debe preceder a la configuración pública.
Pero la configuración de la aplicación también es anterior a las variables del sistema (systemProperties) y al entorno del sistema (systemEnvironment). Entonces, el test1.config que configuramos no tuvo efecto como local.
Con una ligera modificación:
problema resuelto
Luego pruebe si la configuración local se sobrescribe.
La configuración local ha alcanzado el efecto de cobertura. El código de clase de inicio final es:
@SpringBootApplication
@EnableDiscoveryClient
@EnableFeignClients
@PrepareConfigurations({
"__common_database_", "__common_eureka_"})
@NacosPropertySource(groupId = "infra", dataId = "zebra-service.yml", autoRefreshed = true
,after = StandardEnvironment.SYSTEM_PROPERTIES_PROPERTY_SOURCE_NAME
)
public class WebApplication {
public static void main(String[] args) {
SpringApplication.run(WebApplication.class, args);
}
}
¡Este artículo está publicado por OpenWrite, una plataforma de publicación múltiple para blogs !