Microservices Architecture
Section 1 development of Internet Application architecture
With the development of the Internet, the user group is gradually expanding, the traffic of the website increases exponentially, and the conventional single architecture can no longer meet the request pressure and the rapid iteration of business, so the change of architecture is imperative. Let’s take the architecture evolution of dragnet as an example, from the single architecture analysis at the beginning to the current microservice architecture step by step.
1) Single application architecture
At the beginning of the birth, pull hook users, data scale is small, all function modules of the project in a project code, compile, packaged and deployed in a Tomcat container architecture model is the monomer application architectures, this architecture is simple real use, easy to maintain, and low cost, become the mainstream of the era architectural approaches
Advantages:
- The early stage of the project was fast-paced, and the team was able to iterate quickly when there were fewer team members
- Simple architecture: MVC architecture, only need to use IDE development, debugging
- Easy to test: just unit tests or browsers
- Easy to deploy: Start in a container packaged as a single executable JAR or as a war package
Disadvantages:
-
With the continuous function iteration, the single project is too large, the code is disorderly, and the coupling is serious. After the development team grows gradually, the communication cost becomes high. For example, the code takes 3-5 minutes from compilation to startup
-
New business difficulty: Adding new business and maintaining old functions in an already chaotic system is an unpredictable problem. It is difficult for a new employee to take over the task after he/she comes, the learning cost is high, and it takes about a week to get started
-
Core business and edge business mixed together, problems affect each other, such as: a temporary activity traffic surge, machine load will affect the normal business services
Application architecture further enrich change volume rise, monomer, such as the application of cluster deployment, using Nginx for load balancing, increasing cache server, file server, database cluster and separation of doing, speaking, reading and writing, etc., through the above measures to enhance its ability to cope with high concurrency and cope with some complex business scenarios, but still belongs to the monomer application architecture.
2) Vertical application architecture
In order to avoid the problems mentioned above, vertical division of modules was started. The principle of vertical division was based on the existing business characteristics. The core goal was first to prevent mutual influence between businesses, and second to improve efficiency and reduce dependence between businesses after the expansion of the RESEARCH and development team.
advantages
- System splitting implements traffic sharing and solves concurrency problems
- It can be optimized for different modules
- Convenient horizontal expansion, load balancing, improved fault tolerance rate
- The systems are independent and do not affect each other, making new business iterations more efficient
disadvantages
- Services call each other, and if a service’s port or IP address changes, the calling system must manually change it
- After cluster construction, load balancing is complicated, for example, Intranet load. When migrating machines, routes of callers are affected, leading to online faults
- Service invocation methods are not uniform, based on HttpClient, WebService, interface protocol is not uniform
- Service monitoring is not in place: there are no monitoring indicators, such as success rate, failure rate, total time, etc., other than relying on port and process monitoring
3) SOA application architecture
After the vertical division, module increases, the cost of maintenance in also get higher, some common business and module to repeat more and more, in order to solve the above mentioned interface protocols is not unified, service cannot be monitoring, load balance, the introduction of alibaba open-source Dubbo, a high-performance, lightweight open source Java RPC framework, It provides three core capabilities: interface-oriented remote method invocation, intelligent fault tolerance and load balancing, and automatic service registration and discovery.
Service-oriented Architecture (SOA) is a service-oriented Architecture. According to the actual business, the system is divided into appropriate and independently deployed modules, which are independent of each other (through Webservice/Dubbo and other technologies for communication).
Advantages: Distributed, loosely coupled, flexible extension, reusable.
Disadvantages: Large service extraction granularity, high coupling degree between service caller and provider (interface coupling degree)
4) Microservices application architecture
Microservices architecture can be said to be an extension of SOA architecture, which is less granular and more independent of services. The application is broken down into tiny services, which can use different development languages and storage, and often communicate with each other through lightweight services such as Restful. Microservices architecture is all about small, independent, lightweight communication.
Microservice is the sublimation of SOA with finer granularity. One of the key points of microservice architecture is that “business needs thorough componentization and servitization”.
Microservice architectures are similar and different from SOA architectures
An obvious difference between microservice architecture and SOA architecture is the difference in the granularity of service separation. However, for the development of pull-in architecture, the granularity of service separation we have seen in the SOA stage is relatively fine. Therefore, from the above pull-in SOA to pull-in microservice, there is not much change in service separation. It just introduces a relatively complete new generation of Spring Cloud microservices technology. Of course, what we see above are the results of the evolution of the pull architecture. Each stage has actually undergone many changes. The service separation of the pull architecture has actually gone from coarse to fine, not absolutely in one step.
Take a pull box example to illustrate the difference in granularity between SOA and microservices
In the early stage of SOA architecture, both “resume delivery module” and “talent search module” had the requirement of presenting resume content, but it may be slightly different. At the beginning, we maintained a set of resume query and presentation code in each module. Later, we split the service into a more fine-grained resume base service, which can be called by different modules
Section 2: Ideas and advantages and disadvantages of micro-service architecture
The core idea of microservice architecture design is micro. The granularity of separation is relatively small, so that single responsibility and development coupling degree will be reduced, small functions can be independently deployed and expanded, with strong flexibility and small impact range of upgrade
For example, we need to upgrade our application from 1.7 to 1.8. We have ABCDE.. And so on, we can independently upgrade A, and leave the other applications untouched
Advantages of microservices Architecture: Microservices Architecture and microservices (focus on architecture here)
- Microservices are small, making it easy to focus on A, B, C, and D for specific business functions
- Microservices are small, and each microservice can be independently implemented by a small team (development, testing, deployment, operation and maintenance). The team cooperation is decoupled to a certain extent, which facilitates the implementation of agile development
- Microservices are small, facilitating reuse and assembly between modules
- Microservices are very independent, so different microservices can be developed in different languages and loosely coupled
- With a microservices architecture, it’s easier to introduce new technologies
- Under the microservice architecture, we can better realize the integration of DevOps development, operation and maintenance.
Disadvantages of microservices architecture
- In microservice architecture, distributed complexity is difficult to manage. When the number of services increases, management will become more complex.
- Distributed link tracking is difficult under microservice architecture.
Section 3 some concepts in microservices architecture
Service registration and service discovery
Service registry The service provider registers/enlists information about the services it provides (server IP and port, service access protocol, and so on) to the registry
Service discovery Service consumers can obtain a relatively real-time list of services from the registry and then select a service to access based on certain policies
process
- Service providers register their services in service registries, and in the case of multiple clusters, there will be multiple services
- When a service consumer wants a feature, it gets the list of services from the registry
- After the service consumer obtains a service address, it selects the service instance to invoke
Load balancing
Load balancing distributes the request load to multiple servers (application servers, database servers, etc.) to improve service performance and reliability
Common load balancing algorithms
- polling
- random
- Hash based on Ip
- Distribute according to machine load
- Consistent Hash algorithm
fusing
Fusing is circuit breaker protection. In microservice architecture, if downstream services respond slowly or fail due to excessive access pressure, upstream services can temporarily cut off calls to downstream services to protect the overall availability of the system. This measure of sacrificing part while preserving the whole is called circuit breaker.
For example, the most downstream service C responds very slowly, causing the whole link to die. In this case, the circuit breaker kills service C
The link to track
Microservice architectures are becoming more and more popular, and a project is often split into many services, so a single request requires many services. Different microservices may be developed by different teams, implemented in different programming languages, and the entire project may be deployed on many servers (even hundreds or thousands) across multiple data centers. Link tracing is to log and monitor the performance of many service links involved in a request
- Taceid runs throughout
- Spanid Id in the current service
- What is the last service ID of parentId
API gateway
Under the microservice architecture, different microservices tend to have different access addresses. The client may need to call the interfaces of multiple services to complete a business requirement. If the client is allowed to communicate directly with each microservice, it may appear as follows:
- Clients need to call different urls, which makes maintenance calls difficult
- In certain scenarios, there is also the problem of cross-domain request (cross-domain problem will be encountered when the front and back end is separated. Originally, we can solve the problem by using Cors at the back end, but now we use gateway, so put it on the gateway layer)
- Each microservice requires separate authentication
Then, THE API gateway can better deal with the above problems in a unified way. The API request calls the unified access API gateway layer, and the gateway forwards the request. The API gateway is more focused on security, routing, traffic, etc. (the microservices team can just focus on business logic), and its features include
- Unified Access (Routing)
- Security protection (Unified authentication, responsible for gateway access authentication, communication with the Access Authentication Center, and actual authentication service logic transferred to the Access Authentication Center)
- Blacklist and whitelist (control access to the gateway by IP address control function)
- Protocol adaptation (to implement communication protocol verification and adaptation conversion)
- Traffic Control (Traffic limiting)
- Long and short link support
- Fault tolerance (load balancing)
