Hello, I’m Why.

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

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

To my amazement, this open source book with such learning potential and instructive value has only 887 stars.

It’s better to catch you early than to catch you coincidental. I’m the 888th person to hit Star.

https://icyfenix.cn/


Let’s take a look at the mind map I put together:


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

One of my personal feelings after watching it is:

A lot has been written about distributed architecture directions. And are the author all the way through the experience of the voice, concentrated in the article.

The slogan on the front page: Build reliable large-scale distributed systems.

Who wrote it?

So who is the author of this open source book?

Zhi-ming zhou.

Yes, the man you think wrote the book on the JVM.


Actually you see week guy to write self introduction carefully, have small detail very much.

Programmer, researcher, author and evangelist, the least gimmicky job is “programmer.”

In the programmer, the description is:

A programmer who does some part-time management and research work.

In fact, about this point, I have seen some of zhou’s public self-introduction, all said that he is a “part-time some management work programmer”, to set a label for such a person.

He explains this label in his article the Programmer’s Way.

He wants to get through this TAB is for a programmer, later want to development as an architect or r&d manager, do not easily leave a glimmer of frontier in the field of technology, from technology, and give up coding decisions are likely to be like you put down after the college entrance examination mathematics, biology, geography knowledge, once let go, life is hard to have the chance to pick it up again.

When you let go of the longer code, as time passes, your code, technologies, products, and team development state of understanding, gradually can produce the deviation of displacement and team members, lose the ability to give guidance on details, lost puts forward solutions to ground on the question of professional ability, can only in short term is difficult to check the big strategic direction of right and wrong opinion.

Work on meetings, processes, and team management practices, and find presence in professional manager-style presentations and presentations.

At this point, you go from being a mentor to a manager, and eventually your relationship with your team evolves from being a partner and working hand in hand to being dependent on the company system and the authority of your management position to maintain employment.

I can understand the phenomenon zhou Guy said, in fact, is a very common phenomenon. There are even some friends who go into management positions with the goal of not writing code any more. Based on the current market and industry status quo, such a choice is understandable.

Just, is there even a small chance that you don’t throw away the code altogether. It also needs to be the most effective link between you and your team.

As the book Clean Code Writes:

Software architect itself is one of the best programmers, they would have been writing code, although may not much like other programmers code output, but only a continual programming, can ensure that they meet the problems facing other programmers, and experience other programmers felt in the heart, so if without programming, they also will not be able to do this work software architecture.

The positioning of this “Phoenix Architecture” by Zhou Himself is as follows:


For developers to sort out the skills of the software architecture map, while systematically sorting out their own knowledge, and equipped with the corresponding technical program demonstration.

It’s really a good thing for everyone.

My original idea was to take you on a tour of the book, which mainly serves as an introduction.

But the more I write, the more I feel bored. Because even though I worked so hard, I didn’t represent one thousandth of the value of the book.

You’ll have to read it for yourself to know I’m not lying to you:

This is really a treasure!

So I decided to change my mind and just tell you what’s in it, which is actually the first chapter of the exploration of the book.

Explore the start


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


For the existing content, typos, incoherent places and unclear meanings, he is also taking time to revise, the latest revision is June 6th, yesterday and Last Sunday:


So, it’s a little more real-time, systematic, and good than most of the other articles on the web.

The book is divided into five parts and two chapters, and in order to help you quickly locate your own part, Zhou also carefully introduces the corresponding reader types of each part.

  • Introductory Explorations: This section is intended for explorers who are preparing for a hands-on introduction to the documentation.
  • Part 1 Architecture in Evolution: This section is suitable for all developers, but is especially recommended for those who have just made the transition from a monolithic architecture to a microservice architecture.
  • Part 2 Architect’s Perspective: This section discusses style-neutral architecture knowledge for all technical architects, system designers, and developers.
  • Part 3 Distributed Cornerstones: This section is intended for developers using distributed architectures.
  • Part iv Immutable Infrastructure: This part is for infrastructure operation and maintenance personnel and developers of technology platforms.
  • Part v Technology Methodology: This part is aimed at decision makers who can make important technology decisions in the enterprise.
  • Extra-essay: this part has no specific readers, the content is the author’s daily articles.
  • Appendix: This section is for designers and developers who are new to the cloud native environment.

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


You can be a little strange to the post-micro service era and non-service era, but I change the English name, we should be very familiar with it.

The post-microservice era is actually the era of Cloud Native.

And no service is Serverless.

However, it should be noted that Zhou Ranked Serverless after Cloud Native. In fact, there is no inheritance and substitution relationship between the two. Don’t get the wrong idea that “no service is more advanced than microservice” just because Zhou wrote the order of the two.

