Talking about it architecture and reconstruction (dry goods) from Xizhimen overpass

- August 13 PM 20:00 Neeke June from one battlefield to another battlefield, back to the office, open the computer, landing, wonderful micro-community sharing is about to begin!

Hello, I am Neeke, Chinese name Gao Tao, PHP development team member, now Cloud wisdom as senior architect, responsible for the company's product architecture and research and development work. At present, cloud Wisdom has two products, monitoring Bao and perspective Bao. The former mainly do backbone network monitoring and IT infrastructure monitoring, the latter mainly to do business-oriented, end-to-end integration of APM solutions.

Attach a personal profile of the Gao Tao: Neeke, senior architect for Cloud intelligence, member of the PHP development team, and author of Pecl/seaslog. 8 years of research and development management experience, early engaged in large-scale enterprise information research and development framework, 09 into the Internet digital marketing and in-depth research architecture and performance optimization. 2014 joined the cloud Wisdom, committed to APM product architecture and development. Advocating agility, efficiency, gettingreal.

The main share with you today is in recent years, I in the website, application, information systems, architecture and reconstruction of some experience and experiences.

Architecture, in the eyes of ordinary technical personnel, is a seemingly very mysterious occupation, feeling like a group of mysterious Martial, engaged in some very mysterious work, with some seemingly very deep, very strange things, to let some seemingly decadent projects or applications, resulting in some subtle changes.

And for the reconstruction, relative to the architecture, it is more tolerant, more elusive. Let's start with a picture.

Yes, this is a very beautiful night scene, is Beijing, Xizhimen overpass. It is a milestone in the history of the construction of overpass in China.

But at the same time, it is also a wonderful flower.

Everyone notice, the lower left corner to the right, the direction is from west to east, if I want from the lower left, to the right, that is, from the west to the south, we think, how should we go? Don't suspense, just look at the answer.

The Green Line is our desired driving route, and the Yellow line is the real driving route. That is, we need to go from the west to the East Bridge, and then from the south to the North Bridge, and then from east to west again down the bridge, and then from north to south, to reach our direction. It is difficult to get down from the bridge, not the driver of Beijing. In fact, many Beijing drivers, will also faint here. However, it is a very good design.

Why do you say that?

OK , let's analyze the user, or audience, of this overpass.

Obviously, for this bridge, there are two users: the driving driver, the commanding police. This is obviously not an excellent design for a driving driver:

1 , not direct, easy to faint vegetable;

2 , which bend did not turn right, it is difficult to return to the original road;

3 , not controllable.

But for the traffic police (or the delivery department), this is obviously a very good design:

1 , there is no need for traffic police, also do not need red street lights, saving resources;

2 , because all is one-way road, do not have to turn and convection, reduce the accident rate.

Of course, the architect of the overpass, that is, the architects of this instance.

About architecture, this is one of the points I want to share:

Excellent architectures, most of which are business-agnostic, can easily fail if the architecture is completed from a business perspective.

Let's look at another picture:

