Why a distributed configuration center?

In a microservice architecture, the number of services depends on the size of the project, but the number must be at least a dozen or twenty. These microservices sometimes share some configurations, and when a configuration is modified, all the services must be changed together. The tasks are numerous and error prone.

The distributed distribution center manages the configurations of multiple services in one place and modifies them in a unified manner. The modification takes effect in real time, saving time and reducing the error rate.

This article explores the next configuration management software offering: Apollo.

Introduction of Apollo,

About Apollo’s introduction, somebody else’s own official website is the most authoritative:

Apollo is a distributed configuration center developed by the Framework department of Ctrip. It can centrally manage configurations in different environments and clusters, and push configurations to applications in real time after modification. It has standardized permissions and process governance features, and is suitable for micro-service configuration management scenarios.

The server is developed based on Spring Boot and Spring Cloud, and can run directly after packaging, without additional installation of Application containers such as Tomcat.

The Java client does not depend on any framework, can run in all Java runtime environments, and has good support for the Spring/Spring Boot environment.

Installation and Deployment Guide

The official documentation for Apollo is excellent. For installation and deployment, you can refer directly to:

Single deployment

Distributed deployment

GitHub address of the project

Apollo basic model

This diagram depicts Apollo’s basic model, which means:

  1. Users modify and publish configuration items in the configuration center.
  2. Configuration center notifies Apollo client of configuration updates;
  3. The Apollo client pulls the latest configuration from the configuration center, updates the local configuration, and notifies the application

Apollo Core Module

Let’s take a look at an architecture diagram from Apollo:

A little knowledge of microservices architecture is enough to extract a few core modules from this diagram:

  • Config Service
  • Admin Service
  • Eureka cluster
  • Meta Server
  • Client
  • Portal

After picking out these modules, let’s briefly analyze its architecture model:

  • EurekaIt’s the Microservices registry,Config Service 和 Admin Service 向 EurekaThe registration service
  • ClientthroughMeta Server 从 EurekaTo obtainConfig ServiceService list
  • PortalthroughMeta ServerGet it from the registryAdmin ServiceService list
  • Client 和 PortalBoth sides go throughSoftware Load BalancerLoad Balancing

The above simple analysis is a brief analysis based on this architecture diagram. Now let’s take a look at what the functions of each module are.

Config Service

The Service object of Config Service is Apoll client. The Apollo client obtains configuration items from the interface provided by Config Service.

When the configuration item is updated, the Config Service is responsible for pushing a message to the Apollo client.

TIP:

  • The Config Service push message adopts the asynchronous mode (Spring DeferredResult), which greatly increases the number of long connections
  • The default configuration of built-in Tomcat is up to 10000 connections (adjustable). A 4C8G VIRTUAL machine can support 10000 connections, so it meets the requirement (an application instance will only initiate one long connection).

Admin Service

The Admin Service provides interfaces for managing configurations, including modifying and publishing configurations. The Service object is the Portal.

Meta Server

Meta Server is a Eureka Proxy:

  • PortalAccess by domain nameMeta ServerTo obtainAdmin ServiceAddress list of
  • ClientAccess by domain nameMeta ServerTo obtainConfig ServiceAddress list of

Meta Server and Config Service are deployed in the same JVM.

Eureka

Eureka is an important component of Spring Cloud and is responsible for registration discovery of services.

The Config Service and Admin Service register services with Eureka and keep the heartbeat.

Eureka is also deployed in the same JVM as Config Service.

Portal

You can manage configurations visually on the Portal.

  • Obtain the Admin Service Service list (IP+Port) from Meta ServerIP+PortAccess the service
  • Perform load balance and retry on the Portal

Client

Client is a Client program provided by Apollo. It provides functions such as configuration acquisition and real-time update for applications.

  • Obtain the Config Service Service list (IP+Port) from Meta Server and access the Service through IP+Port
  • Perform load balance and retry on the Client

Apollo Core Concepts

Application of application

Applications are services, and Apollo clients need to know the identity of each application at run time,

Each application needs to have a unique identity — appId. There are several ways to specify the appId. The SpringBoot project recommends configuring the appId directly in application.

Environment is the environment

The environment is commonly referred to as the development, test, pre-release, production and other environments. The Apollo client needs to know not only the identity of the application, but also the environment in which the application is operating, because configurations are different in different environments.

In distributed deployment, determine the deployment environment and deployment mode in advance.

There are also several ways to specify a project’s environment, which is specified by default by reading the configuration on the machine (the env attribute in server.properties),

It is also supported by Java System Property.

Apollo currently supports the following environments:

  • DEV Development environment
  • FAT test environment, equivalent to alpha (functional test)
  • UAT integration environment, equivalent to beta environment (regression testing)
  • PRO production environment

Of course, you can also use the source code

Com. Ctrip. Framework. Apollo. Core. Enums. Env and com. The ctrip. Framework. Apollo. Core. Enums. EnvUtils to customize the environment.

Cluster cluster

For example, the application instances in the Shanghai equipment room are grouped into one cluster and the application instances in the Beijing equipment room are grouped into another cluster by data center.

The same configuration can have different values for different clusters, for example, the ZooKeeper address.

The cluster is specified by default by reading the configuration on the machine (the IDC Property in server.properties), although it can also be specified by Java System Property at runtime.

