microservices

问题 I have created a spring boot application to connect h2 database with it. While doing so, it throws an error showing Database not found. Please help me with the solution which I can implement and resolve the issue. I have added com.h2database dependency in the pom.xml file, then also it gives the error. Below is my pom.xml file and application.properties file pom.xml <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation=

问题 So I am creating application using microservice architecture. I have few microservices and I want to configure all in kong with custom routes/url. For example: I have user service and location service and I want those routes in kong looks like this: GET http://localhost:8001/service/user/list --> http://user-service-url.com/user_list GET http://localhost:8001/service/location/122332--> http://location-service-url.com/get/122332 I have searched all over the internet and couldn't find anything.

问题 Here is the yml for spring cloud gateway. I want to write URI without load balancing. But as I'm using Eureka, I don't think hardcoding something like "localhost:6678" is a good idea. I would like to specify the service name, without the lb prefix. Any way to write it ? spring: cloud: gateway: routes: - id: before_route uri: lb://hello-service I'm seeing this on the console when I run the gateway: You already have RibbonLoadBalancerClient on your classpath. It will be used by default. As

问题 Here is the yml for spring cloud gateway. I want to write URI without load balancing. But as I'm using Eureka, I don't think hardcoding something like "localhost:6678" is a good idea. I would like to specify the service name, without the lb prefix. Any way to write it ? spring: cloud: gateway: routes: - id: before_route uri: lb://hello-service I'm seeing this on the console when I run the gateway: You already have RibbonLoadBalancerClient on your classpath. It will be used by default. As

问题 Background: I am building an application and the proposed architecture is Event/Message Driven on a microservice architecture. The monolithic way of doing thing is that I've a User/HTTP request and that actions some commands that have a direct synchronous response . Thus, to respond to the same User/HTTP request is 'hassle free'. The problem: The user sends an HTTP request to the UI Service (there are multiple UI Services) that fires some events to a queue (Kafka/RabbitMQ/any). a N of

问题 I tried to start a new f1-micro node in my cluster using Googles UI and it silently fails. So I decided to run it using gcloud to see if that one provides more details And so I ran the following gcloud container node-pools create my-f1-pool --image-type ubuntu --machine-type=f1-micro --cluster bcomm-sg-cluster --disk-size=10GB --enable-autoscaling --min-nodes=2 --max-nodes=6 --zone=asia-southeast1-a --enable-autorepair This is the result I got instead WARNING: Modifications on the boot disks

问题 I try to set a cookie in one domain and send it to another domain. Architecture : API-Gateway -> User service When a login request receives to Gateway, it forwards it to User service. User service does credential checking, if it matches, then redirect it to gateway. expiration := time.Now().Add(24 * time.Hour) cookie := http.Cookie{Name: "usercookie",Value:jwtToken,Expires:expiration,Path:"/"} http.SetCookie(res, &cookie) redirectURL := "http://localhost:7070/home?usercookie=" + url

问题 I'm trying to make a few microservices more resilient and retrying certain types of HTTP requests would help with that. Retrying timeouts will give clients a terribly slow experience, so I don't intend to retry in this case. Retrying 400s doesn't help because a bad request will remain a bad request a few milliseconds later. I imagine there are other reasons to not retry a few other types of errors, but which errors and why? 回答1: There are some errors that should not be retried because they

问题 I'm trying to make a few microservices more resilient and retrying certain types of HTTP requests would help with that. Retrying timeouts will give clients a terribly slow experience, so I don't intend to retry in this case. Retrying 400s doesn't help because a bad request will remain a bad request a few milliseconds later. I imagine there are other reasons to not retry a few other types of errors, but which errors and why? 回答1: There are some errors that should not be retried because they

问题 Consider the following micro services for an online store project: Users Service keeps account data about the store's users (including first name, last name, email address, etc') Purchase Service keeps track of details about user's purchases. Each service provides a UI for viewing and managing it's relevant entities. The Purchase Service index page lists purchases. Each purchase item should have the following fields: id, full name of purchasing user, purchased item title and price.