This is the 24th day of my participation in the August Text Challenge.More challenges in August

🌈 Past review

Thank you for reading, I hope to help you, if there is a flaw in the blog, please leave a message in the comment area or add my private chat in the home page, thank you for every little partner generous advice. I’m XiaoLin, a boy who can both write bugs and sing rap

• 💖10 minutes to RocketMQ! You can’t even get into Ali? 2 ️ ⃣ 💖
• 💖10 minutes to RocketMQ! You can’t even get into Ali? 1 ️ ⃣ 💖
• 💖 5-minute introduction to custom images and installation software 💖Docker series

I. Micro services

1.1 introduction to micro services

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, Which may be written in different programming languages and use of different data storage technologies. —– The microservice architecture style is a way of developing a single application as “a set of small services,” each of which “runs in its own process” and communicates through a lightweight mechanism (usually HTTP resource apis). These services are “built around business functions” and “deployed independently” through fully automated deployment mechanisms. “These services are minimally centrally managed” and may be written in different programming languages and use different data storage technologies.

Microservices are an architecture that separates a single overall application into smaller, project-related independent services. A service typically implements a separate set of features or functions, including its own business logic and adapters. The correlation between microservices is achieved by exposing apis. These independent microservices do not need to be deployed on the same VIRTUAL machine, system, or application server.

1.2. Why microservices

1.2.1 monomer application

It’s good to have all the code in one project when a system is low volume, and then that project is deployed on a server. All services for the entire project are provided by this server. This is the single-machine architecture.

The advantages of single application are that the single architecture mode is easy to develop, test, deploy and run well at the very early stage of the project.

His shortcomings are also obvious:

1. Applications add more and more functionality over time, and eventually become huge, with a project likely to have millions of lines of code and cumbersome JARS stacked against each other.
2. Over time, the development efficiency is low and the code maintenance is difficult.
3. If you want to use a new technology, a new framework or a new language, it’s not possible.
4. Any module vulnerability or error will affect the application and reduce the reliability of the system.

1.2.2 Distributed

As Tomcat and MySQL are required to run the entire system, the processing capacity of a single server is limited, and 2G memory needs to be allocated to Tomcat and MySQL. As services become more and more complex, more and more requests are required. Memory is running low, so this is where distributed deployment is needed.

We make a request for comments that rely on components [Tomat and MySQL] that are distributed on two different servers. So it’s called a distributed system.

The biggest difference between distributed and monolithic projects is that distributed projects are deployed separately, such as placing databases on a separate server.

1.2.3, cluster

In fact, there are problems in the diagram above. For example, Tomcat has a single point of failure. Once the server where Tomcat is located goes down and becomes unavailable, we cannot provide services. So what is the cluster pattern?

When the single-machine processing reaches a bottleneck, you make several copies of the single-machine, thus forming a “cluster”. Each server in the cluster is called a “node” of the cluster, and all the nodes make up a cluster. With each node providing the same service, the processing power of the system is multiplied by several times.

But the question is which node will handle the user’s request? It is best to let nodes that are less loaded at the moment handle the load so that the pressure on each node is equal. To do this, a “scheduler” role is added in front of all the nodes. All requests from the user are sent to it first, and it then decides which node to process the request based on the current load of all nodes. This “scheduler” has an awesome name – load balancing server.

1.3 Evolution of system architecture

The evolution of the architecture is roughly as follows: single application architecture ===> Vertical application architecture ===> Distributed service architecture ===> Mobile computing architecture Microservice architecture ===> [unknown]

1.3.1. Single application Architecture

In the early days of the Internet, the general website application traffic was small, so only one application was needed, and all the functional codes were deployed together, which could reduce the cost of development, deployment and maintenance.

For example, an e-commerce system will contain many modules of user management, commodity management, order management, logistics management and so on.

We will make them into a Web project and deploy them to a Tomcat server.

His strengths are:

1. Simple project structure, small projects, low development cost.
2. The project is deployed on a node and is easy to maintain.

