Architecture related knowledge, I wonder how much attention you usually have? In my own words, there was a little bit less attention to this.

But these things are important in my opinion, when we do the test cannot be a head into the business, if we can on the architecture of the whole system have a macro understanding, I believe, for you testing, performance testing at the back of the business, or job interview (don’t ask me how I know, eaten kui o (╥ man ╥) o), would be helpful.

Today, LET’s take a look at the evolution of the architecture.

One, monomer application

Single application, in fact, no matter what functions are written in an application, such as user functions, commodity functions, order functions, etc., common in the e-commerce system.

Now I recall that when I first started in the industry, the system I tested was such a single application.

It is a “big” project for ZF. The name is really big, and the cost should be tens of millions.

Although the project is “large”, the construction period is tight and manpower is limited. Because the company is a state-owned enterprise and there are very few formal pits, I became one of them and the only tester by chance. When people were needed, contractors were hired to develop and test with them.

So in this case, the advantages of monomer application come into play:

  • Simple and crude, all functions packaged together, directly deployed.
  • Local debugging is convenient, directly start the whole project, debugging is in a process, there is no lengthy call chain, convenient to quickly locate bugs.
  • Local function calls without the overhead of network calls.
  • If you have a problem you can quickly roll back because there’s only one application.

But in retrospect, the downsides of this monomer application are obvious:

  • System coupling is high. When more and more functions are added later and the amount of code increases greatly, the module boundary demarcated in the mind of a main program may become more and more fuzzy, leading to confusion in the call relationship.
  • There are more and more changes in one to give two, often there is a change in the development of a feature, and lead to problems with other features.
  • If one function fails, the whole thing rolls back.
  • Single language, can not choose a more appropriate language according to the scene. For example, there is a module system focused on big data analysis, which is more appropriate in Python because it has a rich class library.
  • The overall availability of the system is not high, and the failure of a function may affect the operation of the entire system.
  • The system is not easy to expand deployment, for example, there is a function in the system traffic is heavy, can not withstand the machine, then deploy the whole application on the new machine, can not independently deploy the heavy traffic service, will cause a certain waste of resources.

Note that a single application does not mean that the application is deployed on only one online server. There are usually multiple applications. Otherwise, only one server will fail completely.

Second, micro-service architecture

With the development of the business, a single application can no longer meet the current requirements. Therefore, functions that were previously combined are separated into independent services.

What are the advantages?

  • The coupling degree is reduced, the function boundary of the module is clear, and the module is physically isolated according to the service.
  • Diversified technology selection, you can choose the most appropriate scheme
  • It can be independently expanded according to the service, and other unnecessary items are still kept as is, and resources are rationalized.

Looks perfect. Solves the pain point of the monomer. But there are new drawbacks:

  • Changes involving multiple services are complex and need to be considered. Determine the sequence and rollback scheme of each service before making services online.
  • Problems may involve rolling back multiple services that affect each other.
  • Instead of single application invocation, multiple applications now interact directly. The invocation link becomes longer, bringing network overhead and increasing difficulty to locate problems.
  • In addition, in order to make your application more reliable, there are other exceptions to consider, such as call failures, high frequency calls due to certain problems, such as limiting traffic, circuit breakers and so on.
  • There are many more……

Third, the SOA

When it comes to microservices, SOA is also mentioned.

SOA is a service-oriented architecture idea, but microservices are the same, with a slightly different emphasis:

  • Microservice architecture refers to the idea of extracting public services from the system and managing them separately.
  • SOA architecture refers to the architectural idea of breaking up services and unifying access to service interfaces.

The SOA architecture embraces the idea of microservices.

Distributed and clustered

These 2 as long as clear good concept naturally remember.

  • Distributed: Two different components cooperate to provide services externally. In fact, we often say that the separation of the front and back end is such, the front-end JS code runs in the browser, the back-end code runs on the server. And that’s also true for our system.
  • Cluster: Usually refers to the existence of multiple instances of the same component, forming a logical whole. For example, if I have a user service, but I have multiple servers running this user service, it is a cluster.

Typically, distribution involves clusters.

Finally, this article refer to the following: www.cnblogs.com/dw3306/p/14… Zhuanlan.zhihu.com/p/181161035 B station: meet crazy god said