I am not convinced! This open source project has only 888 stars! ?

Hello, I am why.

Yes, I found another treasure, and I can’t wait to share it with everyone.

This treasure is an open source project, or an open source book.

What makes me wonder is that this open source book with such learning potential and guiding significance is currently only 887 Stars.

It’s better to catch up early than to catch up by coincidence. I am the 888th person who ordered Star. It sounds like a lot of fate:

https://icyfenix.cn/

Let's take a look at the mind map I compiled after reading it:

It’s okay if you can’t see clearly, you will get the link at the end of the article.

One of my personal feelings after reading this is:

Regarding the direction of distributed architecture, I have written a lot of it. And they are all empirical talks that the author walked along the way, condensed in the article.

Right from the slogan on the home page: Build a reliable large-scale distributed system.

Who wrote it?

So who is the author of this open source book?

Zhou Zhiming.

Yes, that's the man you thought of who wrote the JVM book.

In fact, if you look carefully at the self-introduction written by Zhou Lao, there are very small details.

Among the four professions of programmer, researcher, author, and evangelist, ranked first is the least gimmicky "programmer" job.

In the programmer, the description given to himself is:

A programmer who works part-time in management and research.

In fact, on this point, I have seen some public self-introductions by Zhou Lao, saying that he is a "part-time managerial programmer" and labeling someone like himself.

He explained this label in his article "Programmer's Road".

What he wants to express through this label is that for a programmer, whether he wants to develop into an architect or a R&D manager in the future, he should not leave the forefront of the technology field easily. The decision to leave the technology and give up coding is very likely. It will be like the knowledge of mathematics, biology, geography and so on that you put down after the college entrance examination. Once you let it go, it will be difficult to have the opportunity to pick it up again in your life.

When you put down the code for longer, over time, your understanding of the code, technology, product status, and team R&D status will gradually become misaligned with team members, lose the ability to give guidance in details, and lose professional problems. The ability to put forward a grounded gas solution can only be used to provide opinions on a large strategic direction that cannot be verified in the short term.

Work hard on meetings, processes and team management measures, and look for a sense of presence in professional manager-style presentations and reports.

At this moment, you have changed from a team mentor to a manager. In the end, the relationship between you and the team, from a partner who works side by side, has completely evolved to rely on the company's system and the power of management positions to maintain the employment relationship.

I can understand the phenomenon Zhou Lao said, but it is actually a very common phenomenon. Some friends even take up the management position with the goal of not writing code anymore. Based on the current market and industry status quo, such a choice is understandable.

Just, is there such a little possibility, don't abandon the code completely. This also needs to be the most effective link between you and the team.

As stated in the book "The Way to Clean Code":

Software architects themselves are the best programmers. They will write code all the time. Although they may not output as much code as other programmers, only continuous programming can ensure that they meet the problems faced by other programmers. , To experience the feelings of other programmers, so if they do not program, they will not be able to do the job of software architecture.

This "Phoenix Architecture", Zhou Lao's own positioning of it is this:

It provides developers with a skill map on software architecture, and at the same time systematically sorts out their own knowledge, and is equipped with a demonstration program corresponding to the technical solution.

It's really a matter of benefiting others and self-interest.

My original idea was to first take everyone around this book, mainly to serve as an introduction.

But the more you write, the worse it feels. Because even though I wrote it so hard, it didn't reflect one-thousandth of the value of this book.

You have to read it yourself before you know that I didn't lie to you:

This is really a treasure!

So I decided to change my mind and tell everyone what's in it. In fact, it's just the beginning section of the book.

Exploring start

This is the update log part of the beginning of the exploration. You can see that Zhou Lao has been maintaining new content for the project:

As for the existing content, he is also taking time to modify the typos, incompatibility, and ambiguity in the existing content. The most recent modification was June 6, yesterday, and last Sunday:

Therefore, compared to most other online articles, it will be more real-time, systematic and higher quality.

The book is divided into five parts and two chapters. In order to let you quickly locate the part that suits you, Zhou Luo also carefully introduces the type of readers corresponding to each part.

