Tears, can’t bear to look back!

The blogger graduated 4 years ago, the recent autumn recruit began, every time back to their autumn recruit, all feel that their special pity (dish is the original sin), their resume at that time, the project above, only a agricultural materials e-commerce platform, then the second kill system is not so popular (resume per capita second kill system).

Your first micro interview

When his own eight-part text back is actually ok, but his project is just a stand-alone system, distributed? Micro service? What the hell? It was the second interview. In a hotel room, the interviewer looked at me with a smile and asked me to draw the agricultural materials e-commerce platform in my project first. My mind was buzzing. What, one Android, one front page, and one back?

It looks something like this

Let’s see, this is too simple, should I make it more complicated? Or, can I call this architecture? In this way, hesitate between, the wool did not draw… I remember drawing something like this. No surprise, it’s gone

This thing is a bit like four, do not say, shameful ~Copy the code

Second micro interview

The second micro audience interview, graduation has been nearly a year, holding a try mentality, looking for a senior sister within the push, at that time I do what? In the crawler. The company is close to the micro crowd, just in the kingdee side, after work to slip past, with the interviewer bar for a while, good guy, did not take out a piece of paper for a while:

Draw the architecture of your current crawler system!

The deployment architecture of the system looked like this, and it looked a little simpler than that.

But, I just can’t draw hand!! Thinking too simple ah!! Can you call this architecture?

Showdown! I can’t draw!

Now think of it, really too humbled, young ah! So if I look back now, how can I draw it?

Deployment architecture of a single system

Diagram of hierarchical architecture of crawler system

Business architecture of crawler system

Architecture diagram

From the above description of the architecture in all directions, in fact, even a single system can draw extraordinary architectural diagrams! (Why didn’t I?)

Recently, I was looking at architecture (Howie’s class). In the 4+1 view, we describe our system in many ways. Please refer to the following description.

What is the architecture of your seckill system?

Monomer system

No matter how awesome your resume is, I’m guessing most of your services look like this. If you’re right, check it out. Only the browser is distributed.

So how do I describe my monomer system?

Three principles of architectural design:

  • Simple principle
  • The principle of appropriate
  • Principles of evolution

Every principle is in line with our university’s seckill system!!

Principle of simplicity: One system can fulfill all the actions of our seckill service without too many middleware dependencies

Principle of appropriateness: In our practical projects, single systems are best suited. (basically have no money! Splitting services, introducing middleware, deploying clusters, all cost money!)

The principle of evolution: It makes sense that no system architecture is set at birth and evolves over time to meet business requirements.

Conclusion:

Advantages of our architecture: low cost, low system complexity, low maintenance cost, fast problem location

Disadvantages: poor stability, low concurrency, weak scalability, etc

Each solution has its own strengths and weaknesses when sorting through the architecture, so it’s important to understand the strengths and weaknesses of your current solution. In order to better show the interviewer your system!

Service split

Good guy, participated in a science and technology innovation competition, the funding is in place, can buy more machines, that should not optimize the service, split into a micro service system out!

What actions have we taken in this architecture of service fragmentation?

  • Static resource isolation (The CDN to accelerate)
  • Proxy server (Nginx)
  • Services are split and applications are deployed independently
  • Service RPC communication (RPC framework & Registry)

1. Separation of front and rear ends

In a single system, our static resources (Html,JS,CSS and IMG) may all be returned through our server, and the problem is:

  • The front endCode maintenanceHigh cost (full stack development costs)
  • Front-end code release requires the entire system to be released
  • The serverbandwidth.Request resourcesTake up etc.

Then the benefits of separating the front and back ends are clear:

  • Code is maintained independently (Low coupling), low release cost (High efficiency)
  • The front and rear ends interact with each other through interfacesDynamic data
  • CDN resourceAccess acceleration, reducing backend service stress (A high performance)

2, reverse proxy

The effect of the reverse proxy is obvious, because our services are split into multiple components, so we need to provide a common entry point for our interactions with the front end. This entry point is our reverse proxy server (Nginx). For example: the service domain name: https://www.jiuling.com, according to a restful specification, we can through https://www.jiuling.com/user/1.0/login will forward the request to the user login service interface.

