1. All kinds of idle chatter and teasing

2. Tried-and-true Architecture 3: Introduces a simple, practical, scalable Internet architecture

3. Four complementary storage sets: This section describes a storage combination that you like and the application scenario

4. Simple and easy to use monitoring six brothers: introduce some monitoring tools that have been used and emphasize the importance of monitoring

5. Continuous cultivation of basic middleware: The middle and late projects need perfect basic middleware, which will be introduced here one by one

6. Frustrating engine changes: Sometimes high-speed projects need to be restructured. Here are some lessons

7. Thirty Architectural design Patterns (PART I) : Give my own understanding of some architectural design patterns summarized by Microsoft

8. Thirty Architectural design Patterns (part 2) : Give my own understanding of some architectural design patterns summarized by Microsoft

9. Architecture review and architecture document: 100 questions of architecture review and 5 elements of architecture document summarized by myself

Many projects start off as an all-in-one project, with a set of MVC frameworks, controllers that provide external data, services that contain business logic, DAL that access databases, scheduled tasks, All In One project, Then, six months and a year later, the business developed and needed to reconstruct the current architecture (to put it mildly, it was overturned and started all over again) for the following reasons:

1. With more than 5 people modifying code in a large project, branch management code conflict resolution costs are too high.

2. As the pressure rises, it is difficult for such a simple gut architecture to split and disperse the pressure, thus failing to withstand high concurrency.

3. Although we will have a clear directory for MVC to store the logic of the three components, as the business logic becomes more and more complex, we will have aggregated Controller and aggregated Service. All components are no longer in the same horizontal plane, and the code is piled up and rots quickly, which is easy to form the tendency of copy and paste.

I personally don’t recommend starting a project in this way unless it’s clearly experimental and tentative. Using a relatively simple architecture (see article 2) doesn’t take too much time, but the start can often avoid a do-over later on.

I personally moved from.NET to The Java platform. My previous companies used PHP, Python, and Go. I’ve been through.net and PHP to Java, and I’ve been through companies that have mixed languages. Here are a few things I would like to say:

1. Made the mistake of allowing two technologies to develop simultaneously PHP and Java when the team was small. Regardless of size, each team member needs his own technology development and promotion. Each technology stack has different operation and maintenance methods, and each technology has its own monster problems. Using multiple technologies in a small technical team at the same time is really a big consumption for the team. Languages do have their place, but teams of less than 30 people don’t really need to fork the tech stack so early.

2. With the expansion of team size, problems such as recruitment cost, usage cost, performance, resource richness and so on often result in technical transformation. Many platforms are unable to completely change after several years. NET or PHP to Java, which is a painful process. Although technical director always tend to use their familiar technology stack initially to build system, but had to admit that the Java this comprehensive very strong language is a good way to start, open source resources are rich, good people, master more, still bad. development efficiency and performance is not poor, less devices will be able to concentrate more on the business. It’s not that.NET and PHP are bad, but there are a lot of harsh truths we need to accept in the end.

3. As projects grow in size, a lot of things will inevitably need to be written by yourself, and open source is often not suitable, so it is important to leverage the strengths of each language. With its unique advantages in terms of performance, portability, development efficiency, and high concurrency friendliness, Go is a good candidate for developing (network) middleware, often replacing C. The development efficiency of Python is extremely high, and the rich class library basically solves any requirement with one line of code and one API. As a development language for various tools and crawlers of operation and maintenance platform, Python is also irreplaceable in terms of AI.

4. It’s good to be exposed to multiple languages. Some language has an advantage in high concurrency and some language in the development of functional programming is very good, some languages in terms of syntactic sugar design is very beautiful, each language in its characteristic on the level will be higher, also easy to draw lessons from other languages, see some language will let you know every technology can good to what degree, It is not easy to become a frog in a well in a comprehensive language.

At a certain point, the technical team will split horizontally not only into front, middle and back, but also vertically into the framework architecture team and the business team. I have been in both the platform architecture team that develops middleware or frameworks and the business team that focuses on the business code. When we build teams, we always say:

1. The business team is not willing to cooperate with the architecture team to upgrade technology. Isn’t the architecture team working so hard to solve the problems of the business team?

2. The business team is too cautious and conservative, always worried about the impact of architectural upgrades on existing systems, thinking too old and not having any architectural awareness?

In the business team, we say,

1. The architecture team is always superior. They can’t realize the complexity of the business, and the things they make are not practical at all.

2. Is the architecture team very relaxed? The business team works overtime every day to work on the project.

Here I would like to express several views:

1. As the technology develops to a certain extent, some middleware or frameworks are required to do unified things. These middleware combined together form a platform (see Article 5), which can greatly reduce the time for troubleshooting problems and make the optimization work under high concurrency easier.

2. The architects of the architecture team should have deep experience in the business team and know where the pain points are. In this way, the developed systems and tools can match the current projects of the company and play the most important role, so that everyone loves them.

3. In the process of architecture upgrade, the less intrusive the business is the better, and the business team has no perception of the best. The premise is that some of our core architecture frameworks and middleware have been unified and standardized, and some of the frameworks are better developed by ourselves, which will be mentioned in some later articles.

4. When doing business, there are always big changes. We always get used to doing a lot of things manually first, which gradually makes us not so keen on the concept of instrumentalized automation. It’s a good thing to have an outsider at this point who can bump up frameworks and tools to help us be more productive.