上周没写东西，这周写点互联网系统开发中需要了解的技术点，每个点都可以发散出去，连接更多的知识点，打算做个逐步细化的记录。
一个应用的整个生命周期中(生，老，病，死)都需要有一个整体规划.
评估需求，根据需求提炼出其中隐含的非功能性要求，做为容量评估的参考。一般就是大致估算一下，技术发展到现在，如果是聊天或游戏应用，随便一个服务器单机能能维持100W-160W左右的tcp长连接并进行通讯。所以普通的创业起步阶段的应用一般不必太担心设计问题，可以等业务量慢慢上来慢慢调整系统架构。
互联网上许多数不清的小系统上线就是在碰运气，在精益创业的指导下，为了测试业务模式，先弄个原型系统上了再说。有时没用户，用户多了又顶不住，要找一群外援专家来救火，也算是幸福的烦恼。有些移动应用作者自己也不知道为什么突然就火了，然后又快速消失在市场中。
以http请求到达服务器的整个处理过程来说明。从服务器接收到http请求，在整个反应链路上直到打到最终数据库上，每个可能的瓶颈点上都有相应地技术来支撑性能上的优化。
如一个业务系统用户有五百万，需要根据活跃用户在业务的高峰时期估算最大http请求数量，根据请求量设计前端反向代理，负载均衡策略；这块要考虑常见（软/硬负载方式）反向代理设施的差异性(nginx,lvs,f5,haproxy)
Nginx：HTTP层负载均衡，反向代理，跑遍全球的选择。由于工作在七层上，所以可以支持对http url级别的转发。随便在网上偶遇个bug可能都是曝出一个enginx bad gateway的错。
lvs：tcp/udp层负载均衡，由于工作在四层，面对的都是连接，处理的都是dst ip,port；src ip，port的东西。
常用的转发模式有DR(修改目标地址MAC)，流量经过lvs，但ip包的返回不经过lvs，性能较好，lvs不会成为瓶颈。
NAT：网络包的进出都要经过lvs，对lvs的负载会比DR模式高。
为了除单点，lvs的高可用需要用keepalived做双机主备。
硬件产品，价格昂贵，价格很容易上百万，有问题找厂家，其实这样有时找线上找问题反而受到制约。
均衡器之后就是这里，这层级的缓存是为了减少应用服务器上大量静态小文件(css,js,jpg)的读取压力。可选的有varnish,squid等。
Squid:老牌产品，支持正向/反向代理缓存，作为可持久化缓存，可以支持较大的容量，有自有的内存页/磁盘页管理，有些cdn产品也是基于此产品改造。
Varnish：设计为内存缓存，内存管理由操作系统控制，对于无持久化需求的静态文件性能不错，如图片。
ngnix：扩展功能不错，也有个缓存模块，不过通常都是缓存自身的一些page。
Apache Traffic Server: Apache出品，也可作为一个不错的选择。
反向代理之后的应用服务器数量(tomcat,jetty)要考量应用服务器本身的处理能力，如常规tomcat基准数据是1000qps,这个只是tomcat在开nio情况下平均的水平。
其处理性能还受到应用程序内处理逻辑，如缓存的应用，服务化应用在应用间rpc的消耗的时间。
最后打在数据库上数据库上之前还有大把的活需要做，减少数据库的负担。
又十点多了，下次再继续吧。
文章来自微信平台「麦芽面包」。转载请注明。
原文地址：http://blog.csdn.net/darkjune/article/details/46675127
