Hi friends,
In this post, I will explain about CAP Theorem and setting external configurations in microservices.
Question 1:
What is CAP Theorem?
Answer:
- Consistency — A guarantee that every node in a distributed cluster returns the same, most recent, successful write. Consistency refers to every client having the same view of the data. There are various types of consistency models. Consistency in CAP (used to prove the theorem) refers to linearizability or sequential consistency, a very strong form of consistency.
- Availability — Every non-failing node returns a response for all read and write requests in a reasonable amount of time. The key word here is every. To be available, every node on (either side of a network partition) must be able to respond in a reasonable amount of time.
- Partition Tolerant — The
system continues to function and upholds its consistency guarantees in
spite of network partitions. Network partitions are a fact of life.
Distributed systems guaranteeing partition tolerance can gracefully
recover from partitions once the partition heals.
The C and A in ACID
represent different concepts than C and A in the CAP theorem.
The CAP theorem
categorizes systems into three categories:
- CP (Consistent and Partition Tolerant) — At first glance, the CP category is confusing, i.e., a system that is consistent and partition tolerant but never available. CP is referring to a category of systems where availability is sacrificed only in the case of a network partition.
- CA (Consistent and Available) — CA systems are consistent and available systems in the absence of any network partition. Often a single node's DB servers are categorized as CA systems. Single node DB servers do not need to deal with partition tolerance and are thus considered CA systems. The only hole in this theory is that single node DB systems are not a network of shared data systems and thus do not fall under the preview of CAP.
- AP (Available and Partition Tolerant) — These are systems that are
available and partition tolerant but cannot guarantee consistency.
Question 2:
How to do externalized configuration in microservices?
Answer:
Why do we need
this?
With microservices, applications are split into
several services (microservices), each one usually running in a separate
process. Each process can be deployed and scaled independently, meaning that
there may be several replicas of the a microservice running at a certain time.
Let’s say we want to modify the configuration for a microservice that has been replicated a hundred times (one hundred processes are running). If the configuration for this microservice is packaged with the microservice itself, we’ll have to redeploy each of the one hundred instances. This can result in some instances using the old configuration, and some using the new one.
Moreover, sometimes microservices use external connections which,
for example, require URLs, usernames, and passwords. If you want to update
these settings, it would be useful to have this configuration shared across
services.
How does it work?
Externalized configuration works by keeping the
configuration information in an external store, such as a database, file
system, or environment variables. At startup, microservices load the
configuration from the external store. During runtime, microservices provide an
option to reload the configuration without having to restart the service.
Implementing a configuration
server with Spring Cloud Config
There are many ways to implement externalized configuration. Netflix’s Archaius and Spring Cloud offer ready-to-use and well-tested solutions. Cloud services and platforms such as AWS and Kubernetes offer similar services, as well. The demo application uses Spring Cloud Config which includes both the server and the client part of the equation.
Use the Spring Initializr to create a new Spring Boot
application named config-server and include the Eureka
Discovery, Config Server, Actuator (optional), and Config Server
dependencies:
Open up the ConfigServerApplication class
and activate the discovery client and the configuration server by using the
following annotations:
@SpringBootApplication
@EnableConfigServer
@EnableDiscoveryClient
public class ConfigServerApplication {
...
}
Remove the application.properties file
and create a new application.yml file
with the following content
server.port:8101
spring:application.name:config-server
cloud.config:
server.git:
uri:https://github.com/alejandro-du/vaadin-microservices-demo-config.git
default-label:master
eureka:client:
serviceUrl:
defaultZone:http://localhost:8001/eureka/
registryFetchIntervalSeconds:1
instance:
leaseRenewalIntervalInSeconds:1
}
That's all for this post.
Thanks for reading!!
