{"id":80035,"date":"2020-05-02T13:42:54","date_gmt":"2020-05-02T11:42:54","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/udobnye-arhitekturnye-patterny"},"modified":"2020-05-02T13:42:54","modified_gmt":"2020-05-02T11:42:54","slug":"udobnye-arhitekturnye-patterny","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/udobnye-arhitekturnye-patterny","title":{"rendered":"Convenient Architectural Patterns","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hello, Habr!<\/p>\n

<\/p>\n

In light of the current events due to the coronavirus, a number of internet services have started to experience increased load. For example, one of the retail chains in the United Kingdom simply halted its online ordering website<\/a><\/noindex>, as it could not handle the demands. It's not always possible to simply speed up a server by adding more powerful hardware; however, customer requests must be processed (or they'll go to competitors).<\/p>\n

<\/p>\n

In this article, I'll briefly discuss popular practices that can help create a fast and fault-tolerant service. However, among the possible development schemes, I have selected only those that are currently easy to utilize<\/strong>. For each point, you either already have ready-made libraries available, or you can solve the task using a cloud platform.<\/p>\n

<\/a><\/noindex><\/p>\n

Horizontal Scaling<\/h1>\n

<\/p>\n

The simplest and most well-known point. Conventionally, there are two commonly encountered load distribution schemes \u2014 horizontal and vertical scaling. In the first case,<\/a><\/noindex> you allow services to work in parallel, thus distributing the load among them. In the second case,<\/a><\/noindex> you order more powerful servers or optimize the code.<\/p>\n

<\/p>\n

For example, I will take an abstract cloud file storage, that is, a kind of analog of OwnCloud, OneDrive, and so on.<\/p>\n

<\/p>\n

The standard illustration of such a scheme is below; however, it merely demonstrates the complexity of the system. After all, we need to somehow synchronize the services. What happens if a user saves a file from a tablet and then wants to view it on a phone?<\/p>\n

<\/p>\n

\"Convenient
\nThe difference between the approaches: in vertical scaling, we are ready to increase the capacity of nodes, while in horizontal scaling \u2014 we add new nodes to distribute the load.<\/p>\n

<\/p>\n

CQRS<\/h1>\n

<\/p>\n

Command Query Responsibility Segregation<\/a><\/noindex> is quite an important pattern, as it allows different clients to not only connect to different services but also receive the same event streams. Its advantages are not so obvious for a simple application, but it is extremely important (and simple) for a high-load service. Its essence: incoming and outgoing data streams should not intersect. In other words, you cannot send a request and expect a response; instead, you send a request to service A, but receive a response in service B.<\/p>\n

<\/p>\n

The first bonus of this approach is the ability to break the connection (in the broad sense of the word) during the execution of a long request. For example, let's take a more or less standard sequence:<\/p>\n

<\/p>\n

    \n
  1. The client sent a request to the server.<\/li>\n
  2. The server started a long process.<\/li>\n
  3. The server replied to the client with the result.<\/li>\n<\/ol>\n

    <\/p>\n

    Let's imagine that in step 2, the connection was interrupted (either the network was reconnected, or the user navigated to another page, terminating the connection). In this case, it will be difficult for the server to send a reply to the user with information about what was processed. By applying CQRS, the sequence will be slightly different:<\/p>\n

    <\/p>\n

      \n
    1. The client subscribed to updates.<\/li>\n
    2. The client sent a request to the server.<\/li>\n
    3. The server responded 'request accepted'.<\/li>\n
    4. The server replied with the result via the channel from step '1'.<\/li>\n<\/ol>\n

      <\/p>\n

      \"Convenient<\/p>\n

      <\/p>\n

      As seen, the scheme is a bit more complex. Moreover, the intuitive request-response approach is absent here. However, as can be seen, a connection break during the request processing will not lead to an error. Furthermore, if the user is actually connected to the service from multiple devices (for example, from a mobile phone and a tablet), it can be arranged for the response to arrive on both devices.<\/p>\n

      <\/p>\n

      Interestingly, the code for handling incoming messages becomes somewhat uniform (not 100%) for both events influenced by the client and for other events, including those from other clients.<\/p>\n

      <\/p>\n

      However, in reality, we gain additional bonuses due to the fact that a unidirectional flow can be processed in a functional style (using RX and analogs). And this is a significant advantage, as essentially the application can be made fully reactive, while also applying a functional approach. This can significantly save resources on development and maintenance for complex applications.<\/p>\n

      <\/p>\n

      If we combine this approach with horizontal scaling, we gain the ability to send requests to one server while receiving responses from another. Thus, the client can choose the service that is convenient for him, while the system internally will still be able to process events correctly.<\/p>\n

      <\/p>\n

      Event Sourcing<\/h1>\n

      <\/p>\n

      As you know, one of the main features of a distributed system is the lack of a global time and a common critical section. For a single process, you can achieve synchronization (on the same mutexes) in which you are sure that no one else is executing this code. However, for a distributed system, such synchronization is dangerous, as it incurs overhead and undermines the very beauty of scaling \u2014 ultimately, all components will be waiting on one.<\/p>\n

      <\/p>\n

      From this, we derive the important fact that a fast distributed system cannot be synchronized, as that would reduce performance. On the other hand, we often need a certain level of consistency among components. For this, we can utilize an approach with eventual consistency<\/a><\/noindex>, which guarantees that in the absence of data changes, after some period of time following the last update ('eventually'), all requests will return the most recently updated value.<\/p>\n

      <\/p>\n

      It's important to understand that for traditional databases, another approach commonly used is strong consistency<\/a><\/noindex>, where each node possesses the same information (this is often achieved when a transaction is considered committed only after a response from a second server). There are some relaxations due to isolation levels, but the overall essence remains the same \u2014 you can operate in a fully consistent world.<\/p>\n

      <\/p>\n

      However, let's return to the original task. If part of the system can be constructed using eventual consistency<\/a><\/noindex>, then the following scheme can be built.<\/p>\n

      <\/p>\n

      \"Convenient<\/p>\n

      <\/p>\n

      Key features of this approach:<\/p>\n

      <\/p>\n