3. Interprocess communication

With the separation of services, in the implementation of part of the function, will involve the invocation of services to each other, for example:

In a common implementation, we would use a registry and RPC framework to achieve this capability. Zookeeper & Dubbo are the most commonly used implementations.

Why use the RPC framework?

When we talk about using RPC framework, do we think about why we use RPC framework? Each service provides RESTful interfaces, so is it possible to communicate between services?

This is where the difference between RPC and RESTful comes in:

  • Small data packets & fast transmission efficiency:RPCSome necessary header information in the transport protocol is simplified, thus speeding up the transmission efficiency.
  • Low development cost: e.g.DubboFramework that encapsulates the logic of calls between services (e.g.reflection.To build theandTimeout controlEtc.), just need to develop the correspondinginterfaceandThe data modelCan.
  • Service governance: In the distributed scenario, we have more than one service provider, which involvesThe health service.Load balancingandService flow controlI need to deal with, and this part of the ability toRPC & RegistryAll have been met under the framework of.

After the advantages, let’s analyze the disadvantages of RPC:

  • Strong coupling: compared withRESTfulIn terms ofRPCFrameworks are difficult to implement in cross-language scenarios. andVersion depends onStronger. The service is out of the presentNetwork environmentAfter the migration, services cannot be provided and the migration cost is high.
  • Intranet call:RPCIt is more suitable for Intranet transmission, but less secure in the public network environment.

Distributed microservices

In the last version of service splitting, we divided multiple subsystems according to different business boundaries and functional responsibilities, and different systems were subjected to different load pressures. For example: The order service takes a long time to process each request (other services do not have much pressure), in order to increase our order volume, we can just expand the order service, this is the benefit of service separation, performance utilization increased!

From the figure above, we can see that some services appear different ghosting. Each square can be understood as a machine. In this architecture, in order to ensure our order success rate and order quantity, we mainly focus the server on order service.

Before that, let’s look at our middleware cluster deployment:

  • Mysql master/slave architecture: Separate read and write, reduce the pressure on the primary database, ensure that data can be written normally, and ensure that the order data falls into the database.
  • Zookeeper primary/secondary architecture: Ensures that the registry is available and avoids avalanche of the whole link.
  • Redis sentinel cluster: avoidredisThe outage caused a lot of traffic to be sent directly to the database.

summary

At this point, generally our own development system, also basically completed the evolution of the entire seckill system. Maybe everyone has been wondering why we are missing the most familiar MQ?

I’m going to talk about the architecture of this seckill system in terms of synchronous calls throughout the call link, because it satisfies our current traffic requirements, in terms of the architecture design principles referred to as the fit principle and the evolution principle. In the current situation of meeting traffic requirements, we need to think about the introduction of messaging middleware, what is the problem? What is the problem being solved? After weighing the advantages and disadvantages, it is time for us to decide whether to use this scheme or not.

A high performance

In the process of the evolution of architecture, we through service, vertical expansion, distributed deployment, improve the performance and stability of our architecture, for us since the research phase of the evolution of architecture is already enough for our traffic demands, but if we want to continue to optimize our system, improve service performance and can be optimized from the following several aspects:

  • Resources preheating
  • Cache warming
  • The asynchronous call

1. Resource preheating

In the above service split phase, we mentioned the separation of static resources, static resources here include: HTML, JS, CSS, IMG, etc. In the activity phase, we can warm up the static resources in the activity of goods and services to CDN through the background management system to accelerate the access to resources.

Resource preheating: the resource is loaded into the CDN in advance. Back to the source: When the CDN cannot find the resource, it will trigger the call of the source station (commodity service) to query the corresponding resource. If the resource exists in the source station, it will be returned to the CDN for caching. OSS: services for actual static storage resources. (For details, see Aliyun OSS.)Copy the code

