What is a distributed configuration center?

I am 3Y, a markdown programmer with one year CRUD experience and ten years’ experience 👨🏻💻 known as a quality octuan player all the year round

Last time we arranged the monitoring posture, I wonder if you have configured it. But I don’t care what your progress is. I’m not waiting for you.

Today, LET’s talk about the topic of distributed configuration center

What is a distributed configuration center

As I mentioned earlier, a distributed configuration center is a component that comes standard on the back end.

A distributed configuration center is simple to understand: it is a system that keeps configuration information separate from its own system, and this information can be accessed by applications in real time.

It is not difficult to achieve the above core functions, but as middleware, more supporting services are required, including but not limited to

• 1, there is a background interface for us to modify the configuration
• 2. Configure the Dr Logic if the service is interrupted
• 3. Support configuration information in different environments (our online configuration is generally configured with different values in different environments)
• 4. Related authority management (only the responsible person can update the configuration)
• 5. Easy to use (with corresponding SDK support or API support)
• .

Some companies develop their own set of components for this distributed configuration center, which implements the functionality I mentioned above. As an individual or a small business, just go open source. Don’t always think how wonderful research, maintenance cost is great.

02, Why distributed configuration center

We can store the constantly changing configuration information in the distributed configuration center, such as: the requested IP address, traffic limiting value, system configuration value, various service switches, and so on.

Even my old employer’s rules engine was based on a distributed configuration center, which used too many scenarios…

Take our Austin project for example. This time we are going to implement message discarding. Yes, you read that right. The core of our project is sending messages, but we need to implement the function of discarding messages in the system.

Austin is positioned as a push platform for all types of push messages across the company. With this positioning, it is difficult to guarantee who will use the system (naturally there will be careless ones).

What we can see from Austin’s implementation architecture is that if a large number of messages need to be delivered instantly, the data will be stuck on MQ waiting to be consumed

We implemented validation at the Austin-API layer to determine if the template was deleted, but it is likely that requests have already been processed by Austin-API and messages are already backlogged in MQ.

It is possible to check again with austini-Handler to see if the template has been deleted, but many times the owner of the message template does not want to delete the template (deleting it means they cannot see the configuration message for the template on the console), perhaps they just sent the wrong message and hope that undelivered messages will not be sent again.

In addition, we had to implement whitelist blocking in the Austin project for dev and Pre environments.

For Austin projects, dev and Pre environments are not fundamentally different from online environments. Because ultimately messages are delivered, as long as the environment can deliver messages to the user, it can be used as an online environment.

Generally, services go through the process in the DEV and Pre environments before sending messages. However, it is hard to guarantee that they will be tested properly, what if the business side has a Bug that causes the dev/ Pre environment to be pushed in large quantities?

So, we whitelisted the dev/pre environment so that only users who were whitelisted could receive messages. The whitelist list can be maintained in the distributed configuration center

PS: I believe that we have more or less seen a lot of push accidents (major factories seem to have similar news and experience). In large part, it’s a mixture of circumstances. The dev or Pre environment was used to test message delivery, but production was used instead. (This kind of problem usually requires the intervention of authority and approval)

Like the previous implementation of the de-duplication function, I hardcoded the specific num and seconds values in the code. These values may one day change with the operational rules, so they will also be drawn to the distributed configuration center.

.

03. Distributed configuration center selection

From the first day I wrote Apollo into middleware that Austin might introduce, I had a lot of people ask me why I chose Apollo. I still quite puzzled, how on this middleware ask me especially much? The distributed configuration center also has a wide selection of projects:

There are also many comparisons on the Internet, such as:

Overall: Apollo supports a full range of features, a vibrant community, and rich documentation in Chinese. So I chose Apollo. It’s so important to have an active community, and when you have a problem with a framework and you look it up on the Internet and no one has a record of stomping on it, it’s a big head.

