Spring Boot - Zuul - 微服务 - 优化对网关的 API 调用以获取用户详细信息

Question

I am implementing a micro-service architecture in Spring-Boot with Zuul as gateway. I have a zuul gateway service that has authentication and authorisation logic. Also, it has API exposed that responds with user details like userid-username mapping, current loggedin user etc. So, my other services make API call to gateway for any user information. I have marked zuul.sensitiveHeaders=Cookie,Set-Cookie to allow bearer token to be passed to non-gateway microservices.

Problem Statement - In my other service, I am just storing userid where ever required. Then, while returning data to front-end, I make API call to gateway service to fetch username for the userid. This works fine when I am modifying single data.

However, when I have to return bulk data (say 1000 records), I am making 1000 API calls to fetch username based on userid of each record. This is compromising the speed.

Example -

To display above data on UI, I am making 8 API calls to gateway to fetch username for each userid (created_by).

Can someone please help me with architecture I should be using in such case. Some of the solutions I thought of are below. However I am not very sure if any of these is best possible one

1. Fetch hashmap of userid-username mapping after login and store in session cache. but this will slowdown login call
2. Add OncePerPrequestFilter such that on every API call, hashmap of userid-username mapping will be fetched and passed to controller. This is feasible but in APIs where this mapping is not required, still a API call will be made which will be over load.

any other suggestions are welcome.

Answer 1

It's not quite clear what you're trying to do - the question title does not seem to have to do much with the description. Nonetheless, it seems you have two separate facets to this issue:

1. In your backend, you require user information passed via the token (through your Gateway) that is used in your services.
2. In you frontend, you need some (minimal?) subset of that information for display purposes (I say display, but usually this information would be used for some other process - eg "send this user an E-Mail").

Moreover, you mention that:

However, when I have to return bulk data (say 1000 records), I am making 1000 API calls to fetch username based on userid of each record. This is compromising the speed.

How you wish to handle this situation depends what you want to do and how you wish to represent your requests and results.

In short, you need to give us more details behind the actual use case behind this specific request and the nature of requests that will be happening in the system. For instance, do you really need each individual user? Do you instead perhaps need a list of all active/inactive/ users in the system? In the latter case, it would suffice to query a read-optimized model which is updated whenever a new user is created. In this case, the response would not only be fast, but you could easily add nice features like paging and sorting since chances are you are already providing such functionality for collection-based responses.

Your backend services can still populate a security context based on the token information alone: what the user's role in the system is, the provided scopes, etc. For changing the state of the system, you would still (at some point in the process) have a check that checks the current system state, via eg a database call.

If you only need some small subset of details for the currently logged in user to be displayed (which rarely changes), and this data is not highly confidential, you may consider adding it as a custom Claim inside your bearer token. For example, if you use JWTs as your bearer tokens, you can easily decode the token and read the information.

So, it depends on what you exactly want to do. Do you really need to query >1,000 individual users at once for 1 field? Perhaps I've misunderstood the question, but it sounds to me like you want a very specific subset of information on a large number of entities (in this case - users) in your system, and a read-optimized model (or even a database view which is directly queried by a user with sufficient privileges) would do the job.

As a side remark, Spring Cloud Zuul has been in maintenance mode since the Greenwich release train, as of 22 Jan. 2019. You should consider upgrading to the Spring Cloud Gateway , which supersedes it and offers (among many other improvements) a non-blocking request model (as opposed to the Zuul blocking model).