Apollo分布式配置中心好好学一

Apollo分布式配置中心好好学一

大纲

1、Apollo简介

2、Apollo入门

1、Apollo简介

        分布式系统中,微服务往往都是集群部署,若配置发生改变,则需要重新部署多台应用,运维成本高,采用分布式配置中心,将配置从应用剥离出来,统一管理,优雅的解决了配置的动态变更、持久化、运维成本等问题。

        总得来说,配置中心就是一种统一管理各种应用配置的基础服务组件。

        集中管理配置,那么就要将应用的配置作为一个单独的服务抽离出来了,同理也需要解决新的问题,比如:版本管理(为了支持回滚),权限管理等。一个合格的配置中心需要满足:

配置项容易读取和修改
添加新配置简单直接
支持对配置的修改的检视以把控风险
可以查看配置修改的历史记录
不同部署环境支持隔离

1.1 主流的配置中心

目前市面上用的比较多的配置中心有:(按开源时间排序)

1、Disconf

        2014年7月百度开源的配置管理中心,专注于各种「分布式系统配置管理」的「通用组件」和「通用平台」,提供统一的「配置管理服务」。目前已经不再维护更新。 https://github.com/knightliao/disconf

2、Spring Cloud Config

        2014年9月开源,Spring Cloud 生态组件,可以和Spring Cloud体系无缝整合。 https://github.com/spring-cloud/spring-cloud-config

3、Apollo         2016年5月,携程开源的配置管理中心,能够集中化管理应用不同环境、不同集群的配置,配置修改后能够实 时推送到应用端,并且具备规范的权限、流程治理等特性,适用于微服务配置管理场景。 https://github.com/ctripcorp/apollo

4、Nacos

        2018年6月,阿里开源的配置中心,也可以做DNS和RPC的服务发现。 https://github.com/alibaba/nacos

1.2 功能特性对比

        总的来看,Apollo和Nacos相对于Spring Cloud Config的生态支持更广,在配置管理流程上做的更好。Apollo相对于Nacos在配置管理做的更加全面,Nacos则使用起来相对比较简洁,在对性能要求比较高的大规模场景更适合。但对于一个开源项目的选型,项目上的人力投入(迭代进度、文档的完整性)、社区的活跃度(issue的数量和解决速度、Contributor数量、社群的交流频次等),这些因素也比较关键,考虑到Nacos开源时间不长和社区活跃度,所以从目前来看Apollo应该是最合适的配置中心选型。

1.3 Apollo特性

        基于配置的特殊性,所以Apollo从设计之初就立志于成为一个有治理能力的配置发布平台,目前提供了以下的特 性:

1、统一管理不同环境、不同集群的配置

1、Apollo提供了一个统一界面集中式管理不同环境(environment)、不同集群(cluster)、不同命名空间(namespace)的配置。

2、同一份代码部署在不同的集群,可以有不同的配置,比如zookeeper的地址等 

3、通过命名空间(namespace)可以很方便地支持多个不同应用共享同一份配置,同时还允许应用对共享的配置进行覆盖

2、配置修改实时生效(热发布)         用户在Apollo修改完配置并发布后,客户端能实时(1秒)接收到最新的配置,并通知到应用程序

3、版本发布管理         所有的配置发布都有版本概念,从而可以方便地支持配置的回滚 4、灰度发布         支持配置的灰度发布,比如点了发布后,只对部分应用实例生效,等观察一段时间没问题后再推给所有应用实例

5、权限管理、发布审核、操作审计         应用和配置的管理都有完善的权限管理机制,对配置的管理还分为了编辑和发布两个环节,从而减少人为的错误。所有的操作都有审计日志,可以方便地追踪问题 6、客户端配置信息监控

        可以在界面上方便地看到配置在被哪些实例使用 7、提供Java和.Net原生客户端         提供了Java和.Net的原生客户端,方便应用集成

        支持Spring Placeholder, Annotation和Spring Boot的ConfigurationProperties,方便应用使用(需要Spring 3.1.1+)         同时提供了Http接口,非Java和.Net应用也可以方便地使用

8、提供开放平台API

        Apollo自身提供了比较完善的统一配置管理界面,支持多环境、多数据中心配置管理、权限、流程治理等特性。不过Apollo出于通用性考虑,不会对配置的修改做过多限制,只要符合基本的格式就能保存,         不会针对不同的配置值进行针对性的校验,如数据库用户名、密码,Redis服务地址等 对于这类应用配置,Apollo支持应用方通过开放平台API在Apollo进行配置的修改和发布,并且具备完善的授权和权限控制

2、Apollo入门

2.1 执行流程

1、在Apollo配置中心修改配置 2、应用程序通过Apollo客户端从配置中心拉取配置信息         用户通过Apollo配置中心修改或发布配置后,会有两种机制来保证应用程序来获取最新配置:一种是Apollo配置中心会向客户端推送最新的配置;另外一种是Apollo客户端会定时从Apollo配置中心拉取最新的配置,通过以上两种 机制共同来保证应用程序能及时获取到配置。