His shortcomings are also obvious:

• All functions are integrated in one project, which is difficult to develop and maintain for large projects.

• The project modules are tightly coupled with low single point fault tolerance.

• It is impossible to optimize and expand horizontally for different modules.

1.3.2. Vertical Application Architecture

As the number of visits gradually increases, a single application can only rely on the addition of nodes to cope, but it will be found that not all modules will have a large number of visits.

Take the e-commerce as an example, the increase of user visits may only affect the user and order module, but the impact on the message module is relatively small. At this point we want to add only a few more order modules, not the message module. At this point, the single application can not be done, vertical application came into being.

The so-called vertical application architecture is to break up an application into several unrelated applications to improve efficiency. For example, we can divide the single application of the above e-commerce into:

• E-commerce system (user management, commodity management, order management)

• Background system (user management, order management, customer management)

• CMS system (Advertising management marketing management)

In this way, once the user access becomes larger, it is only necessary to increase the nodes of the e-commerce system, without adding nodes of the background and CMS.

His strengths are:

1. System split achieves traffic sharing, solves concurrency problems, and can be optimized and scaled horizontally for different modules.
2. Problems in one system do not affect other systems, improving fault tolerance.

Disadvantages:

1. Systems are independent of each other and cannot call each other.
2. Systems are independent of each other, and there are repetitive development tasks

1.3.3 Distributed Architecture

As more and more verticals are applied, there will be more and more repetitive business code. At this point, we thought, can we extract the duplicate code, make a unified business layer as independent services, and then call different business layer services by the front-end control layer? This results in a new distributed system architecture. It will split the project into a presentation layer and a service layer, which contains the business logic. The presentation layer only needs to handle the interaction with the page, and the business logic is implemented by invoking the services of the service layer.

Advantages:

1. Extract common functions into the service layer to improve code reuse.

Disadvantages:

1. The coupling degree between systems becomes high, and the call relationship is complicated and difficult to maintain.

1.3.4 SOA Architecture

In a distributed architecture, when the number of services increases, problems such as capacity evaluation and waste of small service resources become obvious, a scheduling center needs to be added to manage the cluster in real time. At this point, SOA Service Oriented Architecture (SOA) for resource scheduling and governance (SOA) is key.

Advantages:

1. The use of registries addresses the automatization of invocation relationships between services

Disadvantages:

1. There are dependencies between services, and when something goes wrong it can have a big impact (service avalanche).
2. Service concerns are complex, operation and maintenance, test and deployment are difficult.

1.3.4. Microservices Architecture

Microservices architecture is a service-oriented architecture to some extent, with a greater emphasis on “clean uncoupling” of services.

Advantages:

1. Services are atomized and split, packaged, deployed and upgraded independently, ensuring clear task division for each microservice and facilitating expansion.
2. Microservices invoke each other using lightweight Http protocols such as RESTful.
3. Services have their own separate responsibilities and are loosely coupled to avoid service breakdown due to a module failure

Disadvantages:

1. The technical cost of distributed system development is high (fault tolerance, distributed transactions, etc.).
2. Service governance and service monitoring are key.
3. Multi-service o&M is difficult. With the increase of services, the pressure of O&M also increases

1.4. Problems to be solved by microservices

Microservices architecture is a simple way of breaking up individual applications into smaller services, each of which is a project that can run independently.

Frequently asked questions about microservices architecture

Once the microservice system architecture is adopted, it is bound to encounter the following problems:

• So many small services, how to manage them?

• With so many small services, how do they communicate with each other?

• With so many small services, how do clients access them?

• So many small services, once there is a problem, how to deal with themselves?

• So many small services, once there is a problem, how to arrange the wrong?

The above problems are beyond the reach of any microservice designer, so most microservice products provide components for each problem to solve.

1.5. Common concepts of microservices architecture

1.5.1 Service Governance

Service governance is the automatic management of services, the core of which is service registration and discovery.

