Shulou(Shulou.com)06/03 Report--

Architects have always been the height of programmers'"envy and pursuit". Today, let's talk about how to define a good architect in my (CEO: sun Xuan) eyes. After all, I used to be an architect:

Before I start today's topic, I'd like to talk about a conversation with my former company, P9, which is now P10.

The problem is that he said that the company's middleware architect is not familiar with the company's business, a lot of things can not be landed, very confused. His recent main task is to chat with these architects:)

And then he told an analogical story that went something like this.

We (architects) are going to build a highway to look at the perspectives of highway builders (architects) and drivers (business research and development).

1. Builders choose the best sand cement, better design drawings and operation procedures to ensure quality and handle abnormal situations (such as entrance tips, overtaking, emergency parking belts)

2, what do drivers care about?

Does the driver have a wide road? can you tell me in advance if there is a traffic jam?

Does the driver care about the smooth road? Of course I care, I care.

This leads to a question: do drivers (business R & D) care about using the best cement?

Imagine you are the driver (business R & D). Do you care?

A, care

B, don't care.

You are welcome to leave a message and leave your thoughts.

I think a good architect needs to have the following four key abilities when designing a system: "balancing trade-offs, predicting the future, abstract thinking, and fault-tolerant mechanisms."

1. Balance trade-off

In essence, there will always be advantages and disadvantages of an architecture, it can not be perfect and universal, and there is no situation in which an architecture can be used in scenario An and is most suitable in scenario B, so we need to make an accurate judgment and make a choice.

We can adjust the architecture according to the specific business needs, that is, according to the current business needs, select the most matching architecture. In addition, the architect needs to weigh the relationship between requirements and resources, efficiency and security, latency and throughput, and so on, based on the status quo.

For example, for online trading systems, it may be more important to ensure its low latency, so a certain amount of throughput can be sacrificed, while for offline systems, throughput is more important.

two。 Predict the future

Architects need to have the ability to predict the future, because the adjustment cycle of the architecture is usually long. This is also a big difference between programmers and architects.

The programmer is responsible for a project, in the current context of the Internet, the iterative cycle of the project is very fast, basically in days or weeks, at most one month. If inappropriate code is found and refactoring is needed, programmers can basically complete the refactoring in a few days or weeks.

The adjustment of the architecture is a relatively long process, which may take months or even years. Therefore, when designing the architecture, the architect needs to have a sense of anticipation and make predictions and choices about many uncertain things, such as what level the traffic will grow in the future, whether new business will be generated, and what new requirements these will bring to the system, and so on.

3. abstraction

In addition to knowing how to choose and have a sense of anticipation, architects should also master abstract methods when designing architectures. they should not grasp the eyebrows at once, but should do a good job of layering and separation.

Because the architect is faced with a very large system, in order to avoid getting caught up in the details too early, do not look at the details of the various components, but define their roles and think about them in pieces. When looking at each block, the other blocks can be regarded as an abstract concept, in addition, we also need to consider the problem of reuse.

For example, when I worked as an online customer service robot on a food delivery platform, I used the idea of layering and high reuse, and a conversation robot can accomplish a variety of business requirements. This is actually a very complex system, in which there are a variety of dialogue robot modules, some are particularly suitable for retrieval queries, and some are suitable for task-oriented, product recommendation-oriented conversations, and so on.

We abstract the conversation robot into a general interface, and then divide it into small robots. In this way, each small robot only needs to focus on its own business module. Then, we will introduce a routing robot at the front end, and the routing robot will determine which small robot should be assigned to complete the current conversation according to the state of the current conversation management. This is the typical hierarchical thinking.

4. Fault-tolerant mechanism

Compared with programmers, architects face a much worse environment, because the system is more complex, the probability of errors increases, and every node and every function can go wrong, so it requires architects to Design For Failure for errors and make solutions in advance.

In addition to application errors, data loss can also occur, which can be prevented by backup.

In addition, if there is a failure, how to achieve rapid recovery? Our common practice now is not to fix it but to change it, because if we want to repair an abnormal state, there may be associated problems after repair, and if we can delete the existing failure by technical means and replace it with a brand-new system, it will be able to ensure that it can quickly return to normal.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.