实时推送:

1、在Protal界面操作发布配置,protal会请求adminservice向数据库保存刚修改的信息,向
ReleaseMessage表插入一条消息记录,消息内容就是配置发布的AppId+Cluster+Namespace
2、Config Service有一个线程会每秒扫描一次ReleaseMessage表,看看是否有新的消息记录, 
如果有新的记录会获取最新的配置,通知到客户端。 
3、客户端会把从服务端获取到的配置在本地文件系统缓存一份

定时拉取:

        客户端还会定时从Apollo配置中心服务端拉取应用的最新配置。定时频率默认为每5分钟拉取一次,客户端也可以通过在运行时指定System Property: apollo.refreshInterval来覆盖,单位为分钟

2.2 安装

1、环境要求:

Apollo服务端:1.8+
Apollo客户端:1.7+ 
Mysql环境:5.6.5+ 
Apollo的表结构对 timestamp 使用了多个default声明,所以需要5.6.5以上版本

2、下载地址:

        Tags · apolloconfig/apollo · GitHub

apollo-adminservice-1.8.1-github.zip
apollo-configservice-1.8.1-github.zip
apollo-portal-1.8.1-github.zip

3、创建数据库

        Apollo服务端共需要两个数据库: ApolloPortalDB 和 ApolloConfigDB ,ApolloPortalDB只需要在生产环境部署一个即可,而ApolloConfigDB需要在每个环境部署一套。

1、创建ApolloPortalDB数据库
apollo/ApolloPortalDB__initialization.sql  
2、创建ApolloConfigDB 
apollo/ApolloConfigDB__initialization.sql 

        启动:Apollo默认会启动3个服务,分别使用8070, 8080, 8090端口,请确保这3个端口当前没有被使用

启动apollo-configservice
java ‐Xms256m ‐Xmx256m ‐Dspring.datasource.url=jdbc:mysql://localhost:3306/ApolloConfigDB?
characterEncoding=utf8 ‐Dspring.datasource.username=root ‐
Dspring.datasource.password=itcast0430 ‐jar apollo‐configservice‐1.8.1.jar 
 
启动apollo-adminservice 
java ‐Xms256m ‐Xmx256m ‐Dspring.datasource.url=jdbc:mysql://localhost:3306/ApolloConfigDB?
characterEncoding=utf8 ‐Dspring.datasource.username=root ‐
Dspring.datasource.password=itcast0430 ‐jar apollo‐adminservice‐1.8.1.jar 


启动apollo-portal
java ‐Xms256m ‐Xmx256m ‐Ddev_meta=http://localhost:8080/ ‐Dserver.port=8070 ‐
Dspring.datasource.url=jdbc:mysql://localhost:3306/ApolloPortalDB?characterEncoding=utf8 ‐
Dspring.datasource.username=root ‐Dspring.datasource.password=itcast0430 ‐jar apollo‐
portal‐1.8.1.jar

2.3 核心概念

1、application 引用 appId

        是实际使用配置的应用,Apollo客户端在运行时需要知道当前应用是谁,从而可以去获取对应的配置

2、environment 环境

        配置对应的环境,Apollo客户端在运行时需要知道当前应用处于哪个环境,从而可以去获取应用的配置

3、cluster 集群

        一个应用下不同实例的分组,比如典型的可以按照数据中心分,把上海机房的应用实例分为一个集群,把北京机房的应用实例分为另一个集群。

4、namespace (命名空间)

        一个应用下不同配置的分组,可以简单地把namespace类比为文件,不同类型的配置存放在不同的文件中,如数据库配置文件,RPC配置文件,应用自身的配置文件等

2.4 Apollo原理

        apollo一共由四个部分client,config,admin,protal组成。其中config server是提供配置的读取和推送,Admin Service提供配置的修改、发布等功能。

1、Config Service提供配置的读取、推送等功能,服务对象是Apollo客户端 2、Admin Service提供配置的修改、发布等功能,服务对象是Apollo Portal(管理界面) 3、Config Service和Admin Service都是多实例、无状态部署,所以需要将自己注册到Eureka中并保持心跳 4、在Eureka之上我们架了一层Meta Server用于封装Eureka的服务发现接口 5、Client通过域名访问Meta Server获取Config Service服务列表(IP+Port),而后直接通过IP+Port访问服务,同时在Client侧会做load balance、错误重试 6、Portal通过域名访问Meta Server获取Admin Service服务列表(IP+Port),而后直接通过IP+Port访问服务,同时在Portal侧会做load balance、错误重试 为了简化部署,我们实际上会把Config Service、Eureka和Meta Server三个逻辑角色部署在同一个JVM进程中

end
  • 作者:旭仔(联系作者)
  • 发表时间:2024-05-28 21:16
  • 版权声明:自由转载-非商用-非衍生-保持署名
  • 转载声明:如果是转载栈主转载的文章,请附上原文链接
  • 公众号转载:请在文末添加作者公众号二维码(公众号二维码见右边,欢迎关注)
  • 评论