Zhou describes the relationship between the two as follows:

  • If microservice architecture is the best that distributed system can achieve at present, then non-service architecture may be the starting point of “non-distributed” cloud system.

The second part of the mind map is as follows:


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

Personally, I think this section is full of dry goods.

Accessing remote services provides a detailed description of RPC and REST from their respective origins:


In the transaction processing section, you can look at the concept of “shared transactions.” In fact, I’ve seen a number of projects that claim to be microservices architectures go the “shared transaction” route.

I think it’s a pseudo-distribution.

The disassembly of transparent multi-level shunt systems from client to network to server is a description of god’s perspective, and the theme of this section is “Architect’s Perspective”.

The architect should look at the system from a more holistic perspective, without getting into the minutiae of a specific system:


Part III Distributed foundation:


Consensus algorithm, service discovery, traffic governance, network communication, monitoring and early warning constitute the cornerstone of distribution.

It can be said that if it is a distributed service, you can find the shadow of the above keywords.

Some of it is done by the application itself.

Some open source frameworks do it for you, and you don’t even know they exist.

But things like traffic governance and monitoring alerts (observability) above are not necessary when a distributed service is first built.

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

As time goes on and the business develops, traffic management and monitoring warnings are gradually added.

That said, these are all things you should have if you want control over the development of distributed services.

The word “cornerstone” is as precise as a scalpel.

Which brings us to part four, Immutable Infrastructure:


This is where we move from microservices to cloud native.

In this chapter, the week guy arranged in containers, system and service grid development as the main line, introduced how virtualization containers and service grid blurs the boundaries between software and hardware, how to help on infrastructure and communication level micro service to hide complexity, solve originally only through software programming to solve the problem of distributed by the programmer.

The following “technical methodology” is a guide to avoid the pit of micro-services, which explains how to better use micro-services from four perspectives: purpose, premise, boundary and governance.

The last part is “essays” :


One of the “cloud native era, Java crisis and opportunity” and “programmer’s road” these two articles, I suggest you watch repeatedly.

The former is technical, the latter is soft skills.

After reading “Java Crisis”, I felt that a self-revolution about Java has quietly begun.

Java is not a great development language, I’m sure of that. But Java has a large user base and an unusually rich ecosystem that is its moat. So it won’t go down anytime soon.

But the wind starts at the end of the tree. The storm was coming, and many people, myself included, didn’t know it.

In the article, Zhou Had a paragraph like this:

The biggest difficulty with Java’s support for pre-compilation is that it is a dynamically linked language, which assumes that the code space of the program is Open World, allowing new classes to be loaded at any time through the class loader and run as part of the program. To compile ahead of time, you must give up this dynamism, assuming that the program’s code space is Closed and that all code to run must be known at compile time. This not only affect the normal operation of class loaders, besides unable to dynamic loading, reflex (through reflection can be invoked at compile time unknowable method), dynamic proxy, bytecode generation library (such as additional) everything will run when the function of the new code is no longer available, if these basic ability will directly pull away, Helloworld will still work, but Spring won’t work, Hibernate won’t work, most productivity tools won’t work, and most of the superstructure of the entire Java ecosystem will collapse.

“Most of the superstructure of the entire Java ecosystem collapses.”

So, this change in Java is to pull the plug.

Read Graal VM after Reading Java Peril, and you can see why the success of Graal VM depends on the future of Java.

And that change has already begun quietly, like a little dot:

Most run-time bytecode generation and modification operations are unacceptable to Graal VM.

But CGLIB, for example, does dynamic proxying by generating bytecode (a subclass of the proxy class) at runtime.

This is the prevailing pattern at the moment.

Right now, since Graal VM does not support it, it has to be worked out with the framework.

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

Similarly, in SpringBoot 2.2, the @SpringBootApplication annotation also adds the proxyBeanMethods parameter, which is usually required for SpringBoot native applications built using Graal VM.

My favorite part is the technical Demo engineering section, which gives you the project Demo right out of the box:


And zhou Guy wrote this open source project has a feature, quoted part will give specific official address. Rigorous and authoritative, such as when writing about the technical components used in the project:


A quiz

In the project, I also found a q&A.

The questions and answers are very good. Bring them here for you to see.

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

The questions are as follows:

Brother Zhou, I saw the Matthew effect you said. Thinking back to the software nirvana you talked about earlier, the perfect microservice system allows services to have a nirvana process, with strong fault tolerance. Microservices are developing so fast that I think the Matthew effect is really not far off.

I can’t help but think about the skills I need to master the most, and feel more anxious.

I am a Java development engineer with seven years of working experience. I am 28 years old and currently working in a traditional information software technology company in Beijing. My salary is relatively low in the computer industry.

