1.聊聊如何将数据同步到apollo配置中心
2.Apollo配置中心组件讲解
3.Apollo 8.0 配置参数读取源码解析：以 Planning 模块为例
4.终于把Apollo存储加密这件事搞定了 | 周末福利！源码
聊聊如何将数据同步到apollo配置中心
在微服务架构中，源码配置管理是源码一个关键环节。配置中心，源码如Apollo、源码Spring Cloud Config、源码cdd源码Diamond、源码Disconf、源码Nacos等，源码为集中式管理配置提供了便利，源码同时也支持热更新等特性。源码在实际项目中，源码我们常会遇到将配置数据先保存至数据库，源码再持久化到配置中心的源码场景。然而，源码直接将数据同步至配置中心可能更为便捷。本文以Apollo为例，介绍如何实现这一过程。 实现思路主要基于Apollo提供的开放API，通过该API可以执行配置的增删改查操作。具体步骤分为以下几个部分： 应用接入Apollo开放平台：通过Apollo管理员提供的管理界面创建第三方应用，获取token，并确保应用已授权操作权限。 授权操作权限：在管理员界面为应用分配相应的刻度尺源码权限，以管理特定的Namespace配置。 调用Apollo Open API：引入Apollo Open API库后，可以利用其接口进行配置操作。如同步API网关路由信息，首先通过API获取当前配置项，然后创建或更新配置项。 具体实现示例如下： 创建并发布配置项：利用Apollo Open API创建新的路由配置，并同步发布至配置中心。示例代码展示了如何通过API获取当前配置项的索引，然后构建并发布新的配置项，如路由规则。 更新配置项：若需要更新已有的配置项，同样通过API操作实现。示例中通过获取配置项的索引，更新其属性，如路由路径、条件等，并重新发布。 删除配置项：在需要删除配置项时，示例代码展示了通过API更新配置项为无效状态，以实现路由的删除。注意，物理删除配置可通过调用Apollo API的蓝冠平台源码removeItem方法完成。 在实际应用中，Apollo的API提供了RESTful风格的操作，使得配置管理变得更加高效。在使用时，需注意API的细节，如增删改与发布的操作分离，以及确保操作安全性和正确性。本文提供的示例仅为参考，建议在实际生产环境中进行验证和调整。 总结来说，利用Apollo的开放API，开发者可以实现数据的自动同步至配置中心，简化配置管理流程，提高开发效率和系统稳定性。类似地，若配置中心采用Nacos等其他服务，也提供了开放API接口，实现功能基本相同，感兴趣的读者可以自行探索。Apollo配置中心组件讲解
Apollo配置中心有什么组件，组件有什么作用 ?
从编译出来的jar包展开来讲，或是说运行包来说，只有4个组件，淘客方舟源码分别是：
Portal
提供Web界面供用户管理配置 通过Meta Server获取Admin Service服务列表（IP+Port），通过IP+Port访问服务 在Portal侧做load balance、错误重试
Admin Service
提供配置管理接口 提供配置修改、发布等接口 接口服务对象为Portal
Config Service
Config Service 包中包含了三个组件: config ,meta server,euraka
a. Config 组件
A. 提供配置获取接口
B. 提供配置更新推送接口（基于Http long polling）
i. 服务端使用Spring DeferredResult实现异步化，从而大大增加长连接数量
ii. 目前使用的tomcat embed默认配置是最多个连接（可以调整），使用了4C8G的虚拟机实测可以支撑个连接，所以满足需求（一个应用实例只会发起一个长连接）。
C. 接口服务对象为Apollo客户端
b. Meta Server组件
A. Portal通过域名访问Meta Server获取Admin Service服务列表（IP+Port）
B. Client通过域名访问Meta Server获取Config Service服务列表（IP+Port）
C. Meta Server从Eureka获取Config Service和Admin Service的服务信息，相当于是一个Eureka Client
D. 增设一个Meta Server的角色主要是为了封装服务发现的细节，对Portal和Client而言，永远通过一个Http接口获取Admin Service和Config Service的服务信息，而不需要关心背后实际的服务注册和发现组件
E. Meta Server只是一个逻辑角色，在部署时和Config Service是在一个JVM进程中的
c. Eureka组件
A. 基于Eureka和Spring Cloud Netflix提供服务注册和发现
B. Config Service和Admin Service会向Eureka注册服务，并保持心跳
C. 为了简单起见，目前Eureka在部署时和Config Service是在一个JVM进程中的（通过Spring Cloud Netflix）
Client
Apollo提供的客户端程序，为应用提供配置获取、实时更新等功能 通过Meta Server获取Config Service服务列表（IP+Port），通过IP+Port访问服务 在Client侧做load balance、错误重试
如果从用户访问数据流的关系图，大概类似如下的结构:
基本机制流程如下：
Config Service启动时候启动Config server，Meta server，Eureka三个服务 ，同时Config Server把自身注册到Eureka上面，计划类网站源码并保持心跳。 Admin Server 启动时，把自身注册到Eureka 上面，并保持心跳。 Config Server，Admin Server都通过Meta Server连接Eureka，所以Meta Server相当于一个Eureka的客户端，提供功能接口。 Portal 启动时候，通过Meta Server获取Admin Service 的列表（IP:PORT）,同时通过软件实现LB，错误重试 Client 客户端添加到开发项目中，项目启动后，客户端会通过Meta Server获取Config service的列表，并在客户端内部实现了LB,错误重试
如果理解了上面的组件以及数据流程，那么也应该明白如果要编译安装Apollo大概需要获得什么组件。参考上面的第一张图，那么编译后的Apollo组件应该有四个：Portal,Admin Service ,Config Server,Client 。
Apollo 8.0 配置参数读取源码解析：以 Planning 模块为例
目录
在本篇讨论中，我们将剖析 Apollo 8.0 配置参数的读取过程，以 Planning 模块为例进行深入探讨。
1. 配置参数分类
了解 Apollo 中各模块的启动机制，主要通过主文件 mainboard 编译生成的可执行文件以及动态链接库的加载实现。Planning 模块的 DAG 文件 (apollo/modules/planning/dag/planning.dag) 指定了模块的动态链接库和单个组件 PlanningComponent 的配置。
配置参数分为两类：基于 ProtoBuf 的参数和 gflags 命令行参数。Planning 模块的 ProtoBuf 配置文件为 (apollo/modules/planning/conf/planning_config.pb.txt)，与之对应的 ProtoBuf 接口文件为 (apollo/modules/planning/proto/planning_config.proto)。而 gflags 命令行参数配置文件为 (apollo/modules/planning/conf/planning.conf)。
1.1 ProtoBuf 参数
ProtoBuf 参数通过 module_config.components.config.config_file_path 指定配置文件路径，文件中的参数在组件初始化时被读入 ProtoBuf 对象。
1.2 gflags 命令行参数
gflags 参数通过 module_config.components.config.flag_file_path 指定，文件中的命令行参数在初始化时由 gflags 解析。
2. 配置参数读取流程
主入口文件 (apollo/cyber/mainboard/mainboard.cc) 的 main 函数负责加载 DAG 文件并启动模块。解析命令行参数、读取 DAG 文件、执行模块加载逻辑。
2.1 加载 DAG 文件
解析命令行参数形成 ModuleArgument，用于存储参数信息。执行主流程时，ModuleController 负责加载所有模块，并处理模块组件的注册、实例化和初始化。
2.2 读取配置参数
ModuleController 通过 LoadModule 方法读取模块配置，具体步骤涉及读取 ProtoBuf 参数和 gflags 命令行参数。
3. 总结
本文通过分析 Planning 模块的配置读取过程，清晰展示了 Apollo 8.0 中配置参数的完整读取流程。通过理解这一过程，开发者能够更深入地掌握 Apollo 的模块启动和配置机制。
终于把Apollo存储加密这件事搞定了 | 周末福利！
作者：尹吉欢 转自：微信公众号“程序员私房菜”
本文节选自《Spring Cloud微服务入门实战与进阶》
敏感配置，如密码等，我们期望进行加密存储，确保其安全性。然而，Apollo框架并未提供数据加密功能。若想实现此功能，有两种方法：一是修改Apollo源码，添加加解密逻辑；二是利用第三方框架进行数据加密。
jasypt-spring-boot是一款基于Spring Boot开发的框架，它可自动解密properties中加密的内容。在Apollo中，我们也可以利用jasypt-spring-boot实现数据的加解密操作。
jasypt-spring-boot的GitHub地址：github.com/ulisesbocchi...
使用jasypt-spring-boot提供的方法对需要加密的配置进行加密，然后将加密内容配置在Apollo中。项目启动时，jasypt-spring-boot会解密Apollo加密的配置，让使用者获取解密后的内容。
创建一个新的Maven项目，并加入Apollo和jasypt的依赖。具体依赖信息如下：
创建一个加密的工具类，用于加密配置。执行main方法后，可以得到如下输出：
input就是hello加密后的内容，将input的值复制存储到Apollo中。存储格式需要遵循一定规则，即需要将加密内容用ENC包起来，这样jasypt才会解密这个值。
使用时可以直接根据名称注入配置，例如：
input的值就是解密后的值，使用者无需关心解密逻辑，jasypt框架在内部处理好了。
jasypt整合Apollo也存在一些不足之处。目前，我只发现了以下两个问题：
上述两个问题与jasypt实现方式有关，意味着这种加密方式可能仅适用于数据库密码等场景，启动时可以解密，且仅使用一次。对于需要加密的核心业务配置，jasypt无法支持实时更新。下章节我将讲解如何修改Apollo源码来解决这两个问题。
扩展Apollo支持存储加解密
前文介绍了如何使用jasypt为Apollo中的配置进行加解密操作，基本需求可实现。但仍存在一些不足之处。
jasypt仅在启动时解密带有ENC（xx）格式的配置，当配置发生修改时无法更新。由于Apollo框架本身不具备对配置加解密的功能，若想实现加解密并支持动态更新，就需要修改Apollo源码来满足需求。
修改源码需要重新打包。这里介绍一种简单实现方法：创建一个与Apollo框架中相同类名的类进行覆盖，这样无需替换已使用的客户端。
若配置中心存储的内容是加密的，意味着Apollo客户端从配置中心拉取下来的配置也是加密的。我们需要在配置拉取下来后对其进行解密，然后再执行后续流程，如绑定到Spring中。在业务点进行切入后，配置中心加密的内容可自动转换为解密后的明文，对使用者透明。
通过分析Apollo源码，我找到了一个最合适的切入点来完成这项任务，即com.ctrip.framework.apollo.internals.DefaultConfig类。DefaultConfig是Config接口的实现类，配置的初始化和获取都会经过DefaultConfig的处理。
在DefaultConfig内部有一个更新配置的方法updateConfig，可在该方法中对加密数据进行解密处理：
这里使用AES进行解密，意味着配置中心的加密内容也需要使用相同的加密算法进行加密。至于格式，仍使用ENC(xx)格式来标识加密配置内容。解密后将明文内容重新赋值到Properties中，其他流程保持不变。
创建一个加密测试类，加密配置内容，并将其复制存储到Apollo中。输出内容如下：
Ke4LIPGOp3jCwbIHtmhmBA==
存储到Apollo中时，需要用ENC将加密内容包起来，如下：
test.input = ENC(Ke4LIPGOp3jCwbIHtmhmBA==)
使用之前的代码进行测试，Config获取和Spring注入的方式可以成功获取到解密后的数据，并且在配置中心修改后也能实时推送到客户端并成功解密。
本文摘自于《Spring Cloud微服务入门实战与进阶》一书。这是朋友写的一本新书，豆瓣评分8.2。