在“app后端”qq群中，经常被问到的一个问题：“怎么设计一个应付高并发的架构”。诚然，设计一个能应付百万流量的高并发架构，是很令人兴奋的技术挑战，但在创业公司中的成长，难道就只有设计架构吗？在这篇文章中，谈谈我对这方面的看法。 　　

1. 在大多数的公司中，很难遇到真正的高并发问题

曾经听不止一位网友说过，自己想去某某互联网巨头工作，希望能锻炼自己的技术，学习高并发，高可用，可伸缩的架构技术。

但亲，你知道吗？在大型公司中，一个典型的工作模式是螺丝钉，一个人只负责固定的一部分。很多时间，这些高并发，高可用，可伸缩的架构问题，都给以前有这方面经验的人去解决。
　　
想想，一个靠谱，以前有成功解决相关高并发经验的人，和一个只掌握了基本理论，没真正实践过这方面的新手，出于成本和风险的考虑，假设你是一个公司的领导者，会选择哪一个呢？
　　
　　而在创业型公司里，由于都是新生的产品，需要一点点积累用户，在初期没啥机会遇到相关的大规模的并发问题。
　　
　　至于以后有没有机会遇到，很难说。在聚光灯下，看到的都是成功者，失败者早已湮没在历史的长河里。极大可能当没遇到过相关的大规模的并发问题，项目就已经倒下了。 　　

2. 不为了技术而技术

　　
　　对于创业公司来说，我一直推崇的架构原则是“尽量使用成熟的第三方服务和软件，自己只负责业务逻辑”。
　　
　　为啥要尽量使用成熟的第三方？我的理由是，自己去做，不见得比第三方的专业团队做得更好，大多数情况是更糟的，既浪费了精力，又拖慢了产品的进度，为啥还要自己弄呢？
　　
　　有的小伙伴把后台的架构弄得无比复杂，例如，就一个普通的应用，不是游戏，不是聊天服务器，app和后端的通讯专门开发一个私有的socket协议，而不采用简单容易实现的http。理由是私有协议安全，省流量。
　　
　　在创业公司里，我一直认为最大的成本是时间成本。初期融资有限，面对产品的压力，投资人的压力，还有，团队的压力，我觉得，3个月的时间，怎么也要出产品。
　　
　　私有协议比起http协议是更安全，省流量，但私有协议需要自己去做相关的封包，解包的处理，这都需要耗费时间。而且，对于大多数程序员来说，非常熟悉http，但socket编程，很多程序员都只在学校中学过，没有真正的实践经验。这些方面都会拖慢了产品的开发进度。
　　
　　时间，对于初创团队来说是最宝贵，过于复杂的架构，在创业初期，根本不适用。 　　

3. 在创业公司中的额外成长

　　
（1） 独立做技术决策的机会
　　
　　虽然在创业公司里，初期没法面对高并发的挑战，但会有全局了解app后端的机会。后台每个模块应该有哪些方案去解决，每个方案有哪些具体的技术，每种技术的优缺点，这些都需要后台去调研，决策。
　　
　　创业公司里，很少有全面了解后端技术，android, ios 这三方面的通才，技术负责人的角色，更多的是保证产品的顺利研发，而不是解决具体每个技术问题。所以，你要评估这个技术的学习成本，运维成本，对产品的影响，这个过程没有同事能帮助你，都要靠自己去调研，解决，每次都是难得的成长机会。
　　
（2） 全面去了解app的诞生，成长过程
　　
　　从基础的需求分析开始，到分拆模块，到数据库设计，技术的选型，甚至是运维，部署，陪伴着app的成长。
　　
　　这个过程中，我们会不断地思考为什么要这样做，这样做的优缺点是什么，有什么影响。
　　
　　没有完整经过过这个过程的人，怎么会了解这这里面的风光呢？
　　
（3） 另类的成长
　　
　　虽然，高并发的问题不是每个初创app都有机会经历，但一些成长，只要你有心，就能实现：
　　
　　 你有重构过自己的代码，使它的执行效率更好吗?
　　
　　面对痛苦的调试api的经历，你有研究过其他工具，使调试api更加方便吗？
　　
　　 你有写过自动化的运维脚本，进行一些常见的运维工作吗？
　　
　　你有定期和同事分享自己在工作中遇到的问题和解决方案，使大家一起成长吗？（当然了，这个需要领导批准。如果领导不同意这样的技术分享会，就写博客分享憋）
　　
　　你有研究过自己的产品，给相关的同事提过意见吗？你是否想过产品为啥要这样设计，迎合了用户的哪些需求呢？

项目挂掉了，你有总结出在这个过程，团队和自己犯过哪些错误吗？

转自：CSDN