• The introductory chapter begins to explore: This part is for explorers who are preparing to practice the contents of the document introduction.
• The first part of the evolving architecture: This part is suitable for all developers, but it is especially recommended for developers who have just transitioned from a monolithic architecture to a microservice architecture.
• The second part of the architect's perspective: this part discusses architecture knowledge that has nothing to do with style, suitable for all technical architects, system designers, and developers.
• The third part is the cornerstone of distributed: this part is for developers who use distributed architecture.
• The fourth part is immutable infrastructure: this part is for infrastructure operation and maintenance personnel and developers of technology platforms.
• Part V: Technical Methodology: This part is aimed at decision makers who can make decisions about important technical decisions in the enterprise.
• Essay essay: This part has no specific audience, and the content is the collation of the author's daily articles.
• External appendix: This part is for designers and developers who are just beginning to get in touch with the cloud native environment.

The mind map I made after reading the first part is as follows:

You may be a little unfamiliar with the post-microservice era and the no-service era, but if I change the English name, everyone should be very familiar with it.

The post-microservice era is actually the cloud native era, Cloud Native.

And no service is actually Serverless.

But it should be noted that Zhou Lao ranks Serverless after Cloud Native. In fact, there is no inheritance or substitution relationship between the two. Don't be wrong about Zhou Lao's thinking that "no service will be more advanced than microservice" because of the writing order of the two.

Zhou Lao described the relationship between the two as follows:

• If the microservice architecture is the ultimate that can be achieved on the path of distributed systems, then the serviceless architecture may be the starting point of the path of "non-distributed" cloud systems.

The mind map of the second part is as follows:

This part mainly talks about the issues that we will definitely involve when we do distributed services, such as: remote service call (RPC), distributed transaction processing, multi-level shunting, and architecture security.

I personally think that this part is full of dry goods.

Among them, access to remote services provides a detailed description of RPC and REST from their respective origins:

In the transaction processing section, you can take a look at the concept of "shared transactions". In fact, I found that some of the projects that claim to be microservice architecture have moved towards the route of "shared transactions".

I think this is a kind of pseudo-distribution.

The disassembly of the transparent multi-level distribution system from the client to the network to the server is a description of God's perspective, and the theme of this part is "the architect's perspective".

The architect should look at the system from the perspective of such a more overall planning, without going into the details of the specific system:

The third part of the cornerstone of distributed:

Consensus algorithm, service discovery, traffic management, network communication, monitoring and early warning together constitute the cornerstone of distributed.

It can be said that if it is a distributed service, the shadow of these keywords can be found.

Some are made by the application system itself.

Some are open source frameworks to help you get it, you don't even know their existence.

But the above, such as traffic management and monitoring and early warning (observability) are not necessary when a distributed service is first built.

In most cases, the just-built distribution is in a wild state.

As time progresses and business development, traffic management and monitoring and early warning will be added gradually.

That is to say, if you want the monitoring of the development of distributed services to be controllable, then these things should be there.

The term "cornerstone" is as precise as a scalpel.

Come to the fourth part, immutable infrastructure:

At this point we will move from microservices to cloud native.

In this chapter, Zhou Lao focuses on the development of containers, orchestration systems, and service grids, and introduces how virtualized containers and service grids blur the boundaries between software and hardware, and how to help at the level of infrastructure and communication. Microservices hide complexity and solve distributed problems that can only be solved by programmers through software programming.

The following "technical methodology" is a guide to avoiding pitfalls in microservices, expounding how to better use microservices from the four perspectives of purpose, premise, boundary, and governance.

The last part is the "essay":

The two articles, "Cloud Native Era, Java's Crisis and Opportunity" and "Programmer's Road", are recommended to be watched repeatedly.

The former is technical, and the latter is soft skills.

After reading "Java Crisis and Opportunity", I feel that a self-revolution about Java has quietly begun.

Java is not an excellent development language, this I am very admit and sure. But Java has a huge user group and an extremely rich ecosystem, and this is its moat. So it won't fall down in a short time.

But the gale started at the end of Qingping. Storms are coming, and many people, including me, don't know it.

