Copyright belongs to the author, any form of reprint please contact the author to obtain authorization and indicate the source.
What is architecture
Architecture has long been regarded as a synonym for advanced technical people, but it is difficult to judge what is architecture and what makes an architect a good architect. However, to improve architectural capabilities, it is not enough to rely on the code level alone. Code can only help us solve execution problems, but the height of architecture depends more on strategic (business insight) and tactical (technical vision) problems.
But at what level is the height of architecture? The height of the architecture (both architectural strategy and architectural techniques, also known as architectural patterns).
In the design of an architecture, a complete solution is usually required to solve practical problems, including the selection of appropriate system architecture form according to specific business scenarios; How to design and implement the selected architectural form; In this if there is difficulty how to deal with the compromise; The architecture of the system if the online operation of the problem how to solve… And so on a series of issues are at the beginning of the architecture design should be considered. This requires the architect’s architectural pattern to support it. In fact, behind the architecture, more is thinking, thinking about why the design is so, why other solutions are not elegant and inappropriate and so on a series of why.
Therefore, if you want to do a good architecture, it is necessary to have absolute theoretical support and actual project architecture practice. Refuse to cheat, refuse empty theory, empty concept.
Conclusion:
Architecture complete solution
- Specific Service Scenarios
- How to choose the architecture
- How to design the architecture
- How does the architecture compromise
- How to solve architecture online problems
Philosophical thinking behind architecture
- Why is it designed this way
- Why aren’t the alternatives elegant
Architectural practices
- Reject empty theory, empty concept
- Experience in actual project architecture implementation
- Refused to fool
There are three stages of Internet development
In the development of the Internet, we are going through these three stages: PC Internet in the past, mobile Internet now and Internet of Things in the future.
In the late PC Internet, early mobile Internet era, that is, the era of interaction 2.0. At this stage, interaction is the core, and the representative products are Weibo and Twitter. These products have “attention”, because “attention” creates interaction, network effects, and the more people talk, the more people watch, and vice versa. This makes the network because of “attention” this mechanism has a possibility of its own growth, an opportunity.
In the late period of mobile Internet, temporarily called interactive 3.0 era, the one-to-one relationship has been transformed into a broader many-to-many relationship because of “attention”, forming a real interactive network form, and people and information are online. The more the network is woven, the more dense, with a more efficient way to achieve the original difficult to achieve the function, network civilization once again progress.
The future of the Internet of Things will bring bigger skies and more incredible lifestyles.
In this process, the characteristics of Internet development become more and more obvious, such as:
- Business functions are becoming more and more complex
- The Internet of Everything is getting bigger and bigger
- More and more requests, higher user experience requirements
- Rapid business iteration, continuous delivery ability, etc
The evolution of Internet architecture
Monolithic architecture,SOA architecture, microservices architecture, distributed architecture, cluster architecture
Single architecture design and practice
A single schema is typically a plain Java WAR file with a single hierarchy of Java code directories inside. The architecture diagram of a single architecture system is roughly as follows:
- Development of simple
- The test is simple
- The deployment of simple
- Simple scale structure
What if a single architecture can’t handle the higher pressures? The expansion of the singleton architecture is to use Nginx as a reverse proxy to send requests to other singleton applications based on different load balancing strategies. The application of a single architecture is a WAR package deployed on Tomcat. Expansion only requires another machine to deploy the WAR package using Tomcat, as shown in the figure:
- Projects with simple business scenarios, uncomplicated functions, and fewer r&d personnel
- Early stage of startup
- Performance requirements are extremely demanding
Having said some advantages of monomer architecture, there are also some disadvantages of monomer architecture:
- System coupling degree is high
- Single technology selection
- Development is becoming less and less efficient
As the system has been used for longer, the company has grown faster and faster. The amount of data and page views of the system are also increasing. How to solve this situation?
- For databases, there are both vertical split (library split) and horizontal split (table split) solutions
- There are also concepts of vertical split (business dimension) and horizontal split (functional dimension) for systems
Horizontal layered architecture design and practice
The horizontal hierarchical architecture is to physically divide the system into multiple processes to run horizontally, and each layer has its own logic to achieve logic decoupling. For example: gateway layer, business logic layer, data access layer, data storage layer. The following is a horizontal hierarchical system architecture diagram:
- Separate pages display services
- A separate gateway service
- A separate business logic service
- A separate data service
- Separate services according to system functions (similar to the division of functional departments in a company)
There are also problems with technical options when designing based on a horizontal layered architecture. The following diagram shows a gateway layer technology options versus dimension diagram, as well as other technology options versus dimension diagrams:
The basic functionality that the business logic layer should have
- Business logic judgment
- Realize different functions according to different logic
The basic functionality that the data access layer should have
- Add, delete, modify and query interfaces for CRUD services
- ORM framework
- Sharding supports separate databases and separate tables
- Mask underlying repository differences (redis/mysql/mongodb)
- The aggregation for the above functionality can be replaced with NewSql
Horizontal hierarchical architecture solves some problems, but it is still a synchronous architecture. In order to improve the processing capability of horizontal architecture, it can be transformed into a horizontal hierarchical architecture of asynchronous architecture, as shown in the following figure:
Design considerations for horizontal layered architecture
Design too much
- The request path becomes longer
- The average response delay becomes high
- The localization problem becomes more complicated
- Increased operation and maintenance costs
Design is too little
- It is basically similar to a single architecture
Reasonable and moderate design
- Synchronous Architecture (Four layers)
- The gateway layer
- Business logic layer
- Data access layer
- Data storage layer
- Asynchronous architecture (five layers)
- The gateway layer
- Asynchronous message queue layer
- Business logic layer
- Data access layer
- Data storage layer
Even with the use of horizontal hierarchical architecture, there are still disadvantages, such a hierarchical approach is too coarse granularity, let’s take a look at the overall picture of the final horizontal hierarchical architecture
Service-oriented Architecture design and practice
For details, see Service-oriented distributed Architecture (SOA)
Microservice architecture design and practice
Refer to microservices architecture design
Microservices architecture has its pros and cons, and bad design can cause problems. Because the business in microservices is concerned with the “communication” of the service office, business iteration needs the support of multiple businesses, resulting in slow business iteration speed. Upgrade of infrastructure components is difficult, affecting delivery capacity and delivery speed; Problems between multi-language communication, business services each language a set of infrastructure, the cost is large.
Below is a graphic illustration of the above questions:
Service grid architecture design and practice
Refer to Service Grid Pattern: Service Mesh
Application A deployment on one machine, the same sidecarA also deployed in this machine, sidecarA is infrastructure components, it implements the service discovery, configuration management, current limiting fuse, the various functions of service governance, which makes the application no longer focus on service governance related code implementation, only need to pay attention to the implementation of the business code, Separation of concerns (which needs to be considered simultaneously in microservices architecture). For example, the retry policy, registry and service invocation routing rules need to be modified to take effect in the microservice architecture. However, in the service grid architecture, only technical infrastructure components need to be modified and updated without affecting the business function code.
The following is a service grid architecture diagram:
- Request: Application A sends reQ to SidecarA, SidecarA sends REQ to SidecarB, and SidecarB sends REQ to application B
- Response: Application B sends resP to SidecarB, SidecarB sends RESP to SidecarA, and SidecarA sends RESP to application A
- Service Mesh Process and upgrade independently
- The business team focuses on the business logic itself
- An infrastructure to support multilingual development
- Business teams and infrastructure teams are decoupled
Technical framework for Service Mesh
| The framework | Development of language | Development co. |
|---|---|---|
| Linkerd | Scala | Buoyant |
| Conduit | Rust | Buoyant |
| Envoy | C++ | Lyft |
| Nginmesh | Go | Nginx |
| Istio | Go/C++ | Goole,IBM,Lyft |
Since Istio is all in one, here is an introduction to Istio. For more details, please refer to the Istio official documentation
Istio
The overall architecture
- The Istio service grid is logically divided into data panels (executor) and control panels (conductor)
- The data panel consists of a set of intelligent proxies that deploy sidecars to mediate and control all network traffic between microservices
- The control panel manages and configures agents to route traffic and enforce policies at run time
Data panel Envoy
- Dynamic service discovery, load balancing, TLS connection termination, HTTP/2 & gRPC proxy
- Fuse, health check
- Based on percentage flow gray scale, fault injection and enrichment indicators
- Envoy deployed as Sidecar, in the same Kubernetes pod as the corresponding service
Mixer
- Responsible for enforcing access control and usage policies on the service grid and collecting metric information from Envoy proxies and other services
- Central component
Pilot
- Pilot provides service discovery for sidecars
- Traffic management features of intelligent routing (e.g. A/B testing, Canary deployment, etc.)
- Elasticity (timeout, retry, circuit breaker, etc.)
- Loose coupling allows Istio to run in multiple environments (for example… Kubernetes (Consul/Nomad)) also maintains the same operator interface for communication management
Citadel
- Provides powerful inter-service authentication and end-user authentication, using built-in identity and certificate management
- It can be used to upgrade unencrypted traffic in the service grid, and non-operators provide the ability to enforce policies based on service identity rather than network control
- Starting with version 0.5, Istio supports role-based access control to control who can access your services
Flow control
- Request routing
- Request Routing
- Version control V1/V2
-
- Service discovery and load balancing
- There are three load balancing modes: polling, random, and weighted minimum requests
- When the number of health check failures for a given instance exceeds a predetermined threshold, it is ejected from the load balancing pool. When the number of health checks exceeds the threshold, the instance is added back to the load balancing pool
-
Flow control/troubleshooting
- Envoy offers a set of out-of-the-box, opt-in failover features that can benefit your application. Features include:
- timeout
- Limited retries with timeout budget and variable jitter between retries
- Limit the number of concurrent connections and upstream service requests
- Perform active (periodic) running health checks on each member of the load balancing pool
- Fine-grained fuses (passive health check) for each instance of a load balancing pool
Flow control/error injection
- Mismatched fail-over strategies (for example, incompatible/restrictive timeouts across service invocations) can lead to persistent unavailability of critical services in an application, resulting in a poor user experience
- Two types of faults can be injected: delay and abort
- Latency is timing failures that simulate increased network latency or overload of upstream services
- An abort is a simulated crash of an upstream service. Abort is usually in the form of HTTP error generation or TCP connection failure
Hundred billion real case design and practice
This chapter explains the evolution of architecture from real cases, giving students more thinking.
Case one of horizontal hierarchical architecture
The push system maintained by “Baidu Space” is used to show friends’ news and serves baidu’s numerous product lines (such as Baidu Space, knowledge, experience, tourism, TING, IM, etc.). The following picture should be familiar to the post-80s and post-90s generation, which is Baidu Space at that time.
100000 QPS
100ms
If you were to design such a system, what would be the design difficulties?
- Whether the message content is Push or Pull
- The architectural pattern should be synchronous or asynchronous
Here is a brief overview of the architecture:
If many people are Posting content at the same time, the server takes time to process the content, but to prevent users from waiting too long, you can first save the content to the message queue, and then cache the content on the user client to notify the user of the success of processing. In this process, the downstream service server will fetch the content from the message queue and continue processing. If the processing fails, the client can be notified of the failure. If the processing succeeds, the user will not be notified. In order to improve the user experience and system processing capacity.
Case 2 of horizontal hierarchical architecture
Another example is the IM chat function in 58.com, which is used for users to communicate with merchants and obtain information. The system is shown in the figure below:
30 +Using a variety of development languages, such as Java/Go. Request in1 billion (IM)and3 billion (not IM)
100w+
If you were to design such a system, what would be the design difficulties?
- How to solve the problem of millions being online at the same time
- Choose synchronous or asynchronous architecture patterns
Here is a brief overview of the architecture:
Because IM design for asynchronous is too complex, considering IM chat real-time, adopt synchronous horizontal hierarchical architecture; How to maintain millions/tens of millions of connections will be covered later.
Case three of microservices Architecture
- The gateway to a
- Business logic layer one (business code aggregated in one project)
- Multiple data access layers
- DB/cache multiple
Here is a brief overview of the architecture:
- The granularity of the amateur logic layer is coarse-grained, with all business logic coupled within a physical process
- Late development iterations are inefficient
So how can these problems be solved? Consider using vertical split (business dimension) for further system architecture optimization. The case of four
Case 4 of microservices Architecture
Combined with the case 3 of microservice architecture above, the business logic layer is split into multiple independent dimensions of business logic layer services according to the concept of vertical split, each using different physical processes, as shown in the figure:
- There is relational coupling between common logical layers, and each business has similar code for other services
So how can these problems be solved? The business logic layer can be further optimized by using component-based dependent JAR package approach, extracting common parts and sinking them into independent services, providing compatible interfaces and using horizontal split (functional dimension) strategy.
Microservice Architecture & Case 5 of Service Mesh
Finally, it can be seen that the split common logic layer also forms a service process, sinking between the business logic layer and the data access layer, which can not only reduce the problem of mutual call cycle dependence between the business logic layer and the same level, but also better remove the redundant code. Combined with the Service Mesh architecture, the result is a more powerful and efficient software architecture.
Below is a simple overall architecture diagram:
Expand the knowledge
- HTTP/HTTPS
- TCP
- Protobuf learning
- High reliability calculation of the system
Homework thinking
For the content of this article, consider the following requirements for gracefully implementing the microservice architecture in the business line of your own company:
- Select a specific business scenario, and give the specific solution of micro-service splitting;
- The reasonable system architecture design is given on the basis of splitting;
- The function flow chart of each microservice is given, and the detailed interface design is given.
- The framework selected for each microservice is given.
- Provide a high availability solution with at least 4 nines for each microservice;
- The service governance scheme and rapid deployment scheme of microservices are given.
