The original address: microservices. IO/patterns/mo…

Scene description

Suppose you are developing a large server-side enterprise application with the following requirements:

  • Multiple clients must be supported, including WEB browsers, WAP browsers, and native mobile apps.
  • Expose the public API for calls
  • Process HTTP requests, or messages, and perform the corresponding business logic.
  • Access the database, cache or persist the response data
  • Communicate with other systems to exchange needed information
  • Returns an HTTP response, specifying a specific serialization method, such as JSON, XML, and so on
  • According to business logic and function, different logic modules are designed and divided

How would you architecture and deploy such an application?

consideration

  • This is a team project, with an independent team in charge
  • Team members change, and new members have to pick up the project quickly
  • Applications must be easy to understand and modify
  • Continuous integration and deployment of applications are expected
  • The application must be able to deploy multiple instances to meet scalability and availability requirements.
  • Want to use newer technologies (frameworks, programming languages, etc.)

The solution

Use a singleton architecture, for example:

  • A Java WAR file to start the program
  • A single-directory Rails or NodeJS program

For example,

Suppose you are designing an e-commerce application that accepts orders from customers (StoreFrontUI), verifies and maintains Inventory Service, verifies and maintains user available balance (Accounting Service), The order is successfully placed and shipped. The application is designed as a single architectural application, for example: a JavaWeb application consists of a single WAR file running on aWeb container such as Tomcat. Rails applications consist of a single directory hierarchy of JRuby or Nginx deployed on Either Nginx or Tomcat. Multiple instances can be deployed behind a load balancer to extend and improve availability.

Analysis of the

The benefits of this solution include:

  • Development is simple, the current IDE is basically according to the development of single application development.
  • Deployment is as simple as deploying a file or directory into a Web container.
  • Capacity expansion is simple. You can expand capacity by deploying multiple instances behind load balancers.

However, as the product iterates and the monolithic application gets bigger and the team size gets larger, the monolithic design has some drawbacks that become more severe:

  • Single application code in the same codebase, the codebase can get bigger and bigger for developers, especially those who are new to the team. Applications will be difficult to understand and modify, and as a result, development will often be slowed down. In addition, because there is no clear module boundary, modularity within code can become more and more ambiguous over time. In addition, because it’s hard to understand how to implement changes correctly, and you may need to accommodate bugs from older versions, the quality of your code can degrade over time, slowly accumulating into a mountain of shit.
  • The IDE can be very stressful. The larger the code base, the slower the IDE, which indexes and loads the code into memory for intelligent completion. Bloated code can slow down the IDE and reduce development efficiency.
  • The Pressure of the Web container increases. The more bloated the program, the longer the startup time, the slower the code debugging, and the longer the deployment time.
  • Continuous integration deployment is increasingly difficult. To update a component, you must redeploy the entire application. This causes all services, whether updated or not, to be affected or interrupted. At the same time, if something goes wrong, the rollback time increases. As a result, this limits the ability of the program to constantly update frequently.
  • It cannot be flexibly extended. Different service modules may have different pressures and have different periods of high pressure. However, each expansion requires the expansion of all modules, resulting in waste.
  • Fault diffusion. If one module fails and leaks memory, the entire business suffers.
  • Barriers to team division. For example, we might want to have a UI team, an accounting team, an inventory team, and so on. The problem with monolithic applications is that it prevents teams from working independently. Teams must coordinate their development efforts and redeployment. It is much more difficult for a team to make changes and update production.
  • You need to use the same technology stack for a long time. A single architecture forces you to align with the technology stack (and in some cases, with a specific version of that technology) that you chose at the beginning of development. With monolithic applications, it is difficult to gradually adopt a newer technology. For example, if the framework you are using stops updating or becomes outdated, it is difficult to phase in a new framework implementation in a single application.