As I mentioned earlier, technology selection is often not tied to technology. If it’s a personal project, pick one where the community is active and where the middleware is already being trampled, and learn its ideas and principles. And so on the knowledge of the future, feel at that time the brain into the shit chose a broken thing, switching costs generally will not have much.

If you are in a company, if you already have similar middleware, you will use what you need to use and tinker with it. If you don’t have a similar middleware, spend a lot of time on research, but in the end, you still need the maturity of the middleware and the community activity (or maybe the boss will follow the habit of making a decision in the past). Ah, there you go. No brainer.)

However, if you are interested, you can take a look at the comparison. There are many articles on the Internet.

04. Principle of distributed configuration center

My previous company was a self-developed distributed configuration center, and I’ve seen the concept before. At that time, I saw that the implementation of the technology developed by the company was to use a long connection to enable the configuration to be listened to by the client in real time. Apollo was referenced this time, and I also looked at the design document, which also implemented real-time client awareness through long polling

I recommend reading distributed configuration Center if you are not familiar with it or what it is.

Ctrip Apollo configuration center architecture analysis evolution

www.apolloconfig.com/#/zh/design…

I don’t feel like I have anything to say about this, and I don’t look at the source code for nothing (unless I’m particularly interested in a technical implementation to see how it’s implemented). And the Apollo documentation did a pretty good job.

I read it from beginning to end, and it felt very smooth, as if I didn’t need to add anything.

Deploy APOLLO

Docker-compose is composed for GitHub, and docker-compose is composed for GitHub, and docker-compose is composed for GitHub.

www.apolloconfig.com/#/zh/deploy…

Github.com/apolloconfi…

Due to the port occupancy problem, I changed the mapping port, the most important two ports: 8070 is the port of the background control page, 8080 is the port of the service

SPRINGBOOT uses APOLLO

As I write this, I find that I really have nothing to write about. I just follow the official documents. The only good thing about this is that I have code that’s already there, so if you follow along, you can just copy and paste it.

1. Introduce Maven dependencies

<dependency> <groupId>com.ctrip.framework.apollo</groupId> <artifactId>apollo-client-config-data</artifactId> The < version > 1.9.1 < / version > < / dependency >Copy the code

Add Apollo configuration information to configuration file:

# apollo  TODO
app:
  id: austin
apollo:
  bootstrap:
    enabled: true
    namespaces: boss.austin
Copy the code

The configuration information was added on the back stage of Apollo (this is not a problem as long as you can open the background, the operation is quite simple, feel there is no need to see any documentation).

The creation of the department is actually a “configuration”, typing organizations can change the existing department, I added boss shareholder department, everyone is my shareholders.

3. Use ApolloConfig directly in Spring

It’s also worth noting that we deployed Apollo on a cloud server using Docker. Generally, fetching posture configuration exposes the corresponding service address on the Intranet, but this is our first experience, so we can skip meta Server directly

To make it easier to use, set the parameters directly at startup (students can change their OWN IP and port).

08,

This article provides a brief introduction to what a distributed configuration center is and what it can be used for. It describes how to get started with Apollo and how to use Apollo in a SpringBoot environment.

I strongly recommend that those of you who are not familiar with distributed configuration centers start with Apollo and read about the origin of his architecture and its design philosophy based on the links above. As a Markdown programmer, I think it’s pretty good.

Those interested in this can also dig into the source code to see how key features are implemented (another learning path?).

If the company has not used the distributed configuration center, read the article to see if there are relevant scenarios for your project, you can research and plug in (a whole Q KPI/OKR is available, don’t worry about it).

It’s not too much to like, is it? I’m 3y. See you in the next video.

Follow my wechat public number [Java3y] in addition to technology I will also talk about some daily, some words can only say quietly ~ [line interview + write Java project from zero] continuous high intensity update! O star!!!!! Original is not easy!! Three times!!

Austin project source code Gitee link: gitee.com/austin

Austin project source code on GitHub: github.com/austin