In the "app backend" QQ group, often asked a question: "How to design a deal with high concurrency architecture." Admittedly, designing a high-concurrency architecture that can handle millions of traffic is an exciting technical challenge, but is it only the design architecture that grows in startups? In this article, I'll talk about my views on this.
1. In most companies, it's hard to meet real high concurrency problems
Once heard more than one netizen said, I want to go to a certain Internet giants work, hope to exercise their own technology, learning high concurrency, high availability, scalable architecture technology.
But kiss, you know? In a large company, a typical working pattern is a screw, a person who is only responsible for a fixed part. Much of the time, these high concurrency, high availability, scalable architecture issues are addressed to those who have previously had this experience.
Think of a reliable, previously successful solution to the relevant high-concurrency experience, and a only mastered the basic theory, did not really practice this aspect of the novice, for cost and risk considerations, suppose you are a company leader, will choose which one?
And in the entrepreneurial company, because are new products, need a little bit of accumulation of users, in the early days there is no chance to encounter the related large-scale concurrency problems.
As for the future there is no chance to meet, hard to say. In the spotlight, see all the winners, losers have been lost in the long river of history. It is highly likely that the project has collapsed when it has not encountered the associated large-scale concurrency problem.
2. Not for technical and technical
For startups, the architectural principle I've been advocating is "to use mature third-party services and software as much as possible, and to be solely responsible for business logic".
Why try to use a mature third party? My reason is that I do it, not necessarily better than a third-party professional team, most of the situation is worse, both wasted energy, and slowed down the progress of the product, why do you have to do it yourself?
Some small partners make the architecture of the background extremely complex, for example, in a common application, not the game, not the chat server, the app and the back end of the communication specifically developed a private socket protocol, rather than simple and easy to implement HTTP. The reason is that the private protocol is secure and saves traffic.
In startups, I always think the biggest cost is the time cost. Initial financing Limited, the face of product pressure, the pressure of investors, as well as the pressure of the team, I think, 3 months of time, how to also out of the product.
Private protocols are more secure and save traffic than HTTP protocols, but private protocols need to be handled by themselves to do the relevant packets, which can take time. And, for most programmers, very familiar with HTTP, but socket programming, many programmers are only in school, there is no real practical experience. These aspects will slow down the product development progress.
Time, the most valuable and overly complex architecture for start-ups, does not apply at the beginning of a startup.
3. Additional growth in start-up companies
(1) opportunities to make technical decisions independently
While in startups, there is no high-concurrency challenge at the beginning, there is a global opportunity to understand the app backend. Backstage each module should have what to solve, each project has specific technology, each technology advantages and disadvantages, these need to back-office research, decision-making.
In startups, there is little to know about back-end technology, Android, iOS, the three-part generalist, the role of technology leader, more is to ensure the smooth development of products, rather than solve specific technical problems. So, you have to evaluate the technology of learning cost, operation and maintenance costs, the impact on the product, this process no colleague can help you, all rely on their own to investigate, solve, every time is a rare opportunity for growth.
(2) to fully understand the birth of the app, the growth process
From the basic needs analysis, to the split module, to the database design, technology selection, and even operation, deployment, accompany the growth of the app.
In this process, we constantly think about why we do this, what the pros and cons are, and what the impact is.
How can anyone who has not been through this process understand the beauty of this?
(3) The growth of alternative
Although the problem with high concurrency is not that every startup app has the opportunity to experience it, some growth, if you have a heart, can achieve:
Have you refactored your code to make it more efficient to execute?
In the face of the painful debugging API experience, have you studied other tools to make debugging APIs more convenient?
Have you ever written an automated ops script to do some common operations?
Do you regularly share with your colleagues the problems and solutions you encounter at work so that we grow together? (Of course, this requires leadership approval.) If the leader does not agree with such a technology sharing meeting, write a blog to share hold on.
Have you studied your own products and commented to the relevant colleagues? Have you ever wondered why a product is designed to meet the needs of the user?
Project hangs up, have you summed up what mistakes the team and yourself have made in this process?
--------------------------------------------------------------------------------------------------------------- ------------
Open the total list of articles in the Link app backend series to see all the original "app backend" articles I've published.
"Author" Zeng Jiansen
"QQ" 190678908
"app back-end QQ Group" 254659220
"public number" Appbackend
"Sina Weibo" @newjueqi
"blog" Http://blog.csdn.net/newjueqi
22. Growth in start-up companies
