To better understand the structure and so of microservices, I ask here.
For example, how would you structure Netflix in microservices?
And one more thing: Netflix, for example, has quite a few calls, if a microservice were to process all the queries on its own, there would certainly be an overload. So how does Netflix do that? Multiple servers for the same microservice? And how would the databases synchronize among the different servers? Or is there then only one database? This could also lead to overload? And how is it decided when which server is used? By random? Or is the server user load somehow fetched?
Micro services have their own data. A service can run with multiple instances, before that a load balancer distributes the calls. The entire system is designed so that if individual components fail, everything continues to run as well as possible. Therefore, things like data synchronization are coupled as loosely as possible and implemented fault-tolerant.
The load balancer is something new for me. It is clear to me that every microservice treats its own data. Let's take account microservice as an example. Will everything be traded from just one database or from several on different servers in order to withstand the requests? If the latter, how are the databases synchronized?
One could connect several account service instances to a correspondingly performant database, e.g. By lowering the consistency requirements for the database that is then clustered if necessary:
https://db-engines.com/de/article/Eventual+Consistency
Another approach is to explicitly model the events that can occur for a user account (query from the app - read-only, new customer, changed settings, make recommendations) and then only distribute corresponding events for synchronization between then several services. Here is an example for an online shop:
https://dzone.com/articles/event-driven-orchestration-an-effective-microservi
With all this, one should not forget that such an architecture is significantly more complex than simple business logic for a normal, relational, transactional database. This solves scaling problems, both for the development teams and for the application itself - but it is bought with a complex and distributed application. Shouldn't be done without need…
I understand, you explained that well, thank you! Two more questions: If Eventual Consistency then pulls all the new values from the database and then writes them into the other database, wouldn't the database be overloaded? Second question: When you update a value, only one database is addressed; is this also addressed asynchronously or is there a wait until the confirmation comes before the client receives a response?
A typical DB of this type would be e.g. Apache Cassandra - when splitting the DB over many nodes, not every node saves all data, but only a part (e.g. 13 nodes, all data replicated to three nodes). This also allows write operations to be scaled by more nodes.
And when writing to the Cassandra DB, the desired consistency can be selected. In Micro Service, you also have the choice in your logic, regardless of the specific DB engine, to respond immediately, write asynchronously to the DB, and wait for the client until the DB has confirmed the write operation.
Thank you!
For example, how would you structure Netflix in microservices?
Netflix's architecture consists of microservices. - They also do a lot of https://github.com/...om/Netflix" class="text-primary">https://github.com/...om/Netflix around the topic.
Without knowing what's actually going on, I can think of various structuring options:
By area of responsibility (I think most likely possible): One microservice takes care of the customer database, another one for the login, another one for the upload of content (there will surely be an interface), another one for the delivery from content to an https://de.wikipedia.org/...ry_Network, then another to calculate recommendations for customers etc.
Distributed by region / country / language: A microservice would then be responsible for German customers, for example, another for Americans etc. (similar to a CDN)
At Netflix I could also imagine that there are different services for certain genres or similar. Gives in order to distribute the load flexibly, for example, with new releases: At Christmas time, one could, for example, increase the services for the Christmas films, but instead reduce the services for the Easter bunny films. (the delivery of the films is estimated to be carried out by a CDN)
…
For example, Netflix has quite a few calls. If a microservice were to handle all the queries on its own, it would certainly be overloaded. So how does Netflix do that?
This is already in the name "microservices architecture":
Micro: That means the various services are very "small" and ideally only responsible for exactly one task. Other services are responsible for other tasks.
Services: majority, so (mostly) there are several services, depending on the distribution of the load.
=> You somehow need a central "instance" that knows which server is responsible for what, where it can be found (for example, under which IP) and whether it is currently online or offline (otherwise the requests are empty). To put it simply: Services log on to a server, tell them what they are doing and are then asked at a certain frequency whether they are still there. A "client" who needs the services only needs to know the IP of this server, asks the server "I need this and that" and the server either forwards the request directly or tells the client which server is responsible for the problem responsible is. Such a server would be e.g. https://github.com/Netflix / eureka (from Netflix), a kind of "registrar" for services.
And how is it decided when which server is used? By random? Or is the server user load somehow fetched?
The keyword is load balancing. There are very different approaches:
Round-robin: the first time the first service is asked, the next one the second service etc.
Distribution by load: The requests are allocated to the service that has the least load at the moment.
Distribution according to response time: The inquiries are allocated to the "next" / fastest service (for example, with a globally distributed network, an inquiry from Germany would not be sent to a service in Shanghai, but rather to the service in Frankfurt)
coincidence
…
There's again the idea of the central authority as a decision-maker about the inquiries (= bottleneck) or the microservices themselves report their status and reject an inquiry if they can't / do not want to (= may take longer to get a service that accepted a request, was found).
Multiple servers for the same microservice?
It all depends on the architecture. Sometimes you only need one server for a certain microservice, sometimes you need 200 servers for a certain service. In theory (depending on the protocol), several microservices can work on one server, for example for developer / debugging purposes.
And how would the databases synchronize among the different servers? Or is there then only one database?
That is also very different. There could be a central DB, several distributed, then there would be the possibility that there's no central DB, but several smaller ones, which in turn can be accessed using other microservices, if you want to take the whole thing to an extreme, you could have a microservice that writes data for each table in a database and have a microservice that reads data. - The opposite would be
Thanks, it helped me a lot!
