Spring Cloud 系列之 Apollo 配置中心(四)
本篇文章为系列文章,未读前几集的同学请猛戳这里:
本篇文章讲解 Apollo 高可用环境搭建,灰度发布,教大家搭建企业中真实环境的配置中心。
高可用环境搭建
点击链接观看:Apollo 高可用环境搭建视频(获取更多请关注公众号「哈喽沃德先生」)
分析
数据库高可用
方案很多,比如双主结构、主从结构、异地备份等等,还可以选择第三方云数据库服务,让云服务厂商去保证数据库的高可用性,这样不仅比自己实现起来更可靠、更轻松,而且还方便管理等。
AdminService 高可用
在 Apollo 中所有的 Admin Service 都会注册到 Eureka 里,所以我们只需要配置多台 AdminService,数据库采用同一套即可。
ConfigService 高可用
在 Apollo 的设计中每个 ConfigService 也是一个 Euerka 的注册中心,所以保证 ConfigService 高可用的前提是保证 Eureka 的高可用,Eureka 的高可用实际上就是将自己作为服务向其他服务注册中心注册自己,这样就可以形成一组互相注册的服务注册中心,以实现服务清单的互相同步,达到高可用的效果。
实践
再来一台机器 192.168.10.104 然后将
apollo-configservice-x.x.x-github.zip和
apollo-adminservice-x.x.x-github.zip上传至该机器,解压以后都配置 102 机器的数据库,我们搭建一个 DEV 的高可用环境。
配置数据库
- 将 ConfigService 和 AdminService 上传至 192.168.10.104
- 解压
- 打开
config
目录下的application-github.properties
文件 - 填写正确的
ApolloConfigDB
数据库连接串信息,注意用户名和密码后面不要有空格! - 修改完的效果如下:
# DataSource spring.datasource.url = jdbc:mysql://192.168.10.102:3306/ApolloConfigDB?characterEncoding=utf8 spring.datasource.username = root spring.datasource.password = 1234
调整服务端配置
Eureka 注册中心地址存储在
ApolloConfigDB.ServerConfig表中,如下图,在③Value的地方添加多个地址即可。
配置 apollo-portal 的 meta service 信息
Apollo Portal 需要在不同的环境访问不同的 meta service(apollo-configservice) 地址,所以我们需要在配置中提供这些信息。默认情况下,meta service 和 config service 是部署在同一个JVM进程,所以 meta service 的地址就是 config service 的地址。
❝对于 1.6.0 及以上版本,可以通过 ApolloPortalDB.ServerConfig 中的配置项来配置 Meta Service 地址。
❞
新版本配置方式
通过
apollo.portal.meta.servers添加 meta service(apollo-configservice) 地址,类似以下方式,修改完需要重启生效。
{ "DEV":"http://192.168.10.102:8080,http://192.168.10.104:8080", "PRO":"http://192.168.10.103:8080" }
旧版本配置方式
打开
apollo-portal-x.x.x-github.zip中
config目录下的
apollo-env.properties文件。
假设 DEV 的 apollo-configservice 未绑定域名,地址是 1.1.1.1:8080,FAT 的 apollo-configservice 绑定了域名 apollo.fat.xxx.com,UAT 的 apollo-configservice 绑定了域名 apollo.uat.xxx.com,PRO 的 apollo-configservice 绑定了域名 apollo.xxx.com,那么可以如下修改各环境 meta service 服务地址,格式为
${env}.meta=http://${config-service-url:port},如果某个环境不需要,也可以直接删除对应的配置项,参考案例如下:
dev.meta=http://1.1.1.1:8080 fat.meta=http://apollo.fat.xxx.com uat.meta=http://apollo.uat.xxx.com pro.meta=http://apollo.xxx.com
如果采用旧版本配置方式,本小节配置方案如下:
#local.meta=http://localhost:8080 dev.meta=http://192.168.10.102:8080,http://192.168.10.104:8080 #fat.meta=http://fill-in-fat-meta-server:8080 #uat.meta=http://fill-in-uat-meta-server:8080 #lpt.meta=${lpt_meta} pro.meta=http://192.168.10.103:8080
除了通过
apollo-env.properties方式配置 meta service 以外,apollo 也支持在运行时指定 meta service(优先级比
apollo-env.properties高):
- 通过 Java System Property
${env}_meta
-
可以通过 Java 的 System Property
${env}_meta
来指定 - 如
java -Ddev_meta=http://config-service-url -jar xxx.jar
- 也可以通过程序指定,如
System.setProperty("dev_meta", "http://config-service-url");
- 通过操作系统的 System Environment
${ENV}_META
-
如
DEV_META=http://config-service-url
- 注意 key 为全大写,且中间是
_
分隔
启动
进入对应安装包的
script目录,执行
startup.sh文件。
我的启动顺序为:
- 192.168.10.101 启动 Portal
- 192.168.10.102 启动 ConfigService 再启动 AdminService
- 192.168.10.104 启动 ConfigService 再启动 AdminService
访问:192.168.10.102:8080 和 192.168.10.104:8080 看看 Eureka 以及各服务是否正常启动,如下:
最后,在页面发布配置信息的同时,可以通过查看日志的方式,查看高可用环境是否搭建成功,日志存放在
/opt/appId/xxx.log。
灰度发布
在一般情况下,升级服务器端应用,需要将应用源码或程序包上传到服务器,然后停止掉老版本服务,再启动新版本。但是这种简单的发布方式存在两个问题,一方面,在新版本升级过程中,服务是暂时中断的,另一方面,如果新版本有BUG,升级失败,回滚起来也非常麻烦,容易造成更长时间的服务不可用。
为了解决这些问题,人们研究出了多种发布策略,比如蓝绿部署、滚动发布、灰度发布等,Apollo 采用的是灰度发布的特性。
介绍
灰度发布也叫金丝雀发布,起源是,矿井工人发现,金丝雀对瓦斯气体很敏感,矿工会在下井之前,先放一只金丝雀到井中,如果金丝雀不叫了,就代表瓦斯浓度高。
在灰度发布开始后,先启动一个新版本应用,但是并不直接将流量切过来,而是测试人员对新版本进行线上测试,启动的这个新版本应用,就是我们的金丝雀。如果没有问题,那么可以将少量的用户流量导入到新版本上,然后再对新版本做运行状态观察,收集各种运行时数据,如果此时对新旧版本做各种数据对比,就是所谓的 A/B 测试。
当确认新版本运行良好后,再逐步将更多的流量导入到新版本上,在此期间,还可以不断地调整新旧两个版本的运行的服务器副本数量,以使得新版本能够承受越来越大的流量压力。直到将100%的流量都切换到新版本上,最后关闭剩下的老版本服务,完成灰度发布。如果在灰度发布过程中(灰度期)发现了新版本有问题,就应该立即将流量切回老版本上,这样,就会将负面影响控制在最小范围内。
实践
我们使用
apollo-demo中的
order-service和
order-service02两个实例来实践,
order-service在 Windows 端运行,
order-service02在 Linux 端运行。
配置文件
order-service 的配置文件。
server: port: 9090 # 端口 spring: application: name: order-service # 应用名称 # apollo 相关配置 app: id: order-service # 与 Apollo 配置中心中的 AppId 一致 apollo: meta: http://192.168.10.102:8080,http://192.168.10.104:8080 # Apollo 中的 Eureka 注册中心地址 #cluster: SHAOY # 指定 Apollo 集群,默认为 default,相同集群实例使用对应集群的配置 #cacheDir: # 配置缓存目录,网络不可用时任然可提供配置服务 bootstrap: enable: true # 启用 apollo env: DEV # 指定环境 # 自定义配置 name: order-service-dev mysql: host: localhost port: 3306 username: root password: root
order-service02 的配置文件。
server: port: 9091 # 端口 spring: application: name: order-service02 # 应用名称 # apollo 相关配置 app: id: order-service # 与 Apollo 配置中心中的 AppId 一致 apollo: meta: http://192.168.10.102:8080,http://192.168.10.104:8080 # Apollo 中的 Eureka 注册中心地址 #cluster: SHAOY # 指定 Apollo 集群,默认为 default,相同集群实例使用对应集群的配置 #cacheDir: # 配置缓存目录,网络不可用时任然可提供配置服务 bootstrap: enable: true # 启用 apollo env: DEV # 指定环境 # 自定义配置 name: order-service-dev mysql: host: localhost port: 3306 username: root password: root
最终效果如下:
创建灰度
点击右上角
灰度按钮,点击确定创建灰度。
新增灰度配置
新增灰度规则
灰度发布
测试
放弃灰度
确认放弃灰度以后会删除该灰度版本,并恢复为主版本的配置信息。
3550全量发布
全量发布将会把灰度版本的配置合并到主分支,并发布。
发布历史
可以通过
发布历史来查看所有的发布记录,比如主版本发布,主版本回滚,灰度操作、灰度规则等等。
至此 Apollo 配置中心所有的知识点就讲解结束了。
本文采用 知识共享「署名-非商业性使用-禁止演绎 4.0 国际」许可协议
。
大家可以通过 分类
查看更多关于 Spring Cloud
的文章。
🤗 您的
点赞和
转发是对我最大的支持。
📢 扫码关注
哈喽沃德先生「文档 + 视频」每篇文章都配有专门视频讲解,学习更轻松噢 ~
- SpringCloud系列:整合Apollo实现分布式配置中心(一)
- SpringCloud | Docker 学习系列 | Kubernetes 学习 将SpringCloud Config 配置中心部署到docker中并放入到Kubernetes中管理
- Spring Cloud 系列之 Config 配置中心(三)
- Spring Cloud 微服务开发:入门、进阶与源码剖析 —— 8.7 配置中心 Apollo
- Spring cloud系列二 Spring Cloud 配置中心的基本用法
- spring cloud 系列第8篇 —— config+bus 分布式配置中心与配置热刷新 (F版本)
- SpringCloud 整合 Apollo 配置中心
- 相较嫡系的SpringCloudConfig,为什么选择使用Apollo作为微服务的配置中心?
- Spring Cloud - - - 通过消息总线更新配置中心,导致client-config服务实例在注册中心全部丢失的问题
- 第六章:分布式配置中心(Spring Cloud Config)
- Spring系列学习之Spring Cloud Config微服务配置
- springcloud(六):配置中心git示例
- 第六篇: 分布式配置中心(Spring Cloud Config)
- 第七篇: 高可用的分布式配置中心(Spring Cloud Config)
- springcloud 入门 8 (config配置中心)
- spring cloud config server 配置中心
- Spring Cloud构建微服务架构:分布式配置中心【Dalston版】
- Spring Cloud -- 分布式配置中心
- 史上最简单的SpringCloud教程 | 第六篇: 分布式配置中心(Spring Cloud Config)