The photo is a dangerous. (The handsome guy in the photo doesn't know.) The walls of the building and beside it is clearly dilapidated. Support is done with a variety of sticks or pillars of varying size and thickness. Many websites or applications, like this dangerous, are already dilapidated, but there are still a lot of businesses that continue to serve, as if there are still many residents living in it. They are helpless, exhausted and unhappy, but when new demand arises, they may still have to add more sticks or props to support the dangerous. When the site or application, has been to let developers, operators, OPS, feel helpless, tired, the time has come to reconstruct.

When architects refactor an application, what are the first things to consider?

First of all, should not be the structure of the site to re-build, a lot of features more excellent, more powerful components to join it?

What I want to share is that before you do a refactoring, don't think about it that way.

The brain is not hot, we are not Iron Man, can hold up a city.

We are not geeks, good, good components, even if you can control, it can not be combined well.

In the reconstruction, the first consideration, is the old building residents. That is, the business in the old application.

The reasons are:

1 , what is the difference between refactoring and a new project without considering the old business?

2 , the old business is constantly iterative, if you want to make a new architecture, when can you catch up with the business?

From my experience of successfully refactoring several mega-application projects, my approach is not necessarily correct, but it is practical:

1 , this dangerous has a lot of support points (bugs, business patches, process patches), and to make the project iteration and maintenance difficult, then you should find these support points for analysis, the similar support points grouped and integrated

2 , these already combed support points, a group of one group to isolate (decoupling the business, reduce the risk of joint risks)

3 , the support points that have been isolated, one for the deep analysis (distinguish process, level, and key points)

4 , refactoring and substitution of support points for normalization (refactoring one by one, and ultimately the refactoring of the infrastructure)

Image point:

It is perfect to re-build an excellent building, but it will make everyone more exhausted;

And a dangerous of the old part as the cornerstone, it has a mechanism to break the reorganization, and eventually become the most solid foundation of the new building, a reconstruction is successful.

OK , the above is my share of this evening, on the architecture and reconstruction of the experience, the following is the exchange time, please ask questions:

Interactive discussion:

Q: I think the architecture must consider business? Otherwise, excessive design or lack of design is very easy.

A: business should be considered. But it cannot be considered too much, as it is likely to become customized and lead to later non-extensibility.

Q: I think the structure and the business relationship is very big, why does it have nothing to say?

A: What I think is that the architecture is starting from the business, but ultimately the decision to structure is in fact a business-agnostic part.

Q: Software development has a very famous sentence, that is, there is no silver bullet, considering the business is for elasticity and expansion, and will not limit the start of refactoring, can start from the 82 law. First, find out where the 20% affects 80%.

A: Business always has such a condition, and these conditions, if once become the decision part of the structure, it is easy to lose the original intention of the architecture.

Q: Between business and non-business, it's really bad.

A: Well. There has been such a sentence: Architecture by business, re-construction of heavy skills. I agree with the latter half of the sentence.

Q: In the architecture domain, it is in fact a division of Enterprise architecture and technical architecture. I think you want to express more purely technical architecture. But, in fact, the technical architecture will be affected by the business, and sometimes the impact is very large

Answer: Yes. I'm talking about the technical architecture, not the business architecture.

Q: Can you give an impression of the most deeply involved customer re-architecting examples, the biggest challenges, and how to sort out how to solve

A: Specifically which business is not nominated Ah. Due to historical reasons (people, time, etc.), a project is very fast success, and the annual stability of more than 300 million yuan, but all the developers and operations personnel have been overwhelmed. Code structure confusion, coupling too much, I actually read some of the structure and logic, a lump of a lump, pull a whole body, any small bug, will be a week to fix or even longer.  The project cannot be maintained until later, and the business is not satisfied. Finally, under my advice and leadership, the research and Development department has set up a refactoring group consisting of two architects, a security consultant, a data consultant and N programmers. First, the project's resource blueprint, Structure blueprint, Process Blueprint, and then select one of the most obscure process, isolate the layer and resources, then deep analysis of it, find the crux of the problem, and use the new architecture for the SOA, the final completion of this module. It then undergoes several refactoring of the modules. The whole project was reborn.

Q: A schema with 2 of the n-th can cross-select the scheme how to solve the multivariable

A: In many cross-selection scenarios, if you can choose a solution that is closest to the business and has the possibility to "turn around" at any time, select it, and if there are still multiple scenarios, be prepared and then choose the lightest solution to start a quick trial and error.

Q: Are there more patterns in refactoring?

A: Well, the pattern is indispensable to use, but the purpose must be clear. Resources, code, processes, there are many patterns can be reused, the users and beneficiaries of these patterns are people, managers, developers, operations operators, therefore, friendly is the first.

Q: Do you need to understand the business and comb the business process during this period?

A: Regardless of architecture or refactoring, the business needs to be fully understood.

Q: Refactoring distributed systems, often involving too much, feels the need to refactor in time

A: Well, distributed systems are the hardest to control. You can use some tools or services to fully understand your system. Say, the perspective treasure can accomplish this thing.

Neeke after sharing, received a sound, instant harvest a lot of fans, the scene atmosphere is very lively.

Cloud Wisdom Official Website: www.cloudwise.com

Talking about it architecture and reconstruction (dry goods) from Xizhimen overpass