In the article, Zhou Lao has this paragraph:

The biggest difficulty with Java's support for pre-compilation is that it is a dynamically linked language. It assumes that the code space of the program is open (Open World), allowing new classes to be loaded through the class loader at any time in the program, as the program's Part of it runs. To compile ahead of time, you must give up this part of the dynamics. Assuming that the code space of the program is closed (Closed World), all the codes to be run must be known at compile time. This not only affects the normal operation of the class loader. In addition to being unable to load dynamically, reflection (through reflection can call methods unknown at compile time), dynamic proxy, bytecode generation libraries (such as CGLib), etc. The functions that generate new code at runtime are no longer available. If these basic capabilities are directly removed, Helloworld can still run, but Spring will definitely not run, Hibernate will not run, and most productivity tools will not run. , The vast majority of superstructures in the entire Java ecosystem will collapse.

"Most of the superstructures in the entire Java ecosystem will collapse."

Therefore, this change in Java is a draw from the bottom.

After reading "Java's Crisis and Opportunity", if you read the article "Graal VM", you will understand: why the success of Graal VM is closely related to the future and destiny of Java.

And this change has begun quietly, such as a small point:

Most of the generation and modification operations of bytecode during runtime are unacceptable in the view of Graal VM.

But, for example, CGLIB generates bytecode (generating a subclass of the proxy class) at runtime to do dynamic proxy.

This is the current mainstream form.

Now because Graal VM can't support it, it must be solved together with the framework.

Therefore, since Spring Framework 5.2, a new proxyBeanMethods parameter has been added to the @Configuration annotation. Setting it to false can prevent Spring from proxying non-interface types of beans.

Similarly, corresponding to Spring Boot 2.2, the @SpringBootApplication annotation also adds the proxyBeanMethods parameter, which usually needs to be set for Spring Boot local applications built with Graal VM.

What I like most is the technical demonstration engineering part. The project Demo is ready for you directly, and it is ready to use out of the box:

And this open source project written by Zhou Lao has a feature, the referenced part will give the specific official address. Rigorous and authoritative, such as when writing about the technical components used in the project:

A question and answer

In the project, I also found a question and answer.

The questions and answers are very good, and I will bring them here for everyone to see.

Comment area: https://icyfenix.cn/methodology/forward-msa/prerequest.html

Questions are as follows:

Brother Zhou, I saw the Matthew effect you mentioned. Think of the software nirvana you talked about before, and the complete microservice system allows the service to have a nirvana process and has strong fault tolerance. With the rapid development of microservices, I feel that the Matthew effect is really not far away.

I can't help thinking about the skills that I need to master the most, and I have a stronger sense of anxiety.

I am a java development engineer with seven years of work experience. I am 28 years old. I am currently working in a traditional information software technology company in Beijing. The salary is relatively low compared to the computer industry.

Confined to the Java language, are higher-level capabilities such as jvm tuning and concurrent programming not critical?

jvm I read the second and third editions of "In-depth Understanding of the Java Virtual Machine: JVM Advanced Features and Best Practices" written by you. Since there are few opportunities to practice at work, I only stay in some theoretical understanding without practice. The theoretical knowledge will be forgotten.

Concurrent Programming I have read "Java Concurrent Programming Practical Combat", I have some understanding of concurrent programming, and some practice, average level.

Microservice companies are not used, and practical experience is also lacking. Knowledge of remote call, distributed transaction, registration center, configuration center, circuit breaker, current limit, etc., can have some understanding with this document of yours by watching the video.

The basic knowledge of java, after these years of tempering, is quite solid, and spring can be used proficiently.

I have an understanding of common design patterns, and I have a good understanding.

I don't want to become a screw.

What abilities should I improve?

Over the years, I have only been competent for the job assigned to me.

Now I find that I lack foresight and control over my career.

I now want to take control of my career, and ask Brother Zhou for some guidance.

I will use the recruitment market to explore market demand, organize and think.

But I can’t wait to tell you something, please feel free to let me know, I hope my request is not very abrupt.