As has been repeatedly mentioned above, when introducing a technology, it is necessary to consider both the advantages and disadvantages it brings. Then what are the risks of CDN?

  • The cost of: compare direct, get to spend money more namely!
  • bandwidth: In the case of heavy traffic access, can the CDN support so much bandwidth? The traffic that each server can support is limited, so it is necessary to consider whether the CDN can support the traffic of services.
  • CDN shooting: In the case of low CDN hit ratio, such asActivity photosWill change every hour, so each image replacement will triggerBack to the source operatingIn this case, the resource access efficiency decreases.

2. Cache warm-up

In contrast to the static resource acceleration above, dynamic data needs to be cached for performance optimization.

  • Single threading (Redis performance bottleneck is not there, so this is not an advantage)
  • Multiplexing I/O model
  • Simple data structure
  • Memory-based operation

Risks arising from the introduction of Redis include:

  • reidsBreakdown: In single-machine deployment, a large number of service calls time out, resulting in an avalanche of services. throughSentinel clusterOptimization.
  • Cache breakdown: Under large flow,A cache MISSandCache expirationCan cause requests to penetrate the database, causing an avalanche of services if the database can’t handle the strain. Can be achieved byBloom filterTo optimize.
  • Data consistency:Cache data with DBTo ensure data consistency, update policies are required.

3. Asynchronous invocation

Through the asynchronous way, the inventory of successful users, through the way of message, sent to the order service, the subsequent order operation. It can sell all the goods in a short time. The overall process is shown in the figure below:

Why does MQ asynchronous invocation improve the throughput of our service?

The main reason is that, with asynchronous invocation, we have completed the request processing by sending the message, and the performance bottleneck has shifted from the order service to the seckill service. Overall service throughput is improved by reducing invocation dependencies.

Common problems with MQ:

  • Data consistency
  • Repeat purchases: Repeated push of messages due to repeated delivery by producers or slow consumption. You need to keep the consumption normal by locking the consumption idempotent.
  • Messages are stacked: When the production capacity is much larger than the consumption capacity, message accumulation will occur.
  • MQ availability: In the case of MQ downtime, synchronous call switchover needs to be supported.

I won’t go into the details here; I’ll write an article about MQ later.

High availability

It’s not easy to see here. Thank you for your support. About usability here, have written before A # “high availability actual combat” -B station jump, close me A station what matter? Take a look if you’re interested.

High availability can be mainly from:

  • Dynamic capacity: Dynamically expands capacity for different services based on service pressure.
  • Current-limiting fuseRefer to my previous article:# High Availability Actual combat -B station jump, I A station what matter?
  • Different live: Multiple equipment rooms are deployed to avoidPhysical attacks!

City double live

Deploy the equipment rooms in different districts of the same city and use a private network to connect them. The distance between two computer rooms is generally tens of kilometers, and the network transmission speed is almost the same as the same computer room, which reduces the system complexity and cost.

This model cannot solve extreme disaster situations, such as an earthquake or flood in a city, but it is used to solve some routine failures, such as engine room fires, power outages, and air conditioning failures.

Different live

In the above model, there is no way to solve city-level service disaster, such as flood, earthquake and so on. This problem can be solved through the remote multi-live deployment solution.

But each scheme is the existence of advantages and disadvantages, so the disadvantages of remote live mainly reflected in the network transmission and data consistency of the problem!

The main problem is the network transmission delay. For example, when you travel from Beijing to Guangzhou, the round-trip Time (RTT) is 50 ms under normal circumstances. When you encounter network fluctuations, the RTT increases to 500 ms or even 1 second, and packet loss may occur. Physical distance will inevitably lead to data inconsistency, which has to be solved from the "data" characteristics. If the data requires strong consistency (such as the deposit balance), it is impossible to do remote multi-work.Copy the code

Pay attention, don’t get lost

Image address: draw. IO original

Well folks, that’s all for this post, and I’ll be updating it weekly with a few high-quality articles about big factory interviews and common technology stacks. Thank everyone can see here, if this article is well written, please three!! Thanks for your support and recognition. See you in the next article!

I am Nine ling, there is a need to communicate children’s shoes can pay attention to the public number: Java tutorial, master first-hand information! If there are any mistakes in this blog, please comment and comment. Thank you very much!