In the context of the Java language, aren’t the higher-order capabilities of the JVM, such as tuning and concurrent programming, critical?

I have read the second and third editions of your book In-depth Understanding of the Java Virtual Machine: Advanced FEATURES and Best Practices of the JVM. Due to the lack of practice in my work, I only have some theoretical understanding, and without practice, theoretical knowledge will fade away.

Concurrent programming read “Java concurrent programming combat”, some understanding of concurrent programming, but also some practice, general level.

Microservices companies are not used and practical experience is lacking. Remote calls, distributed transactions, registeres, configuration centers, fuses, flow limiting, etc., have some understanding of this document by watching the video.

Java basic knowledge, after years of hone, is quite solid, Spring can skillfully use.

I have a good understanding of common design patterns.

I don’t want to be a screw.

What skills should I improve?

All these years, I just did the job assigned to me.

Now I find myself lacking in forward thinking and control over my career.

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

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

But I can’t wait to tell you about it. Please kindly give me your advice. I hope my request is not too rude.

This problem is actually very common: learn no place to practice, slowly forget. I have learned a lot of theories, and I can talk happily, but I have never used them in practice. He is a screw.

Zhou’s reply is as follows:

I’m not writing this to peddle anxiety, and I’m not in a position to coach other people’s careers, but I’ve been asked this question many times before, and I can repeat it.

I would suggest just two things:

  • Do not despise knowledge that does not directly produce practical value;
  • Don’t be tempted to fall into a rut that you already know.

In order to facilitate your understanding, I will make a very primitive analogy, the programmer to improve themselves to the martial arts training, software skills are in fact very obvious “internal force” and “martial arts”, for example, you mentioned the Java virtual machine, this kind of knowledge is not only you rarely have the opportunity to practice in the work, I also similar.

In college computer courses, courses ending in the word “principles”, such as computer principles, operating system principles, compiler principles, database principles, etc., for most people, they will not be able to design processor logic circuits, design programming languages and compilers, and develop operating system kernels.

There are classic books: The Dragon Book on compilation principles, CSAPP on Computer Architecture and Program execution, DDIA on Distributed and database Principles, MOS on operating system Principles, and so on. These books are systematic and comprehensive, but not very readable. A better way to do this is to check out the open class translation videos of the authors of these books on Website B /Coursera.

These skills can help you think and analyze problems, but it’s hard to solve them directly for you in production. Their practical value, that is, the opportunity to use them on the job, is not appropriate.

But these courses are required because they form the foundation of a programmer’s intellectual framework.

Sounds very doctrine, but when you once established a relatively complete solid knowledge framework, found the new knowledge, new technology, can naturally positioned at a certain position of the existing knowledge system, can clearly perceive language, technology, and design intent and objectives of the framework, and even can resonate to the designer thought at the time, can produce a kind of natural feeling.

You’ll have a lower cognitive load to take in new information, learn it faster, and understand it better than others.

As I said at the beginning of this document, I wrote this document to organize my knowledge framework, not to talk about IT. This is really the key to how programmers learn new knowledge, and IT is the fundamental factor that determines how high a programmer can go in the IT industry with rapid knowledge iteration.

In contrast, the specific techniques and methods used to solve problems in production, such as Spring and design patterns you mentioned, I use the analogy of “martial arts”.

This of course is also important, only internal force without martial arts can not walk rivers and rivers, empty has a theory, but can not write the code (including those who only set the general direction of the architect, designer), I think not certainly qualified programmers, it is difficult to expect to become an outstanding technical leadership (difficult to convince).

But the specific “martial arts” should be able to quickly pick up, but also quickly “forget”, is to avoid doing a thing well, always stuck in the thing, avoid getting a good hammer, see everything is like a nail.

Many programmers complain that they are CRUD boys, wallowing in business logic and not getting access to low-level or forward-thinking technology, so they are not getting better at it.

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

In fact, programmers and manual craftsmen in the old times are almost the same, there is a natural worship of technology in their bones, you write code elegant, robust and high performance than others, you kill bugs faster and cleaner than others, will be recognized by everyone.

Naturally, more technical and deeper jobs will fall on you, but at least you’ll have a say in what you do, and you’ll have a choice whether or not to stick to what you know best.

Learn martial arts to become “martial arts master”, is to become a big BOSS do not have to face the long-term entanglement of shrimp.

To learn a specific technology is also to use it to solve problems, and then forget it, to master those deeper, more cutting-edge, and their own skills.

One final question and answer is as follows:


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

For me, at least, it was sobering. In particular, these two points:

  • Do not despise knowledge that does not directly produce practical value;
  • Don’t be tempted to fall into a rut that you already know.

Put it in your phone tag to remind yourself.

With your mutual encouragement.