Shulou(Shulou.com)06/03 Report--

This article mainly explains "how to understand microservices". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "how to understand microservices".

Preface

As organizations begin to build more complex applications, the practice of writing single applications becomes more and more problematic, and microservices emerge as the times require.

Traditionally, applications are built as monomers, with all the code concentrated in a large code base. Because there is no clear distinction between different functions, updating parts of the application may inadvertently affect completely unrelated features. Even if you make simple changes, you must redeploy the entire application, and if something goes wrong, everything will be affected, not just the components to be updated or extended.

To solve this problem, we can solve this problem by splitting the single architecture into modules (semi-independent components). Although it may be much simpler than implementing microservices, it has never really become popular.

Service-oriented architecture (SOA) attracts a lot of people, but largely fails, mainly because it leaves many unresolved problems, such as how to split services correctly. Microservice-based architecture is a more illustrative type of SOA that originates from real-world use cases and has been successfully adopted by many organizations.

Micro-service is just a modular architecture, in which different modules communicate through the network.

What is a microservice?

Microservices are small autonomous application components that work together to form an application. They inherited the basic operational model from SOA, but extended it in a more illustrative way. Microservices are often thought of as a separate part, maintained by a team.

Why is microservice important? As you can see from the above, to update the application, we can update and deploy the microservice independently without having to redeploy the entire application. They also allow a single micro-service team to focus entirely on a single business process without knowing the entire application.

To do this, the microservice has the following properties:

Loose coupling: each service is autonomous and can only be loosely connected to the rest of the system. This means that it has its own lifecycle and can be deployed, updated, extended, and deleted independently.

High cohesion: code with related behavior is grouped together. By grouping all related behaviors together, engineers update the code in one place only when they need to change a specific behavior.

Information hiding: each microservice shares only the data needed by other services and hides only the data related to its own process. Data sharing can inadvertently lead to coupling, so always be cautious.

In order to act as a cohesive application, all these different autonomous services communicate through a network interface. This brings new challenges to a large number of communications. By the way, this is where the service grid comes into play.

Now that we know what microservices are, let's explore why organizations adopt microservices.

Benefits of microservices

Whether it is to solve "developer problems" by aligning services with the team, or to reduce the risk of adopting new technologies, or to reduce deployment complexity and improve scalability, the adoption of micro-services brings many benefits. Let's take a closer look:

Autonomous teams: microservices allow small teams to fully own the entire lifecycle of the service. This can improve responsibility, code quality and job satisfaction. For most large organizations, this "staffing" is one of the main reasons for adopting the micro-service approach.

Technical heterogeneity: developers can theoretically build each service using different languages and different technologies. This enables developers to choose the best technology for that particular service, rather than a more traditional, standardized, one-size-fits-all approach.

Reduce the risk of adopting new technologies: developers can also experiment with new technologies in low-risk services because they know that something is wrong and will not affect the rest of the system. Since risk is the biggest obstacle to the adoption of new technologies, this is a huge advantage.

Resilience: when a component fails, it does not necessarily affect the rest of the system. Note, however, that the application is resilient only to the extent allowed by its architecture. Without good code practices (such as tracking, observability, and fuse wit), minor failures can still be cascaded in complex systems.

Extensibility: to extend any function, you only need to extend the microservice, not the entire single application.

Easy to deploy: if you update a line of code, you only need to update and redeploy that particular microservice, rather than redeploy the entire single application. In contrast, it is much easier to roll back the service than to roll back the entire application. Tools such as Docker and Kubernetes have greatly reduced the cost of deployment and rollback.

Replaceability: it is much easier to replace micro-services in an application than components in a single application.

Best practices for microservices

As mentioned above, one of the reasons why SOA implementations are difficult is that they lack guidance to define service boundaries. Let's see how microservices can solve this problem.

Define service boundaries

Each microservice has specific functions that are modeled around the business domain, which solves specific business problems. For example, with Gmail, the area of business includes all the functions that enable people around the world to communicate via e-mail.

A business domain consists of multiple limited contexts: code related to the same application behavior. Gmail has a variety of functions, including text editing, sending and receiving, archiving, searching, and so on, all of which may form such a context.

Note, however, that the relevant behavior does not necessarily correspond to the function.

highly autonomous

The decoupling system is to be able to change each part of the system independently without affecting the rest of the system.

The less services know each other, the more autonomous they become. Greater autonomy brings greater flexibility. Ideally, if one service crashes, other services will still be able to provide a degraded version of the application.

Although the decoupling system is the ultimate goal, 100% decoupling can not always be achieved.

Network communication

Microservices communicate over the network through their application programming interface (API). To send and receive messages, they must agree on network communication rules. You may be familiar with HTTP, and there are more such protocols.

According to the way of network communication, they can be roughly divided into synchronous or asynchronous communication.

Synchronous mode: client requests require an immediate response from the server and may even be blocked by waiting.

Asynchronous mode: client requests do not block processes, and server responses can be non-immediate

Synchronization is a bit like a landline. Establish a connection and exchange information, and you cannot answer other calls when you connect. This type of communication is usually used with request / response messages, where one service sends a request and waits for another service to respond. While waiting, both services are blocked. As you can imagine, this is only feasible if the connection speed is very fast.

Asynchronous communication is more like e-mail. If you send an email to someone, you can usually continue with other work. After receiving the reply, you will participate again. This is the essence of asynchronous communication: the service sends a message and continues to perform all its operations until a response is received. This method of communication is usually used when the network is unreliable or the physical distance is long. It is usually used with the publish-subscribe (or pub-sub) pattern, in which a service publishes an event and people who subscribe to the event are notified.

The use of that kind of network communication depends on the actual business scenario.

When should I use microservices?

It takes a lot of effort to develop and maintain micro-services than to deal with single applications. We have seen many powerful advantages of microservices, but is this always the best approach? No, developers should prefer monoliths unless they have compelling reasons to do so.

According to experience, small applications for small teams are best based on a single architecture, while large applications developed and maintained by multiple teams at the same time prefer a micro-service approach. Organizations should start with single applications, which can be subdivided into micro-services when scalability, performance, or resiliency benefits are needed. When it needs to be split will largely depend on your use case. There is no panacea. You must make a decision after careful consideration.

What you can do as soon as possible is to maintain a clean and modular code base. When you start running and extending applications, this will make it easier to build and extend, and it will reduce your cost and effort when you break down individual applications into micro-services.

Combine container and Kubernetes

As shown in the figure above, each microservice is placed in a container, a novel packaging mechanism whose concept is similar to the Ultra lightweight Virtual Machine (VM) and helps to separate the microservices (note that although containers are conceptually similar to VM, they do not provide the same isolation or security guarantees). Although microservices are earlier than containers, containers make microservices simpler and more cost-effective.

Kubernetes manages your containerization services to make sure they have sufficient resources and are functioning properly. It acts as some kind of data center operating system for the container.

In short, microservices contain business logic, and the code provides business value. Containers help package micro-services so that they are separated from the rest of the system. Containers and Kubernetes simplify the packaging and management of microservices and are one of the reasons why microservices are so popular.

Conclusion

Although microservices provide more flexibility and incredible power than monolithic architectures, these benefits come at the expense of complexity. Organizations must carefully consider whether the micro-service approach is suitable for them.

In microservices, you will hear more and more about containers and Kubernetes. This is because they are important technological innovations that can provide great value to micro-services. Today, most organizations that use microservices use containers and Kubernetes to manage it.

Thank you for your reading. the above is the content of "how to understand microservices". After the study of this article, I believe you have a deeper understanding of how to understand microservices, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.