Namespace namespace

  • Grouping of different configurations under an application. A namespace can be simply likened to a file. Different types of configurations are stored in different files, such as database configuration files, RPC configuration files, and application configuration files
  • Applications can directly read the configuration namespace of common components, such as DAL and RPC
  • An application can also modify the configuration of a common component by inheriting its configuration namespace, such as the DAL’s initial database connection count

In actual combat

Apollo configuration center setup

Hosting plan

I built a simplified Apollo configuration center with three CentOS VMS:

The host name The IP address Deployment project note
apollo-node-111 192.168.242.111 MySQL, Admin Service (DEV), Config Service (DEV)
apollo-node-112 192.168.242.112 Portal, Admin Service, and Config Service High availability for Portal is not available
apollo-node-113 192.168.242.113 Admin Service, Config Service

The deployment of

  1. On the Apollo-Node-111 machine

    The preparatory work

    According to the host planning described earlier, you need to deploy the database and DEV environment on the Apollo-Node-111 machine.

    Modify the corresponding script:

    Modify the admin service configuration file:

    vim /usr/local/apollo/apollo-adminservice/config/application-github.properties

# File contents
# DataSourceSpring. The datasource. Url = JDBC: mysql: / / 192.168.242.111:3306 / ApolloConfigDBTest? characterEncoding=utf8 spring.datasource.username = root spring.datasource.password = 123456Copy the code

    Modify the config service configuration file:

    vim /usr/local/apollo/apollo-configservice/config/application-github.properties

# File contents
# DataSourceSpring. The datasource. Url = JDBC: mysql: / / 192.168.242.111:3306 / ApolloConfigDBTest? characterEncoding=utf8 spring.datasource.username = root spring.datasource.password = 123456Copy the code

    • Import ApolloPortalDB and ApolloConfigDB databases, and copy a ApolloConfigDBTest library as the database for the DEV environment (modify the SQL script yourself).

      # into the MySQL client MySQL > source/usr/local/Apollo/SQL/apolloportaldb SQL; mysql> source /usr/local/apollo/sql/apolloconfigdb.sql; mysql> source /usr/local/apollo/sql/apolloconfigdbtest.sql;Copy the code

    • Start the Config Service and execute the script:

      /usr/local/apollo/apollo-configservice/scripts/startup.sh
Copy the code

    • Start the Admin Service and run the following script:

      /usr/local/apollo/apollo-adminservice/scripts/startup.sh
Copy the code

    View started services:

    [root@apollo-node-111 ~]# jps
76338 Jps
75865 apollo-configservice.jar
76174 apollo-adminservice.jar
Copy the code

    The server Apollo-Node-111 started the config and admin services.

  2. On the Apollo – node – 112

    Modify the admin service, Config Service, and portal configuration files and set the database address to 192.168.242.111. The configuration method is the same as step 1.

    In addition, Portal also has an apollo-env.properties configuration file, which is modified as follows:

    Dev. Meta = http://192.168.242.111:8080 pro. Meta = http://192.168.242.112:8080, http://192.168.242.113:8080Copy the code

    According to the host planning, three services should be enabled on the modified machine:

    Start config service
/usr/local/apollo/apollo-configservice/scripts/startup.sh

Start the admin service
/usr/local/apollo/apollo-adminservice/scripts/startup.sh

# start portal
/usr/local/apollo/apollo-portal/scripts/startup.sh
Copy the code

  3. On the Apollo – node – 113

    Modify the configuration files of admin service and **config service** and set the database address to 192.168.242.111. The configuration method is the same as step 1.

    Only the admin and config services are enabled.

Three machines deployment is complete, enter the portal address: http://192.168.242.112:8070/

The default user name and password are Apollo and admin.

In actual combat

After logging in to Apollo Portal, add the project, environment, and namespace as described in the official documentation.

Let’s start with the configuration.

Add configuration:

Release:

To start with, create a New SpringBoot project and introduce Apollo Maven dependencies:

<dependency>
    <groupId>com.ctrip.framework.apollo</groupId>
    <artifactId>apollo-client</artifactId>
    <version>1.8.0 comes with</version>
</dependency>
Copy the code

Configuration file application.properties:

Port =8080 app.id= Apollo -demo Apollo. Meta = http://192.168.242.112:8080, http://192.168.242.113:8080 Apollo. The bootstrap. Enabled = true apollo.bootstrap.namespace=commonCopy the code

Write a test Controller that annotates the configuration or listens for configuration updates:

@RestController
@RequestMapping("/test")
public class TestController {

    @ApolloConfig
    private Config config;

    @GetMapping("/config/expiredMinutes")
    public String getExpiredMinutes(a) {
        return config.getProperty("expiredMinutes"."30");
    }

    @ApolloConfigChangeListener
    private void configOnChange(ConfigChangeEvent changeEvent) {
        if (changeEvent.isChanged("expiredMinutes")) {
            System.out.println("ExpiredMinutes update:" + config.getProperty("expiredMinutes"."30")); }}}Copy the code

After the project is started, visit /config/expiredMinutes to get the value of the configuration item:

Now update expiredMinutes:

At this point, we have implemented the use of the Apollo configuration center.

The first public line 100 li ER, welcome the old iron attention reading correction. Making gitee.com/xblzer/Java…