# apollo **Repository Path**: wireless3/apollo ## Basic Information - **Project Name**: apollo - **Description**: 携程框架研发团队强力打造的配置中心,微服务轻量级。spring-boot(spring-mvc spring-security spring-data-jpa spring-boot-test) + eureka + mockito + AngularJS. spring最新技术体系完美诠释 - **Primary Language**: Unknown - **License**: Apache-2.0 - **Default Branch**: master - **Homepage**: None - **GVP Project**: No ## Statistics - **Stars**: 0 - **Forks**: 636 - **Created**: 2016-09-12 - **Last Updated**: 2020-12-19 ## Categories & Tags **Categories**: Uncategorized **Tags**: None ## README ## 基础核心功能 ### 配置类型 * properties * file（xml，json, yml, yaml） #### properties * portal * 支持单条配置项编辑 * 支持以file级别编辑（迁移老项目properties，直接copy） * 可以查看每一个配置项的更改历史（追责，查问题等） * 配置需要发布才能生效（类似于code发布），发布时可以查看所有的配置修改 * 记录发布历史 * 配置发布后，所有的的client在1ms内，更新配置并回调监听事件 * client * 通过 apollo-client API获取配置项 * client api强制用户传入default值，作为最后一层保险（config cache layer） 1. client memory cache 2. client file cache 3. config server file cache 4. db * 通过http restful api获取properties文件 * client可以监听每一个key的change事件 ### file * protal * 文本直接编辑 * 发布时，显示 diff * 记录修改、发布历史 * client * 以String返回file * 可以监听change事件 ## 高级进阶功能 以上功能是配置中心的核心功能，后台修改配置及时通知到客户端，以及客户端可以监听change事件。如果只支持这些，那么就没必要拿出来卖了~ ###高级功能1 --- 配置回滚 配置只有发布后才会生效，有发布当然有回滚啦，虽然功能不大，但是实用价值明显。在发布历史页面可以明确看到那一份是最新配置，哪些是回滚作废了配置。 ### 高级功能2 --- 配置分集群 同一份代码，同一个包在多个DC，或者在不同的cluster配置可能不一致。比如主DC的机器性能更好，可以提供更强大的服务，所以设置的路由优先级高。 ### 高级功能3 --- 配置有继承关系 场景：业务依赖某公共组件，公共组件配置默认值，业务方可以自定义配置且覆盖公共配置。但是不支持多层继承，最多两层。因为考虑多层继承会导致模型复杂度大大提升，犯错的几率也相应的提高。 配置有继承关系，虽然简单，但可以有无限的想象空间，应用空间。 ### 高级功能4 --- 配置可以分组 一个app下面可以有多种类型的配置，配置分组便于管理和维护。一个组是一个namespace ### 高级功能5 --- 配置支持file 是不是很多老项目的配置是xml？完美支持~ ### 高级功能6 --- 权限控制 所有的项目都有权限，现有的权限包括，namespace级别的编辑，发布权。项目级别的管理权限，包括创建cluster，创建namespace，分配namespace权限等。以及：namespace一次发布过程中编辑和发布不能为同一个人，强制增加review过程。我们的权限有何特殊之处呢？权限模型非常易于扩展~ ### 高级功能7 --- http restful api 我们内部client端已支持java和.net版本，但是还有很多其他语言未支持。同时，在推广过程中发现很多团队自己搞过简易版的“配置中心”，不想接入client，而是为其提供restful，便于迁移。 ###高级功能8 --- open api 传统的配置中心，client端只有查询配置的功能。携程内部推广的过程中用户有以下两点需求： 1. 用户的用户是运营同学，不应该让他们直接使用配置中心的后台，而是用户自己封装业务场景，然后调用我们的存储配置api 2. 我们的portal支持绝大部分使用场景，但是有些部门的配置需要做比如校验、预处理等操作 针对第二种场景，如果我们为其开发校验、预处理功能，那么我们的portal将会被污染且不可控。这部分功能应由用户自己去开发，然后调用我们的open api。 开放那些接口以及做到那种程度的auth，我们都经过深入的考虑。 ###高级功能9 --- 可以查看配置实例信息 portal能看到配置信息，但是对于client 实例一无所知？那些应用，哪些机器用了我的配置？每台机器都用了哪份配置？某台机器是不是用了最新的配置？所有信息一览无余~ ###高级功能10 --- 配置灰度发布 | ABTest 场景：调整某个配置参数，先看一下某台机器的效果，而不是全部的机器。跟应用的灰度发布场景一致 ## 附:portal项目主页(更多设计以及portal交互请查看附件)