本篇文章为系列文章,未读前几集的同学请猛戳这里:

本篇文章讲解 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.zipapollo-adminservice-x.x.x-github.zip 上传至该机器,解压以后都配置 102 机器的数据库,我们搭建一个 DEV 的高可用环境。

配置数据库

  1. 将 ConfigService 和 AdminService 上传至 192.168.10.104
  2. 解压
  3. 打开config目录下的application-github.properties文件
  4. 填写正确的 ApolloConfigDB 数据库连接串信息,注意用户名和密码后面不要有空格!
  5. 修改完的效果如下:
# 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.zipconfig目录下的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高):

  1. 通过 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");
  2. 通过操作系统的 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-serviceorder-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

最终效果如下:

创建灰度

点击右上角灰度按钮,点击确定创建灰度。

新增灰度配置

新增灰度规则

灰度发布

测试

放弃灰度

确认放弃灰度以后会删除该灰度版本,并恢复为主版本的配置信息。

全量发布

全量发布将会把灰度版本的配置合并到主分支,并发布。

发布历史

可以通过发布历史来查看所有的发布记录,比如主版本发布,主版本回滚,灰度操作、灰度规则等等。

至此 Apollo 配置中心所有的知识点就讲解结束了。

本文采用 知识共享「署名-非商业性使用-禁止演绎 4.0 国际」许可协议

大家可以通过 分类 查看更多关于 Spring Cloud 的文章。

Spring Cloud 系列之 Apollo 配置中心(四)的更多相关文章

  1. Spring Cloud 系列之 Apollo 配置中心(二)

    本篇文章为系列文章,未读第一集的同学请猛戳这里:Spring Cloud 系列之 Apollo 配置中心(一) 本篇文章讲解 Apollo 部门管理.用户管理.配置管理.集群管理. 点击链接观看:Ap ...

  2. Spring Cloud 系列之 Apollo 配置中心(三)

    本篇文章为系列文章,未读前几集的同学请猛戳这里: Spring Cloud 系列之 Apollo 配置中心(一) Spring Cloud 系列之 Apollo 配置中心(二) 本篇文章讲解 Apol ...

  3. Spring Cloud 系列之 Apollo 配置中心(一)

    背景 随着程序功能的日益复杂,程序的配置日益增多:各种功能的开关.参数的配置.服务器的地址等等. 对程序配置的期望值也越来越高:配置修改后实时生效,灰度发布,分环境.分集群管理配置,完善的权限.审核机 ...

  4. Spring Cloud 系列之 Config 配置中心(二)

    本篇文章为系列文章,未读第一集的同学请猛戳这里:Spring Cloud 系列之 Config 配置中心(一) 本篇文章讲解 Config 如何实现配置中心自动刷新. 配置中心自动刷新 点击链接观看: ...

  5. Spring Cloud 系列之 Config 配置中心(三)

    本篇文章为系列文章,未读前几集的同学请猛戳这里: Spring Cloud 系列之 Config 配置中心(一) Spring Cloud 系列之 Config 配置中心(二) 本篇文章讲解 Conf ...

  6. Spring Cloud 系列之 Consul 配置中心

    前面我们已经学习过 Spring Cloud Config 了: Spring Cloud 系列之 Config 配置中心(一) Spring Cloud 系列之 Config 配置中心(二) Spr ...

  7. Spring Cloud 系列之 Config 配置中心(一)

    服务配置现状 配置文件是我们再熟悉不过的,在微服务系统中,每个微服务不仅仅只有代码,还需要连接其他资源,例如数据库的配置或功能性的开关 MySQL.Redis .Security 等相关的配置.除了项 ...

  8. Spring Cloud 入门教程 - 搭建配置中心服务

    简介 Spring Cloud 提供了一个部署微服务的平台,包括了微服务中常见的组件:配置中心服务, API网关,断路器,服务注册与发现,分布式追溯,OAuth2,消费者驱动合约等.我们不必先知道每个 ...

  9. Spring Boot + Spring Cloud 实现权限管理系统 配置中心(Config、Bus)

    技术背景 如今微服务架构盛行,在分布式系统中,项目日益庞大,子项目日益增多,每个项目都散落着各种配置文件,且随着服务的增加而不断增多.此时,往往某一个基础服务信息变更,都会导致一系列服务的更新和重启, ...

随机推荐

  1. 【转】46个Linux常用命令

    转:https://www.cnblogs.com/passzhang/p/8552757.html 问题一: 绝对路径用什么符号表示?当前目录.上层目录用什么表示?主目录用什么表示? 切换目录用什么 ...

  2. PAT 1006 Sign In and Sign Out (25分) 字符串比较

    题目 At the beginning of every day, the first person who signs in the computer room will unlock the do ...

  3. 「雕爷学编程」Arduino动手做(37)——MQ-3酒精传感器

    37款传感器与模块的提法,在网络上广泛流传,其实Arduino能够兼容的传感器模块肯定是不止37种的.鉴于本人手头积累了一些传感器和模块,依照实践出真知(一定要动手做)的理念,以学习和交流为目的,这里 ...

  4. 前后端分离产生的跨域问题的解决方案之--jsonp、nginx代理、设置头信息等

    前言 在前后端没有分离的时候,前端开发要么是写静态页面,数据渲染后端来做,要么就是前端的页面和后端的代码刚开始的时候就合并在一起,每次后端代码更新了之后,前端也要更新一下代码,然后重启一下服务,还是比 ...

  5. Paxos made simple 翻译尝试

    [这篇论文我翻译下来,首先感觉还是不好懂,很多地方结论的得出不够清楚,需要读者自己思考其中的原因.要理解Paxos算法,个人建议先搜索下介绍算法的中文文章,大致了解下Paxos算法要做什么,然后就再读 ...

  6. .Net基础之5——复杂数据类型

    (1)复习 1.变量 int  double   string   char   bool    decimal 变量的使用规则:先声明再赋值最后使用 2.Camo      Pascal 3.运算符 ...

  7. Spring全家桶一一SpringBoot与Mybatis

    Spring全家桶系列一一SpringBoot与Mybatis结合 本文授权"Java知音"独家发布. Mybatis 是一个持久层ORM框架,负责Java与数据库数据交互,也可以 ...

  8. sqoop-介绍及安装

    1.sqoop概述 sqoop是Apache旗下一款hadoop和关系数据库服务器之间传送数据的工具: 核心的功能: 导入,迁入(从关系型数据库-->hdfs hive hbase) 导出,迁出 ...

  9. HTTP 规范中的那些暗坑

    HTTP 协议可以说是开发者最熟悉的一个网络协议,「简单易懂」和「易于扩展」两个特点让它成为应用最广泛的应用层协议. 虽然有诸多的优点,但是在协议定义时因为诸多的博弈和限制,还是隐藏了不少暗坑,让人一 ...

  10. 附件2:async/await

    在实际开发中总会遇到许多异步的问题,最常见的场景便是接口请求之后一定要等一段时间才能得到结果,如果遇到多个接口前后依赖,那么问题就变得复杂.大家都一直在尝试使用更好的方案来解决这些问题.最开始只能利用 ...