Configuration Center --Apollo small note

First, what is the configuration

Configuration is running, the ability to dynamically adjust behavior.

Configure the following attributes:

• Configuration is a read-only variables independent of the program

  • With a program under different configurations will have different behavior, and the configuration for the program is read-only, so the program can change their behavior by reading configuration, but can not change their own profiles.

• Configuring accompany applications throughout the life cycle

  • Application to initialize at startup by reading configuration, change their behavior depending on the configuration at runtime.

• How to load the configuration mode

  • Program internal hard code, this practice is anti-pattern, it is not recommended.

  • Profile.

  • Environment variables, configuration may be preset in the operating system environment variables, the reading program is running.

  • Startup parameters, can provide a one-time parameter when the program starts.

  • Based on the database, the variable configuration on the database, so the flexibility to adjust the configuration at runtime.

• Configuration management needs

  • Access control: the need to modify the configuration has an excellent access control, otherwise incorrect configuration can cause disaster.

  • Different environments, cluster configuration management: with a program often requires a different configuration in different environments (development, test, production), distinct clusters (such as different data centers), so the need to improve the environment, the cluster configuration management.

  • Component configuration management framework classes: CAT configured as the client.

Second, why you need to configure center

In the absence of the introduction of the configuration center, general research and development when there will be the following pain points:

• Scattered irregular configuration format

  • Some use format properties, some with yml format, with some xml format, as well as save DB, practices varied.

• Mainly local static configuration, configuration modifications trouble

  • In a distributed micro-service environment, service instances when a lot of time, time-consuming configuration changes.

• Easily lead to accidents

  • If you configure a test environment to the production environment.

• Configuring the lack of security audit and version control

  • To modify the configuration can not see who changed what, and modified time, in addition to the problem can not be rolled back in time.

Third, the configuration of the center of the core requirements

1. Deliverables and configure separate

   Traditional practices used in packaging when deployed, will play package different configurations for different environments, each packet contains the environment inside a specific configuration. Now recommended container is packaged and delivered micro mirror mode services, applications generally play a mirror, you can be deployed to different environments, so this configuration requires the delivery member and the separation member only make a delivery, and is immutable you can be deployed into any environment. All but the configuration environment can be collectively disposed at the center of the configuration, operation of the application may be configured to pull the dynamic center arranged according to their respective environments.

2. Abstract standardization

   Center shield configuration different formats should encapsulate the details of the configuration management and configuration, user configuration management autonomous, users typically need only two abstract attention and standardized interface to:

   • Configuration management interface UI, easy application developers to manage and publish configuration.

   • Encapsulated client API, and obtain configuration to facilitate application integration.

3. Multi-multi-cluster environment

   Micro-service applications they use a multi-environment deployment, the general standard of environment development / test / production, and some applications also require multi-cluster deployments, such as support for multi-room cross-version deployments. Configuration Center needed to support centralized management for multi-application environments and multi-cluster configuration.

4. High Availability

   Distribution center can not hang, otherwise it will affect a large area of ​​micro-services.

5. real-time

   Configuration updates need to be informed as soon as possible to the client, high real-time requirements of some configuration, such as blue-green standby switch configuration or deployment configuration, these capabilities require several seconds to switch configuration.

6. Control

   Configuration management needs, including:

   • After configuring the audit can be traced back, you need to log changes people, content and modify events, easy problems.

   • Configuration version control, every change requires versioning, problems can be promptly rolled back to the previous version.

   • Configuring access control, configuration changes need to publish authentication and authorization.

   • Gray publish, you can let take effect a few instances when advertising, make sure that no problem can expand the range of applications.

Fourth, what is Apollo

Apollo is a research and development department Ctrip framework open source configuration management center that centralized management applications in different environments, different cluster configuration, the configuration changes can be pushed to real-time application side, and have standardized permissions, process control and other features.

Apollo the following features:

• Unified management of different environments, different cluster configuration.

  • Apollo provides centralized different environments, different clusters, configuration management different name (namespace) space of a unified interface, and deploy the same code in different clusters, can have different configurations.

• Configuration changes with immediate effect (heat release)

• Release management

• Gray release

• Client configuration information monitoring

  • You can easily see on the screen which is used in the configuration example.

• Java and .Net provide native client

• It provides an open platform API

• Simple deployment

You can see, Apollo features almost meet the core needs of distribution center above.

Fifth, the basic model of Apollo

1. Users can now modify the UI interface / release configuration.

2. Apollo configuration update information distribution center will be pushed to the client Apollo.

3. The client then pull the latest configuration from Apollo distribution center, after updating the local configuration, notification to the application.

Six, Apollo client design

 

1, Apollo client implementation principle

1. The client and server will maintain a long connection, so that the first time to get a push configuration updates.

