Talking about the understanding of microservices

Introduction

The rise of microservices has been around for many years, and in recent years it has reached a stage of great development. The company has done a lot of things related to microservices, and I have also read some content related to microservices. Now let's get to know the three words "microservices" again, and finally I feel a little understood.

What I have seen during my study

1. Microservice design
2. The cornerstone of cloud native distributed storage: etcd in-depth analysis
3. Docker technology introduction and actual combat
4. Play Kubernetes in 5 minutes a day
5. Listen to the wind
6. Learn microservices from 0

Reason

Why do microservices appear? I think this is the inevitable result of the development of the Internet.

Just like when there was no IOS seven-layer model before, when programmers did programming, they needed to do what the seven-layer model did by themselves. Every programmer had to do this, which caused a lot of waste of resources, and everyone did it. The effect is hard to say perfect. Then the IOS seven-layer model appeared. A unified specification helped programmers complete repetitive tasks, which greatly improved development efficiency.

From this point of view, microservices do the same thing.

After decades of development of the Internet, the head company is huge and encounters a lot of problems, and every enterprise may encounter these problems. In many things, everyone is reinventing the wheel, and in many cases it may not be very good. On the basis of absorbing good practices, the experts combined with their extensive knowledge to promote the development of microservices.

At present, it is difficult to form a unified standard for microservices. First, from the perspective of the entire development stage, it is still in the early stage, and there are not a large number of relevant microservice talents. Second, each company's own business conditions are different and it is difficult to completely unify. However, microservices have actually become a prairie fire. In the near future, it may become easier to start an Internet company. Microservices will be like TCP/IP, which is completely transparent to developers. Developers only need Just focus on the development of business logic. Of course, the premise is that the programmer's words are needed to develop to this stage.

Developing such a universal microservice platform is also a very good entrepreneurial direction.

Therefore, as a contemporary programmer, learning microservices is still necessary. This is an inevitable trend and can also increase your own competitiveness. If one day, microservices are as transparent as TCP/IP, people who understand the core principles of microservices will still be more valuable. After all, only these people can solve some magical problems at that time.

system

The water of microservices is quite deep, to be precise, not only deep but also very wide. Microservices involve a lot of content, and each area can be studied in depth to become an expert in this area.

In the book "Microservice Design", microservices are defined as: microservices are small and autonomous services that work together.

This definition is not particularly good, it always feels that it narrows the scope of microservices.

In addition, the gap in the understanding of this sentence is quite large. I remember that I had a comment system before. The comment service, comment backend, DB, cache, etc. were all independently deployed. At the time, I thought this comment system was a microservice. This is not 100% wrong, but it is certainly not correct.

Because microservices describe a whole set of systems, a single independent service only accounts for a small part of microservices.

Microservices are mainly composed of 6 parts

1. Service description

   The documentation for similar services is simple but indispensable. For example, the first problem to be solved for service invocation is how to describe the service. For example, if you provide a service externally, what is the service name of this service? What information is required to call this service? What format is the result returned by calling this service? How to resolve it? These are the problems to be solved by the service description.

2. Registry

   With the service interface description, the next problem to be solved is service publishing and subscription, that is, you provide a service (Provider), how to let the external (Consumer) people who want to call your service know. At this time, a role similar to a registry is required. The service provider registers the service and address provided by the registry to the registry, and the service consumer queries the address of the service to be called from the registry, and then initiates a request.

3. Service framework

   Through the registration center, service consumers can obtain the address of the service provider, and after having the address, they can initiate a call. But you still need to solve the following problems before making the call. What protocol is used for service communication? Is it RESTful API or gRPC? What is the method of data transmission? What format is used for data compression? These activities are usually integrated into our service framework. There are many such open source frameworks on the market , which are relatively mature. The next test is your ability to get started quickly.

4. Service monitoring

   Once a service call can be initiated between the service consumer and the service provider, you need to monitor the call to see if the service is normal. Generally speaking, service monitoring mainly includes three processes, indicator collection, data processing, and data display. Monitoring is to discover problems and abnormalities. If you want to further track and locate problems, you need to learn more about service tracking.

5. Service tracking

   In addition to monitoring the service invocation, you also need to record each layer of links that the service invocation passes through in order to track and locate faults, and finally achieve the goal of approaching the problem. Service monitoring and tracking can be combined, but it must be clear that their respective responsibilities are different.

6. Service governance

   Service monitoring can find problems, service tracking can locate problems, and problem solving depends on service governance. Service governance is to use a series of methods to ensure that service calls can still be performed normally under various unexpected situations. As far as the current open source service frameworks are concerned, most of them do not include the content of service governance, so it is possible that this part requires you and your team to conduct customized development, depending on how well you achieve it. It is like you have a database but you The absence of ER diagram description does not affect your use of microservices. Of course, if there is, it will be the icing on the cake.

The combination of these 6 parts is called a microservice. The following link is a mind map I made. I haven't fully learned some of the content in the map. I will further organize it later. If you like it, you can remember this link first.

https://www.processon.com/view/link/5f3952a17d9c0806d41a90a9

Learning route

Microservices can be regarded as a master of modern Internet technology. I am a beginner, and I need to establish a learning path for myself so that I can better master the content.

For the learning route, I think there are several principles:

1. Find out what to learn and take notes
   • I have read many articles or books before, but I have not written down the content. I always feel that I have learned relatively shallowly. After digesting the content and writing it out, I can deepen my impression.
   • The content that must be learned should be the core content, such as k8s, docker, distributed, etc. 100% need to be learned
2. No need to learn
   • There are multiple technical options for the same program, just learn one. For example, service orchestration only needs to look at k8s, because this is already an industry standard. Service tracking can choose one from zipkin and skywalking
   • Some content is particularly biased towards the operation and maintenance level, which can be understood a little bit or not at all
3. Continuously update and enrich the mind map
4. During the learning process, practice is needed to finally build basic microservices.

The current planned learning and re-learning content are

1. k8s
2. docker
3. Etcd
4. GRPC
5. Netty
6. Dubbo
7. ELK
8. Grafana
9. Kafka
10. Skywalking
11. Apollo
12. Same

In fact, in addition to these, microservices still have a lot of other content to learn, which can be added gradually in the future.

data

1. Microservice learning architecture roadmap (preliminary draft)

2. Microservice learning navigation

3. [Dry goods sharing] Probably the most comprehensive .NET Core cross-platform microservice learning resource in the Eastern Hemisphere

At last

If you like my article, you can follow my public account (Programmer Mala Tang)

Review of previous articles:

technology

1. Talking about microservices
2. TCP performance optimization
3. Current limit realization 1
4. Redis implements distributed locks
5. Golang source code bug tracking
6. The realization principle of transaction atomicity, consistency and durability
7. Detailed explanation of CDN request process
8. The history of blog service being crushed
9. Common caching techniques
10. How to efficiently connect with third-party payment
11. Gin framework concise version
12. A brief analysis of InnoDB locks and transactions

reading notes

1. How to exercise your memory
2. Simple logic-after reading
3. Hot air-after reading
4. The Analects-Thoughts after Reading

Thinking

1. Some views on project management
2. Some thoughts on product managers
3. Thoughts on the career development of programmers
4. Thinking about code review
5. Markdown editor recommendation-typora