Zhu Ye's Internet architecture practice experience S1e1:pilot

Zhu Ye's Internet architecture practice experience S1e1:pilot

In recent years, blogging has really been written less, and everything is ready to be written when you are a freshman, and it is worthwhile to try to write a few things over again. Work more than 10 years, to do more than n Internet system, business involves education, games, e-commerce, and so on, peer-to, is a variety of types of Internet systems have touched, how many have some experience, architectural aspects of the article on the Internet a lot, some are said some methodology, some are said some specific cases, The feeling that you want to share is a little different from what others have already shared, or something you should leave behind. Here I would like to share more about building a complete set of Internet system architecture of some specific practical experience, probably from these aspects to write:

1. A variety of nonsense gossip and spit slots
2. Proven Architecture Three carriage: introducing a simple and practical extensible Internet architecture
3. Complementary storage four-piece set: Describe a personal favorite storage combination and the applicable scenario
4. Simple and easy to use monitoring six brothers: introduce some tools that have been used in monitoring and emphasize the importance of monitoring
5. Continuous cultivation of the basic middleware: in the latter part of the project needs to have a sound basic middleware, here to introduce each
6. A headache for a plane changer: Sometimes you need to refactor a high-speed project and share some experience
7. What exactly is a high concurrency architecture: what does high concurrency architecture optimization do in terms of optimization?
8. ...... (Think about it and add it)

About the All-in-one architecture

Many projects start with a All-in-one project, using a set of MVC frameworks, external data controller, service with business logic, Dal to access the database, timed tasks, everything in one project, Then in six months and a year after the business development of the need for the current structure of the reconstruction (said bad hearing is overturned), for the following reasons:

1. More than 5 people in the same large project to modify the code, branch management code conflict resolution costs are too high.
2. As the pressure rises so simple that the offbeat architecture is difficult to split and disperse the pressure so that it does not stand high concurrency.
3. Although for MVC we will have a clear directory to store the logic of the three components but as the business logic becomes more complex, we will have aggregated controllers and aggregated service generation, all components no longer at the same level, the code all stacked together corrupt quickly, Easy to form the trend of copying and pasting.

Unless it is clear that it is an experimental ad hoc project, I personally do not recommend this way to start, using a relatively simple architecture (see article 2) does not waste too much time, but this opening can often avoid the subsequent reversal.

The platform and language for blossoming

I personally from. NET to the Java platform, previous companies have used Php,python,go. Have experienced. NET and PHP to Java, have experienced a mix of various languages of the company. Here are a few things to say:

1. Once made a mistake, when the team is not a small time to allow the retention of both technologies PHP and Java development simultaneously. Regardless of size, each team member needs their own technology development and promotion, each technology stack has different operations, each technology will have their own monster problem, in a small technical team to use multiple technologies at the same time, for the team is really a great consumption. The language does have a role to play, but the development team, which is smaller than 30 people, does not need to fork the technology stack so early.
2. With the expansion of the size of the team, in the recruitment costs, use costs, performance, resource richness and so on, often will be the technology transformation, many platforms spent a few years can not be completely from. NET or PHP to Java, this is a painful process. Although the technical leaders always tend to start using their familiar technology stack to build the system, but have to admit that the Java is a very strong comprehensive language is a good start, open source resources rich, good recruit, master more, development efficiency also live, performance is not bad, less toss will be able to put more energy into business. Not that. NET and PHP are not good, but we finally need to accept a lot of cruel reality.
3. With the expansion of the project scale, many things will need to write their own, open source is often not suitable, this time to play the language of their respective director will appear very important. Go has a unique advantage in terms of performance, portability, development efficiency, high concurrency friendliness, and is a good candidate for developing (network) middleware, and can often replace C. Python's development efficiency is very high, rich class Library Basic any requirements are a line of code an API to solve the problem, as the operational platform for the various tools and crawler development language, but also in the AI is a standout irreplaceable.
4. Development should be more accessible to several languages, which is very beneficial. Some languages have advantages in high concurrency, some languages in the functional programming aspect of the development is very good, some languages in the syntax of sugar design is very beautiful, each language in its characteristics on the level of a higher point, but also easy to learn from other languages, see some of the language will let oneself know each technology can be good to what extent, It is not easy to become a frog in a comprehensive language.

About the platform architecture team and the business team

The technical team to a certain extent will not only split horizontally into the front and back, but also vertically split into the framework team and business team, the development of the middleware or framework of the platform architecture team and the business team of the work of the business code I have stayed. We always throw up the groove when we are in the architecture team:

1. The business team does not want to work with the architecture team to do the technical upgrade, the architecture team hard to do this is not to solve the problem of the business team?
2. The business team is too cautious and conservative, always worried that the schema upgrade affects the existing system, the idea is too old, a little architectural awareness?

When we were in the business team, we would throw up the groove:

1. The architecture team is always high up, they do not understand the complexity of the business, do things that are not practical, so difficult to use things like our soil method.
2. Architecture Team people are not very easy, business team every day to work on the project, the architecture team seems to be in tea chat research some impractical things.

Here are a few ideas to express:

1. Technology development to a certain extent, must be some middleware or framework to do the unification of things, these middleware together to form a platform (see article 5) can greatly reduce the problem of troubleshooting time, also can make some high concurrency optimization work easier.
2. Architects of the architecture team are best able to work on the business team and know where the pain points are, so that the developed systems and tools can match the company's current projects to make the most of them.
3. When doing a schema upgrade, the less intrusive the better, the better the business team has no sense, as long as some of our core architecture frameworks and middleware are already standardized, some frameworks are still self-developed, and in some of these later, we will refer to this view.
4. Do business often change big, we will always get used to a lot of things manual to do, slowly formed to the tool automation concept is not so keen. It would be a good thing if there were outsiders involved at this time who might be able to collide with a lot of good frameworks and tools to help us improve our productivity.