2. The client will be timed from the latest configuration Apollo distribution center pull application server, but the client timed pull will be reported to the local version, the default once every 5 minutes to pull, you can specify apollo.refreshInterval by running to cover in minutes.

3. After the client obtains from the Apollo configuration center server to the latest configuration of the application, it will be kept in memory.

4. The client will pull from the server to configure a local file system cache to ensure that in the event of network failure or service is not available, depending on the configuration from the local recovery, but also to achieve a certain degree of high availability.

5. The application gets from the client to configure the offense, subscribe to configure the update notification.

2, implement push configuration updates

Apollo above mentioned client and server to maintain a long connection, thereby updating the first time to obtain a push configuration, connected by long actually Http Long Polling implemented:

• Http request initiated by the client to the server

• Server connection for 60s

  • If there is a configuration change in the client's interest in the 60s, the request will return immediately, and inform the client has a namespace information on configuration changes, the client will accordingly pull the latest configuration of the namespace.

  • If no change in the client's interest in the 60s, http status code 304 is returned to the client.

In the server, with async servlet (Spring DeferredResult) Http Long Polling request for service.

Seven, Apollo overall design

 

Before stroke clear thinking, the first of which modules to know:

Main modules:

1. ConfigService

   • Get Interface provides configuration

   • Push interfaces provide configuration

   • Apollo serve clients

2. AdminService

   • Provide configuration management interface

   • 提供配置修改发布接口

   • 服务于管理界面Portal

3. Client

   • 为应用获取配置，支持实时更新

   • 通过MetaServer获取ConfigService的服务列表

   • 使用客户端软负载SLB方式调用ConfigService

4. Portal

   • 配置管理页面

   • 通过MetaServer获取AdminService的服务列表

   • 使用客户端软负载SLB方式调用AdminService

辅助模块：

1. Eureka

   • 用于服务发现和注册

   • Config/AdminService注册实例并定期报心跳

   • 和ConfigService一起部署

2. MetaServer

   • Portal通过域名访问MetaServer获取AdminService的地址列表

   • Client通过域名访问MetaServer获取ConfigService的地址列表

   • 相当于Eureka Proxy

   • 和ConfigService一起部署

3. NginxLB

   • 和域名系统配合，协助Portal访问MetaServer获取AdminService的地址列表

   • 和域名系统配合，协助Client访问MetaServer获取ConfigService的地址列表

   • 和域名系统配置，协助用户访问Portal进行配置管理。

1、简化架构A

 

假设没有分布式微服务的服务发现，那么：

1. Portal会调用AdminService进行配置管理和发布

2. ConfigService和Client保持长连接，ConfigService服务于Client进行配置获取，ConfigService和Client通过一种推拉结合的方式，实现配置实时更新 的同时，保证配置更新不丢失。

3. ConfigService和AdminService共享ConfigDB，ConfigDB中存放项目在某个环境的配置信息，而且这三者在每个配置环境（DEV/FAT/UAT/PRO)中都要部署一份。

4. Protal有个独立的PortalDB，存放用户权限、项目和配置的元数据信息。Portal只需部署一份，它可以管理多套环境。

2、简化架构B

 

因为Client要找ConfigService需要地址列表，Portal找到AdminService也需要地址列表，这时候就需要服务发现了。

1. Config/AdminService启动后都会注册到Eureka服务注册中心，并定期发送保持心跳。

2. Eureka采用集群方式部署，使用分布式 一致性协议保证每个势力的状态最终一致。

3. Client和Portal可以通过Eureka发现ConfigService和AdminService的地址列表。

3、简化结构C

 

因为携程需要跟自家的.Net的系统兼容，所以引入了MetaServer服务，这相当于是代理Proxy，将Eureka的服务发现接口以更简单明确的HTTP接口的形式暴露出来。

但是MetaServer本身也是无状态以集群方式部署的，那么Client/Protal该如何发现MetaServer呢？传统的方式是借助硬件（可以在其中指定MetaServer的位置）或者是软件负载均衡器。

4、完全结构D

 

使用NginxLB（也称Software Load Balancer），由运维为MetaServer集群配置一个域名，指向NginxLB集群，NginxLB再对MetaServer进行负载均衡和流量转发。Client/Portal通过域名+NginxLB间接访问MetaServer集群。

 

---

这里踩个坑，因为一套Portal就可以集中管理多套环境（DEV/FAT/UAT/PRO）中的配置，所以当切换环境的时候，需要注意到.properties(.yml)等配置文件中（SpringBoot）是否有明确标记处需要取出哪些namespace的配置，否则Client将会拉取不了配置中心的配置到本地。

 

参考：

微服务架构 为什么需要配置中心
携程 Apollo 配置中心架构深度剖析
Apollo配置中心介绍