Let’s start with a short story: Zhang SAN is a programmer who goes to work for a new company during the golden nine, silver ten season. The new company looks promising and makes cutting-edge products, so Mr. Zhang vows to make a big show of it and use his excellent development skills to help the company go public.
On his first day on the job, the company opened up access to the code and he became familiar with the company’s core projects. However, zhang SAN was shocked to find that the company’s projects are just like a dump, with all kinds of codes piled up into mountains, and what he has to do is to maintain these old projects. At that moment, Zhang SAN’s inner illusion was shattered.
But after maintaining the project for a while, things took a turn. One day, the new project comes down, the boss appoints Zhang SAN as the person in charge, his heart is overjoyed, finally can prove himself.
“I must make the code elegant and say goodbye to bad code.”
At the beginning, Zhang SAN used a variety of design patterns, crazy abstract business, do more and more strong, feel a body of talent finally had the opportunity to show. But the project was a multi-person collaboration, and as time went by and the project went through iterations, many new people stopped working on the code according to predetermined specifications.
Microservices are springing up for convenience, as developers fill in code with one if statement after another. As a result, John began to manually restrict the submission of code that did not conform to the specification. However, the time pressure of the project became more and more, and Zhang SAN finally released the restrictions due to the pressure of delivery. Although the project delivered smoothly, the strange code was permanently stuck in the project.
Slowly, the original beautiful design began to become more and more bloated, logic became extremely complex. No one dares to refactor, and it is impossible to refactor. Finally, Zhang SAN can’t stand it, resigned to a new company, the new company looks good prospects, do the content is also the forefront of the industry products, Zhang SAN again vowed to show their success in the new company, with their superb development technology for the company’s listing…
This story is repeated over and over again in the Internet industry. It seems that any project will evolve over time, patch by patch, and eventually become a “shit mountain” project, full of historical legacy issues, and the development of new features will be slower and slower, and ultimately unable to evolve to the end of the project. Some Internet companies hire senior software architects at a certain point to extend the life cycle of a project. They often read Refactoring and use various techniques to slow down the process.
What is the product architecture
Like software architecture, product design has architecture.
When we were working on the project, we thought that all the problems could be solved technically, but the whole project was moving towards the “shit-mountain” project unconsciously. According to the r&d mindset, the root of the problem is that there is not enough abstraction, the technical level is not good enough, and a stronger architect is needed to refactor.
After hiring a senior software architect, the project seemed to get better at first, but in the end it didn’t change, it just delayed, and at some point it had to be abandoned and started over.
After a second review, we found that our main focus was on solving technical problems, rather than the product level. According to a saying on the Internet, product architecture is the logical sorting of product data flow based on a full understanding of product users’ needs.
My understanding of product architecture starts with **” world of ideas “**. Programming is about describing real things in languages that computers can understand. What is the language that computers can understand? Is logical. When programming, the developer needs to conceive the whole picture of an event in his mind and describe it in logical terms.
In Western philosophy, there is a saying of “the world of ideas”, which roughly means that whatever people do, they construct the noumenon of things in advance in their mind, and then imitate the preconstructed content in reality. This is very similar to the process we use for programming. Does the product follow this process?
If I think back to the way I thought about projects in the past, I realize that this is true, that we need to more or less build a product trajectory in our head. But when doing the project, as research and development we are thinking about how to use technology to solve problems, but ignore the more important things, any product is to solve customer problems exist, solve customer problems is fundamental, no matter what means……
How to design the product architecture
Before designing, solve the problem of people first. What kind of people are suitable for product architecture?
Product architecture is the logical sorting of product data flow based on a full understanding of product users’ needs.
So this person needs to have the following qualities:
- Ability to research and understand user needs
- Be able to understand the core values of the product
- Ability to understand product operation principles
- Object-oriented design thinking
With these qualities, we can begin to construct the “world of ideas”.
Constructing the World of Ideas
The construction of “concept world” is actually to transform the things that will happen in reality into pure logical description with object-oriented design thinking. This process is called abstraction.
For example, if we need to make a traffic governance type of product, the abstract process might look like this: Traffic governance is basically divided into two major content, traffic monitoring and traffic management, which are the core values.
However, the traditional traffic management tools are basically implemented by SDK, and they generally have the following problems:
- Invasive strong
- The governance function is not complete
- Content, high threshold
- Middleware evolution difficulty
- The version fragmentation is serious
- High upgrade cost
Solving this type of problem will give the service Grid a comparative advantage over the SDK approach as a traffic governance solution.
Based on the above analysis, it can be concluded that if the product is expected to be upgraded quickly and less intrusive, it must not be strongly bound with the customer’s code, and a means independent of language and capable of traffic monitoring and traffic management is needed, which can only be found on the operating system.
If you can manipulate some function on the operating system so that traffic enters the written program before it enters the service, language independence is achieved.
The idea goes something like this: A request comes in, the operating system forwards it to a program we’ve written, our own program reports the data to something to store, and finally the program forwards it to the actual service, and traffic monitoring is done. You also need something to store the reported data, and it needs to be persistent.
In this process, we use a design pattern called sidecar pattern, so we call the programs we write sidecar, and the ones we store database.
Next, we derive the logic of traffic control. To achieve traffic control, we need to use Sidecar. After all, traffic has been forwarded to Sidecar by the operating system. Then you need something else to tell sidecar how to handle traffic. After all, each Sidecar needs to handle different things, and the policy content needs to be persisted, otherwise there will be no corresponding relationship with Sidecar. This thing is called the control side.
The control end configures a traffic control policy and delivers the policy to sidecar. A traffic request is forwarded to SidecAR by the operating system. Sidecar first reports the traffic data to the database, processes the traffic according to the traffic policy, and finally forwards the request to the real service.
In a completely ideal state, the core capabilities of traffic governance are basically implemented through a process that has an advantage over the SDK approach. This is the so-called “idea world” construction process, a purely logical description.
Test the world of ideas
The only measure of whether the world of ideas is correct is whether it accurately describes reality, like the relationship between classes and objects in object-oriented thinking, the world of ideas is an abstraction of reality.
There’s a very effective way to find out if abstraction is good. Find some random people and explain your logic. If the process of presentation is smooth, the other person can understand and do not feel the omission of logic, this abstraction is better.
During the project, the process can be described to people in different positions as much as possible. On the one hand, the team members can deepen their understanding of the product, and on the other hand, the incomplete content of the process can be improved through continuous expression.
How to fall to the ground
When the “world of ideas” is established, it needs to be simulated in reality, and in software engineering, this step begins to move from design to practice. General projects are divided into two categories, one is to start from scratch, the other is stock projects.
A project from scratch
Before starting a project from scratch, there are two questions: Where do you start? How far do you want to go?
As you can see from the process, the following are the cornerstones of everything.
1. Manipulate certain functions on the operating system so that traffic enters the Sidecar we wrote before it enters the service
2.sidecar
3. The database
So when there are no external special circumstances to interfere with the flow monitoring function must take precedence over the flow control function, this is where to start.
Accomplish what level basically depends on time, the concern of personnel, see actual situation to hold. However, no matter how much is done, as long as the direction is right, the iteration of the whole product is of positive significance.
From this diagram, the division of services becomes clear and the boundaries of each service are clearly defined when handed over to r&d. Even if there are new entrants or uneven levels of research and development personnel, the damage caused within this framework is limited and will not cause structural problems to the whole product. At some point in the future, we just need to find a strong enough research and development to write again, and the problems will be solved.
Stock of the project
The landing of stock projects is very complex, the historical legacy harm……
The big idea is to use abstraction to mirror reality, to see if the current code fully conforms to the “process” of abstraction, to figure out the status quo first, and then to figure out how to cut back.
If there is a new demand, or to first abstract, any legitimate demand is logical, if the abstraction is not logical, it is certainly not enough demand mining, can not blindly add code.
Again, if you needed to add a monitor for Sidecar, the process would look like this.
But is it necessary for surveillance to be singled out? The process can look like this if it doesn’t have to.
These 2 kinds of forms have no advantages and disadvantages of the points, can be combined with the specific situation to choose.
conclusion
Those of you who are aware of the service grid field should have noticed early on that the example mentioned above is the birth of a weak version of Istio.
I tried to derive Istio’s architecture purely logically from requirements. There must be something to be said about how many well-known open source projects have become more refined over the years.
This article is only to provide a solution to the problem, the core of the solution to the problem depends on people, a group of big men, no matter what method is used to make things are exquisite and elegant.