I'm going to use Spring Config Service (SCS) for our Microservices Architecture.
Currently our Cloud stack is on AWS.
Since SCS will run on a Docker, thanks to a Pipeline + Cloud Formation, and our config repository will be on a private GitHub repository with encrypted values:
Is there any best practice to refresh the repository that will be "pulled" inside the Docker?
How can I update it on any instances? (since my service will be load balanced with HA).
pleas refer following poc
https://github.com/pooja-varma/cloud-config-and-eureka-server
may be it helps you
Config clients don't poll for changes. It has to be triggered and there is a EnvironemntChanged listened by the application and any changes in the properties will be loaded again. If you need more control over when it has to be refreshed and if you want that to be atomic I would recommend you to use #RefreshScope which are lazy proxies and initialized only when they are used. The Environment of your application is pulled every time and it also actuator endpoints to the rescue as well.
Please refer the documentation here.
http://cloud.spring.io/spring-cloud-static/docs/1.0.x/spring-cloud.html#_refresh_scope
Related
A spring integration project pulls emails from Exchange Server using imap-idle-channel-adapter; it transforms the message; it invokes some SOAP webservices and persists data in DB using Spring Boot and JPA. All works fine.
This needs to be deployed in a four-weblogic-server cluster environment.
Could someone please help with some hints on what needs to be done? Is there any configuration needed?
As long as your logic is just like you show and there is no any more endpoints polling shared resource, your are good so far do nothing more. The mail API has built-in feature to mark messages in the box as read or at least seen, so other concurrent session won’t poll those messages again.
I am using springcloud config server to refresh my application properties at the runtime on scheduled basis in production environment. My schedule runs biweekly without any issues.
My application is running on Kubernetes cloud on multiple pods. Pods tends to crash or restart at any moment. What happens in case of pod crash/restart it fetches the latest property file from Config Server and repository at application startup rather waiting for next scheduled refresh cycle.
This lead to inconsistencies across the pods configuration and application behavior.
What I am looking for a strategy to avoid property refresh at the app startup and "Spring cloud config" client to only refresh based on refresh cycle.
Any suggestions to solve above would be greatly appreciate.
You want to use old properties even your application gets restarted so you need to keep old properties detail somewhere. You can not do that in your application as property detail is coming from config server so its better to set refresh rate for config server also how frequent it should pull config detail from git or whatever is your source.
If you set refresh-rate to two week of config server it will contain old property detail only and does not matter how frequent your application restarted it will get old properties from config-server.
I am newbie to micrometer. could anyone let me know how to manage microservice metrics centrally in spring boot ?
Where i can get all registered service information and matrices and stored metrics in influxdb ?
Assuming that you're asking "How to use Micrometer with Spring Boot for collecting metrics from heterogeneous services which have multiple instances on multiple hosts" as there is nothing special with the microservice architecture compared to the assumed environment, you need to add dimensions to metrics for hosts, application instances, and so on. You can achieve it with the common tags support. See the section for it in the Spring Boot reference guide.
UPDATED:
To answer the additional question on the below comment, I created a sample showing how to use common tags with environment variables. Note that it's on the branch common-tags-2.1.x-with-env, not the master.
Let's say I have started to use the spring-cloud-config-server and get it working (using a git repository in background). So now I will deploy that config-server on a cluster (mesos cluster or AWS cloud etc.)
So for reliability etc. I would like to start two instances of the same config-service within a cluster. By using a service registry all other services can now connect to that config-server and get their configuration.
But the question: How can the synchronisation between those config-servers being handled... So for example If I change the configuration in the git repository and now there is some lack of time between both instance will deliver the exact same information...
Does there exist a solution for that ? Some kind of a raft census protocol / setup etc. ? Or is there the only solution not to use spring-config-server and use etcd instead or other solutions ?
Update:
It might be an option to make a fore-update option for the git repositories. This makes sure to get the most recent state with the drawback of performance.
In Spring Cloud Services v3.1.2 and later, you can use the periodic parameter when configuring a Config Server service instance to cause the mirror service to automatically refresh a Git repository mirror periodically
pcf link
We are in the process of standing up a new microservices architecture with Zuul at the front-end and a bunch of tomcat enabled microservices at the backend. Each service as it starts up, will register itself with Eureka and any client that wants to call those service will do so through Zuul. We've got this all wired in and everything is working fine.
However, I have a couple questions as to how we can make this architecture much more dynamic.
One thing that we assumed was there out of the box with Ribbon/Eureka, but have yet to find a solution for is that as we add more services to the backend, that somehow (via Archiaus and update to Zuul's eureka-client.properties file) Zuul's Ribbon client would update itself with the new service details (e.g. vipaddress, load balancing algorithm, etc). So far, the only thing that works is to update the properties file and restart Zuul (ughhh).
For example, let's say today we have 2 microservices at the backend, therefore, Zuul's eureka/ribbon client configuration would include the below:
ribbon.client.niws.clientlist=service1|service2
zuul.ribbon.namespace=zuul.client
service1.zuul.client.DeploymentContextBasedVipAddresses=myService1
service1.zuul.client.NIWSServerListClassName=com.netflix.niws.loadbalancer.DiscoveryEnabledNIWSServerList
service2.zuul.client.DeploymentContextBasedVipAddresses=myService2
service2.zuul.client.NIWSServerListClassName=com.netflix.niws.loadbalancer.DiscoveryEnabledNIWSServerList
Now tomorrow, let's assume we need to add service3. What we have observed is that if we add those details to the same configuration (see below), they only become available to Zuul after a restart. Is there some other configuration parameter we are missing that would allow us to dynamically introduce the new service details or do we have to roll our own Eureka/Ribbon client to do this?
ribbon.client.niws.clientlist=service1|service2|service3
zuul.ribbon.namespace=zuul.client
service1.zuul.client.DeploymentContextBasedVipAddresses=myService1
service1.zuul.client.NIWSServerListClassName=com.netflix.niws.loadbalancer.DiscoveryEnabledNIWSServerList
service2.zuul.client.DeploymentContextBasedVipAddresses=myService2
service2.zuul.client.NIWSServerListClassName=com.netflix.niws.loadbalancer.DiscoveryEnabledNIWSServerList
service3.zuul.client.DeploymentContextBasedVipAddresses=myService3
service3.zuul.client.NIWSServerListClassName=com.netflix.niws.loadbalancer.DiscoveryEnabledNIWSServerList
My other question is related and that is do we really need to add a client configuration (in eureka-client.properties) for every service that Zuul could possibly route to? At some point, we may have 100's of services running and trying to maintain all the related client configurations in Zuul seems a bit clumsy. Is there a way to globally configure Zuul to load all services into its client list from Eureka (or based on some service metadata in Eureka) and dynamically update this list as new services register themselves with Eureka?
Thanks!
The issue is with namespaces.If we use the default namespace it should be able to pick up the new properties addedd by default.