微信公众号：千里行走

头条技术号：实战架构

交流邮箱：hpy253215039@163.com

欢迎关注，一起交流，学习，提高。

本文主要讲述：

apollo配置中心生产级实践，并提供生产级配置。

(1).demo演示地址

(2).概述

(3).apollo容器化的架构拓扑

(4).apollo容器化资源配比

4.1.apollo-configservice的pod资源配置依据

4.2.apollo-adminservice的pod资源配置依据

4.3.apollo-portal的pod资源配置依据

(5).生产级实践

5.1.生产级配置

5.2.jdk选择

5.3.注意事项

(6).apollo流程规划

(7).apollo配置规划

(8).笔者容器化相关实战github

8.1.笔者生产环境的apollo容器化的配置

8.2.笔者生产实践中使用/制作的jdk官方镜像

8.3.本系列文章所涉及的相关资源的github备份

8.4.笔者生产实践中的openresty高性能配置

(1).demo演示地址

注意，如果访问8080提示403，有可能是你的IP触发了笔者openresty的防封逻辑，请关注笔者微信公众号后发消息给笔者，将你的IP提供给笔者进行配置。

目前可开放的演示地址：

apollo(容器化):

http://dev.apollo-portal.future.com:8080/signin

User: guest

Password: guest

grafana(容器化):

http://monitor-app.future.com:8080/

User: guest

Password: guest

需要配置host:

39.98.43.48 dev.apollo-portal.future.com

39.98.43.48 monitor-app.future.com

(2).概述

apollo配置中心本身非常简单，但是从非容器化向容器化过渡时，会遇到一些实际问题，要求在工程拓扑上兼容4种版本的代码：

原因在于apollo配置中心的url需要hard code到自研框架中；非容器化时，我们需要配置多个url保证apollo的高可用，但是容器化后只需要一个url(k8s-servic负载均衡)就可以了。

适配这些情况改代码的周期和风险太大，不可接受，通过在k8s中建立不同的service负载均衡的域名(与非容器化的域名对应)这种方式可以0成本的解决过渡阶段的这些问题。

(3).apollo容器化的架构拓扑

如下图，其实也非常简单，通过在k8s中建立不同的负载均衡(service)，同时兼容两类配置中心的url。

最终过渡阶段结束后，最终形态是下图中绿色部分。

高清图片位于：

https://github.com/hepyu/kubernetes-microsvc-product-practice/blob/master/images/%E9%98%BF%E9%87%8C%E4%BA%91%26kubernetes%26%E5%BE%AE%E6%9C%8D%E5%8A%A1%E7%94%9F%E4%BA%A7%E5%AE%9E%E8%B7%B5-1%EF%BC%9Aapollo%E6%9E%B6%E6%9E%84-1.jpg

(4).apollo容器化资源配比

cpu资源的request, limit采用1:10，memory资源的request,limit采用1:2。

cpu: request-0.1core, limit-1core

memory: request-1G, limit-2G

这个配比是通过观察K8s-pod的prometheus监控后确认的，apollo正常运行时的cpu和memory占用很低，分别是<0.1core，500MB。

但是limit的配置必须有富余，因为在jvm启动加载时，对cpu和memory的占用是远超正常运行时的资源占用的，设置小了是启动不了的，JVM一直GC，超过yaml定义的最小时间后启动失败，然后重试启动N次(可配置)。

下附实际依据：

4.1.apollo-configservice的pod资源配置依据

cpu: request-0.1core, limit-1core

memory: request-1G, limit-2G

wayne的项目资源限制:

4.2.apollo-adminservice的pod资源配置依据

cpu: request-0.1core, limit-1core

memory: request-1G, limit-2G

wayne的项目资源限制:

4.3.apollo-portal的pod资源配置依据

cpu: request-0.1core, limit-1core

memory: request-1G, limit-2G

(5).生产级实践

5.1.生产级配置

笔者github地址提供了一个生产级配置，可以直接用于生产，包含使用/意图/笔者相关技术文章：

https://github.com/hepyu/k8s-app-config/tree/master/product/standard/apollo-pro

5.2.jdk选择

apollo官方选择的是openjdk，笔者依然沿用；虽然也考虑过换成oracle-jdk，但是考虑到这样做使得制作流程更加复杂化，比如apollo升级了：

需要结合官方的apollo镜像和我们自己的oracle-jdk-image再做一遍镜像，很麻烦，至少也需要check一遍；

openjdk性能也足够，更何况只是满足apollo这类qps极低的服务，一点问题没有；

同时笔者未来也有在线上逐步引入openjdk与alijdk的打算，正好可以先行尝试；

从极致性价比角度选择，依从apollo官方默认的openjdk，好处多多。

5.3.注意事项

apollo-portal开启多副本要注意配置session亲和性

config/admin/portal的负载均衡都需要配置：sessionAffinity: ClientIP；

如果你还是用的ingress代理apollo-portal，那么ingress也需要配置亲和性保证session的正确传递：

nginx.ingress.kubernetes.io/affinity: cookie

ingress的亲和性配置参见文件：https://github.com/hepyu/k8s-app-config/blob/master/product/standard/apollo-pro/apollo-portal/apollo-portal-ingress.yaml

如果不配置亲和性，apollo-portal开启多副本后将出现无法登陆的现象。

(6).apollo流程规划

apollo-portal原生支持4个环境，但是我们为了规避风险，4个环境的apollo-portal是分开的，环境之间不能同步配置；

同时我们规定了apollo的使用流程，下图为流程意会图；

但实际使用上是大大简化了，因为我们的团队规模不需要如此正规的流程；

高清图片位于：

https://github.com/hepyu/kubernetes-microsvc-product-practice/blob/master/images/apollo%E6%B5%81%E7%A8%8B%E8%A7%84%E5%88%92.jpg

(7).apollo配置规划

正如官方所述，apollo并没有在配置规划上做硬性要求，但是实际生产中需要进行规划，否则会非常混乱，带来潜在风险。

我们规定：

1.项目名称必须是a-b-c的形式存在，以-分隔；

2.资源型配置如redis,rds,rpc等必须放置到公共项目里，资源型配置的项目名称必须以a.b.c的形式存在，以.分隔；

3.不论是资源型配置还是实际服务，都必须归纳到各自部门，且每个部门有一个同学是这个部门的最高权限；部门共用的配置有superAdmin管理；

4.资源型配置必须以public namespace的形式存在，使用关联的方式引用；

5.项目的private namespace只能有一个，就是原生自带的application；

下图是一个配置规划意会图，基本上是按照这个规划应用在生产实践中：

高清图片位于：

https://github.com/hepyu/kubernetes-microsvc-product-practice/blob/master/images/apollo%E9%85%8D%E7%BD%AE%E8%A7%84%E5%88%92.jpg

demo规范样例：

(8).笔者容器化相关实战github

8.1.笔者生产环境的apollo容器化的配置

可以直接用于生产环境：

https://github.com/hepyu/k8s-app-config/tree/master/product/standard/apollo-pro

8.2.笔者生产实践中使用/制作的jdk官方镜像

https://github.com/hepyu/oraclejdk-docker-image

8.3.本系列文章所涉及的相关资源的github备份

https://github.com/hepyu/kubernetes-microsvc-product-practice

8.4.笔者生产实践中的openresty高性能配置

https://github.com/hepyu/openrestry