This problem is actually very universal: after learning, there is no place to practice, and slowly forget it. I have learned a lot of theory, and I can talk and laugh, but I haven't used it in practice. He is a screw.

Zhou Lao’s reply is as follows:

I am not writing this article to sell anxiety, nor do I have the ability to guide others in their careers. However, I have been asked many times before, and I can repeat it here.

My suggestions are two:

• Don't underestimate knowledge that does not directly generate practical value;
• Don't get caught up in a technique that you have mastered.

In order to make it easier for you to understand, I will make a very native analogy, and compare the programmer's promotion of himself to the practice of martial arts. The skills in the software are actually distinguished by "internal power" and "martial arts", such as the Java you mentioned. Virtual machines, this kind of knowledge is not only a rare opportunity for you to practice at work, I am also similar.

In university computer courses, courses ending with the word "principle", such as computer principles, operating system principles, compilation principles, database principles, etc., are not very good at designing processor logic circuits for most people , Design programming language and compiler, develop operating system kernel.

These have very classic books: the dragon book on compilation principles, CSAPP on computer architecture and program operation, DDIA on distributed and database principles, MOS on operating system principles, and so on. The system of these books is rigorous and comprehensive, but the readability is not excellent. It may be a better way to read the open class translation videos of the authors of these books at station B/Coursera.

These skills can help you to think and analyze problems, but it is difficult to directly solve the problems in production for you. It is inappropriate to measure their effects in terms of practical value, that is, whether there is a chance to use them in the work.

But these courses are compulsory, because learning them can build a good foundation for a programmer's knowledge framework.

This sounds very dogmatic, but once you have established a relatively complete and stable knowledge framework, you find that the new knowledge and new technology you encounter can naturally be placed in a certain position in the existing knowledge system, and you can clearly perceive it. The design intent and goals of language, technology, and framework can even resonate with what the designer thought at the time, and it will produce a natural feeling.

In this way, your cognitive load for accepting new knowledge will be lower than others, you will master it faster, and you will understand it more deeply.

What I said at the beginning of this document is that the purpose of writing this document is to organize one's own knowledge framework, not just a case, this is indeed the key to how programmers learn new knowledge. It is also a decision in the rapid iteration of knowledge in the IT industry. The fundamental factor of how high the upper limit of a programmer's ability is.

In contrast, those specific technologies and methods used to solve problems in production, such as the Spring and design patterns you mentioned, I compare them to "wugong".

This is of course also important. Only internal strength and no martial arts can’t walk the rivers and lakes. I have a theory, but I can’t write code (including those architects and designers who only set general directions). I don’t think they are definitely qualified programmers. It is also difficult to expect to be an excellent technical leader (difficult to convince the public).

However, the specific "martial arts" should be able to be picked up quickly and can be quickly "forgotten", that is, to avoid getting stuck in one thing when it is done well, and avoid getting a good hammer. Just look at everything like nails.

Many programmers complain that they are CRUD Boys, they are rolling in the business logic, and they have no chance to contact the underlying or forward-looking technology, so it is difficult to improve their skills.

Of course there are objective reasons here, but they are often amplified by subjective reasons.

In fact, programmers are almost the same as craftsmen in the old age. They have a natural worship of technology in their bones. The code you write is more elegant, robust and high-performance than others. You kill bugs faster and cleaner than others, and you will be recognized by everyone.

Naturally, more technically in-depth jobs will fall to you. At least you will have the right to speak and choose what to do. Whether you want to always roll around the business you are most familiar with is caused by You decide.

Learning martial arts to become a "martial master" is to become a big BOSS without having to face the entanglement of shrimp soldiers and crabs for a long time.

Learning a specific technology is also to use it to solve the problem, and then forget it, to master those deeper and more cutting-edge technologies that you don't know yet.

Finally, there is a follow-up question and answer as follows:

I don't know how you feel after seeing this answer.

At least for me, it's shocking. Especially these two points:

• Don't underestimate knowledge that does not directly generate practical value;
• Don't get caught up in a technique that you have mastered.

Has been placed in the phone label, often remind yourself.

Encourage with you.