• Service registration: A service instance registers its service information with a registry.
• Service discovery: Service instances obtain information about registered service instances through the registry and request them to provide services.
• Service culling: The service registry automatically removes problematic services from the available list so that they cannot be invoked.

1.5.2 service Invocation

In microservice architecture, there is usually a demand for remote call between multiple services. At present, the mainstream remote call technologies include RESTFul interface based on HTTP request and RPC protocol based on TCP.

• Representational State Transfer (REST) : This is a more standard and generic REPRESENTATION of HTTP invocation that is supported by all languages.
• Remote Promote Call (RPC) : an inter-process communication mode. Allows remote services to be invoked as if they were local services. The main goal of the RPC framework is to make remote service invocations simple and transparent. The RPC framework is responsible for masking the underlying transport, serialization, and communication details. Developers only need to know who provides what remote service interface and where to use it, and do not need to care about the underlying communication details and invocation process.

The difference between them is in connection:

Comparative study	RESTFul	RPC
Communication protocol	HTTP	Typically TCP
performance	Slightly lower	higher
flexible	high	low
application	Microservices Architecture	SOA architecture

1.5.3. Service Gateway

With the increasing number of micro-services, different micro-services generally have different network addresses, and external clients may need to call the interfaces of multiple services to complete a business requirement. If the client is allowed to directly communicate with each micro-service, it may appear:

1. The client needs to call different urls, which makes it more difficult.
2. In certain scenarios, cross-domain requests are a problem.
3. Each microservice requires separate authentication.

To solve these problems, API gateways were born.

API gateway face to face means that all API calls are unified access to the API gateway layer, from the gateway layer unified access and output. The basic functions of a gateway include unified access, security protection, protocol adaptation, traffic control, support for long and short links, and fault tolerance. With the gateway, each API service provider team can focus on their own business logic processing, while THE API gateway is more focused on security, traffic, routing, and other issues.

1.5.4 Fault tolerance of services

In microservices, a request often involves invoking several services, and if one of them is unavailable, without fault tolerance, there is a high risk of an avalanche of services becoming unavailable.

We can’t prevent avalanches, we have to be as fault-tolerant as possible. The three core ideas of service fault tolerance are:

1. Not affected by the outside environment.
2. Don’t be overwhelmed by upstream requests.
3. Not dragged down by downstream responses.

1.5.5 link tracing

With the popularity of microservices architectures, services are split along different dimensions, often involving multiple services in a single request. Internet applications are built on different sets of software modules, which may be developed by different teams, implemented in different programming languages, and spread across thousands of servers across different data centers. Therefore, multiple service links involved in a request need to be logged, and performance monitoring is link tracing.

1.6 common solutions of micro-services

1.6.1, ServiceComb

Apache ServiceComb, formerly huawei Cloud Service Engine (CSE) Cloud Service, is the first Apache top-level Service project in the world. It provides a one-stop open source solution for microservices, committed to helping enterprises, users and developers to easily microserve enterprise applications on the cloud, and achieve efficient operation and maintenance management of microservices applications.

1.6.2, SpringCloud

Spring Cloud is a collection of frameworks. It takes advantage of the development convenience of Spring Boot to subtly simplify the development of distributed system infrastructure, such as service discovery registry, configuration center, message bus, load balancing, circuit breakers, data monitoring, etc., which can be started and deployed with one click using Spring Boot’s development style.

Spring Cloud does not remanufacture the wheel. It just combines the mature and practical service frameworks developed by various companies and encapsulates them in the Spring Boot style, masking the complex configuration and implementation principles. Finally, a simple and easy to understand, easy to deploy and easy to maintain distributed system development kit was set aside for developers.

1.6.3, SpringCloud Alibaba

&nbspSpring Cloud Alibaba is committed to providing one-stop solution for microservice development. This project contains the necessary components for developing distributed application microservices that developers can easily use to develop distributed application services through the Spring Cloud programming model.