introduction-to-microservices
kandi X-RAY | introduction-to-microservices Summary
kandi X-RAY | introduction-to-microservices Summary
introduction-to-microservices
Support
Quality
Security
License
Reuse
Top functions reviewed by kandi - BETA
Currently covering the most popular Java, JavaScript and Python libraries. See a Sample of introduction-to-microservices
introduction-to-microservices Key Features
introduction-to-microservices Examples and Code Snippets
Community Discussions
Trending Discussions on introduction-to-microservices
QUESTION
Current Architecture:
Problem:
We have a two-step flow between frontend and backend layers.
- First step: The frontend validates an input I1 from the user on microservice 1 (MS1)
- Second step: The frontend submits I1 and more information to the microservice 2
The micro service 2 (MS2) needs to validates the integrity of I1 as it is coming from the frontend. How to do avoid a new query to MS1? What's the best approach?
Flows that I'm trying to optimize removing the steps 1.3 and 2.3
Flow 1:
- 1.1 The User X requests data (MS2_Data) from MS2
- 1.2 The User X persists data (MS2_Data + MS1_Data) on MS1
- 1.3 The MS1 check the integrity of MS2_Data using a B2B HTTP request
- 1.4 The MS1 use MS2_Data and MS1_Data to persist and Database 1 and build the HTTP response.
Flow 2:
- 2.1 The User X already has data (MS2_Data) stored on local/session storage
- 2.2 The User X persists data (MS2_Data + MS1_Data) on MS1
- 2.3 The MS1 check the integrity of MS2_Data using a B2B HTTP request
- 2.4 The MS1 use MS2_Data and MS1_Data to persist and Database 1 and build the HTTP response.
Approach
One possible approach is to use a B2B HTTP request between MS2 and MS1 but we would be duplicating the validation in the first step. Another approach will be duplicating data from MS1 to MS2. however this is prohibitive due to the amount of data and it's volatility nature. Duplication does not seem to be a viable option.
A more suitable solution is my opinion will the frontend to have the responsibility to fetch all the information required by the micro service 1 on the micro service 2 and delivered it to the micro service 2. This will avoid all this B2B HTTP requests.
The problem is how the micro service 1 can trust the information sent by the frontend. Perhaps using JWT to somehow sign the data from the micro service 1 and the micro service 2 will be able to verify the message.
Note Every time the micro service 2 needs information from the micro service 1 a B2B http request is performed. (The HTTP request use ETAG and Cache Control: max-age). How to avoid this?
Architecture Goal
The micro service 1 needs the data from the micro service 2 on demand to be able to persist MS1_Data and MS2_Data on MS1 database, so the ASYNC approach using a broker does not apply here.
My question is if exists a design pattern, best practice or a framework to enable this kind of thrust communication.
The downside of the current architecture is the number of B2B HTTP requests that are performed between each micro services. Even if I use a cache-control mechanism the response time of each micro service will be affected. The response time of each micro services is critical. The goal here is to archive a better performance and some how use the frontend as a gateway to distribute data across several micro services but using a thrust communication.
MS2_Data is just an Entity SID like product SID or vendor SID that the MS1 must use to maintain data integrity.
Possible Solution
The idea is to use the gateway as an api gateway request processing that will cache some HTTP response from MS1 and MS2 and use them as a response to MS2 SDK and MS1 SDK. This way no communication (SYNC OR ASYNC) is made directly between MS1 and MS2 and data duplication is also avoided.
Of course the above solution is just for shared UUID/GUID across micro services. For full data, an event bus is used to distribute events and data across micro services in an asynchronous way (Event sourcing pattern).
Inspiration: https://aws.amazon.com/api-gateway/ and https://getkong.org/
Related questions and documentation:
- How to sync the database with the microservices (and the new one)?
- https://auth0.com/blog/introduction-to-microservices-part-4-dependencies/
- Transactions across REST microservices?
- https://en.wikipedia.org/wiki/Two-phase_commit_protocol
- http://ws-rest.org/2014/sites/default/files/wsrest2014_submission_7.pdf
- https://www.tigerteam.dk/2014/micro-services-its-not-only-the-size-that-matters-its-also-how-you-use-them-part-1/
ANSWER
Answered 2017-Jan-13 at 19:50It's difficult to judge the viability of any solution without looking "inside" the boxes, however:
If the only thing you care about here is stopping the frontend from potentially tampering with the data, you can create a sort of "signature" of the packet of data sent by MS2 to the frontend and propagate the signature to MS1 together with the packet. The signature can be a hash of the packet contatenated with a pseudorandom number generated in a deterministic way from a seed shared by the microservices (so MS1 can recreate the same pseudorandom number as MS2 without the need for an additional B2B HTTP request, and then verify the integrity of the packet).
The first idea that comes to my mind is to verify whether the ownership of the data could be modified. If MS1 must frequently access a subset of data from MS2 it MAY be possible to move the ownership of that subset from MS2 to MS1.
In an ideal world the microservices should be completely standalone, each one with it's own persistence layer and a replication system in place. You say that a broker is not a viable solution, so what about a shared data layer?
Hope it helps!
QUESTION
I'm developing a website with the microservice architecture, and each of the service owns a database. The database stores the data which the microservice needs.
Post
, Video
services need the user information, so both of the services subscribed to the NEW_USER_EVENT
.
The NEW_USER_EVENT
will be triggered when there's a new user registered.
Once the services received the NEW_USER_EVENT
, they put the incoming user information to each of their own database. So they can do things without asking the User
service.
So far so good. But here comes the question:
- What if I'm going to create a new service? How do I get the registered user informations and put them in the new service?
Maybe I can get the informations from the existing services. But the events are pushed by the messaging queue (NSQ
).
If I'm going to copy the data from one of the microservices, how do I make sure which service has the latest user informations? (Because some services haven't received the latest event)
Read More:
The Hardest Part About Microservices: Your Data
Intro to Microservices, Part 4: Dependencies and Data Sharing
...ANSWER
Answered 2017-Jan-05 at 00:14What if I'm going to create a new service? How do I get the registered user informations and put them in the new service?
You have to replay all events to which this new service is subscribed from the beginning of time (you should have an "event store" that keeps all events already happened in your application). Also, you can put a bit smarter logic when replaying events by starting from the most recent ones and going back in time. In this way, you will be able to restore most valuable data first. Just be careful to handle interdependent events correctly.
Data source: The events are pushed by the messaging queue(NSQ), If I'm going to copy the data from one of the microservices, how do I make sure the copy source has the latest user informations?
You are not talking about doing backups, right?
Aside from backups, in the event-driven systems people usually don't copy the data in a classical way, row by row. Instead, they just replaying events from event store from the beginning of time and feeding those events to the event handlers for the new service (or new instance). As a result, new service eventually becomes consistent with the other parts of the system.
Community Discussions, Code Snippets contain sources that include Stack Exchange Network
Vulnerabilities
No vulnerabilities reported
Install introduction-to-microservices
Support
Reuse Trending Solutions
Find, review, and download reusable Libraries, Code Snippets, Cloud APIs from over 650 million Knowledge Items
Find more librariesStay Updated
Subscribe to our newsletter for trending solutions and developer bootcamps
Share this Page