• home > tools > webServer > apache >

    Apollo配置中心介绍

    Author:zhoulujun Date:

    Apollo(阿波罗)是一款可靠的分布式配置管理中心,诞生于携程框架研发部,能够集中化管理应用不同环境、不同集群的配置,配置修改后能够实

    Apollo(阿波罗)是一款可靠的分布式配置管理中心,诞生于携程框架研发部,能够集中化管理应用不同环境、不同集群的配置,配置修改后能够实时推送到应用端,并且具备规范的权限、流程治理等特性,适用于微服务配置管理场景

    官网: https://github.com/apolloconfig/apollo/wiki/Apollo配置中心介绍


    为什么选用Apollo

    Apollo支持热发布,也即不需要重启进程实现配置更改,可以在配置更改后,由客户端实时接收。用户在Apollo修改完配置并发布后,客户端能实时(1秒)接收到最新的配置,并通知到应用程序

    Apollo客户端会把从服务端获取到的配置在本地文件系统缓存一份,用于在遇到服务不可用,或网络不通的时候,依然能从本地恢复配置,不影响应用正常运行。

    • Spring Cloud Config,2014年9月开源,Spring Cloud 生态组件,可以和Spring Cloud体系无缝整合。

    • Apollo, 2016年5月,携程开源的配置管理中心,

    • Nacos,2018年6月,阿里开源的配置中心,也可以做DNS和RPC的服务发现。

    以上三个,Apollo可以直接在控制台上点灰度发布指定发布机器的IP,接着再全量发布,做得比较体系化。

    Apollo支持灰度发布,可配置仅对部分实例生效,测试无误后推送到所有实例中去。

    Apollo的回滚机制是非常好用的,所有的配置发布都有版本概念,从而可以麻利地将发布到客户端的配置回滚到上一个已发布版本,也就是说客户端读取到的配置会恢复到上一个版本,但页面上编辑状态的配置是不会回滚的,从而开发可以在修复配置后重新发布。

    Apollo的权限管理,通过项目的维度来对配置进行权限管理,一个项目的owner可以授权给其他用户配置的修改发布权限。

    Apollo自身提供了比较完善的配置管理界面,支持多种环境的配置管理、权限、流程治理等。也可以方便的看到配置在被哪些实例所使用。应用和配置的管理都有完善的权限管理机制,还具有发布审核、操作审计的功能,可以方便查看日志并追踪问题。除了提供Java和.Net的原生客户端外也提供了Http接口方便其他应用使用。

    Apollo已经支持了多种语言,其他不支持的语言,Apollo的接入成本相对较低。

    本地缓存,Apollo客户端会把从服务端获取到的配置在本地文件系统缓存一份,用于在遇到服务不可用,或网络不通的时候,依然能从本地恢复配置,不影响应用正常运行。

    v2-624a3338fb512ac77c5d22b14796d743_720w.webp

    ……………………

    实在太香……

    配置维度及说明

    支持4个维度管理Key-Value格式的配置:

    1. application (应用)

    2. environment (环境)

    3. cluster (集群)

    4. namespace (命名空间)

    namespace

    Namespace是配置项的集合,类似于一个配置文件的概念

    它的获取权限分为两种:private和public。类型有三种:私有类型、公共类型、关联类型(继承类型)。

    1. private权限的Namespace,只能被所属的应用获取到。一个应用尝试获取其它应用private的Namespace,Apollo会报“404”异常。私有类型的Namespace具有private权限。

    2. public权限的Namespace,能被任何应用获取。公共类型的Namespace具有public权限。公共类型的Namespace相当于游离于应用之外的配置,且通过Namespace的名称去标识公共Namespace,所以公共的Namespace的名称必须全局唯一。

    3. 关联类型又可称为继承类型,关联类型具有private权限。关联类型的Namespace继承于公共类型的Namespace,用于覆盖公共Namespace的某些配置。



    吐槽apollo

    apollo 的架构太重了。

    首先,它把配置中心拆成了 config service、admin service、portal,这一点我倒是可以接受。我不能接受的是,apollo 为了实现客户端到 config service 的负载均衡而引入了过多的组件。

    如图,增加了 SLB、meta server、eureka 等组件,这个我真的觉得没必要,直接使用 SLB 来做负载均衡就行。

    v2-a27e356ae9de7a7c2d1a585576a37557_r.jpg

    但官方说之所以这么设计是为了避免客户端和 config service 之间的长连接给 SLB 增加过多的负担,这么说的话,,也不无道理。

    不过,有一点比较好的就是,apollo 把 config service、eureka 和 meta server 打包在一起部署。

    我们来看看 nacos,首先,它没有将配置中心拆成很多个服务,其次,它的负载均衡方案也比较简单,一个 SLB 就可以搞定。要知道 nacos 同样也维护着与客户端的长连接。

    v2-60c0a8a522482d1128dcf04794fc7954_720w.webp

    所以,中小型系统我会更倾向于使用 nacos





    参考文章:

    千字Apollo配置中心的总结,让配置“智能”起来 https://zhuanlan.zhihu.com/p/267162370

    https://www.zhihu.com/question/469044655/answer/3240819243




    转载本站文章《Apollo配置中心介绍》,
    请注明出处:https://www.zhoulujun.cn/html/tools/webServer/apache/9268.html