web系统架构设计中须要知道的点（前端篇）

上周没写东西，这周写点互联网系统开发中须要了解的技术点，每一个点均可以发散出去，链接更多的知识点，打算作个逐步细化的记录。

一个应用的整个生命周期中(生，老，病，死)都须要有一个总体规划.

前期

评估需求，根据需求提炼出其中隐含的非功能性要求，作为容量评估的参考。通常就是大体估算一下，技术发展到如今，若是是聊天或游戏应用，随便一个服务器单机能能维持100W-160W左右的tcp长链接并进行通信。因此普通的创业起步阶段的应用通常没必要太担忧设计问题，能够等业务量慢慢上来慢慢调整系统架构。

互联网上许多数不清的小系统上线就是在碰运气，在精益创业的指导下，为了测试业务模式，先弄个原型系统上了再说。有时没用户，用户多了又顶不住，要找一群外援专家来救火，也算是幸福的烦恼。有些移动应用做者本身也不知道为何忽然就火了，而后又快速消失在市场中。

前端系统设计模式

以http请求到达服务器的整个处理过程来讲明。从服务器接收到http请求，在整个反应链路上直到打到最终数据库上，每一个可能的瓶颈点上都有相应地技术来支撑性能上的优化。

负载均衡

如一个业务系统用户有五百万，须要根据活跃用户在业务的高峰时期估算最大http请求数量，根据请求量设计前端反向代理，负载均衡策略；这块要考虑常见（软/硬负载方式）反向代理设施的差别性(nginx,lvs,f5,haproxy)

Nginx

Nginx：HTTP层负载均衡，反向代理，跑遍全球的选择。因为工做在七层上，因此能够支持对http url级别的转发。随便在网上偶遇个bug可能都是曝出一个enginx bad gateway的错。

LVS

lvs：tcp/udp层负载均衡，因为工做在四层，面对的都是链接，处理的都是dst ip,port；src ip，port的东西。

经常使用的转发模式有DR(修改目标地址MAC)，流量通过lvs，但ip包的返回不通过lvs，性能较好，lvs不会成为瓶颈。

NAT：网络包的进出都要通过lvs，对lvs的负载会比DR模式高。

为了除单点，lvs的高可用须要用keepalived作双机主备。

F5

硬件产品，价格昂贵，价格很容易上百万，有问题找厂家，其实这样有时找线上找问题反而受到制约。

http缓存

均衡器以后就是这里，这层级的缓存是为了减小应用服务器上大量静态小文件(css,js,jpg)的读取压力。可选的有varnish,squid等。

Squid:老牌产品，支持正向/反向代理缓存，做为可持久化缓存，能够支持较大的容量，有自有的内存页/磁盘页管理，有些cdn产品也是基于此产品改造。

Varnish：设计为内存缓存，内存管理由操做系统控制，对于无持久化需求的静态文件性能不错，如图片。

ngnix：扩展功能不错，也有个缓存模块，不过一般都是缓存自身的一些page。

Apache Traffic Server: Apache出品，也可做为一个不错的选择。

应用服务器

反向代理以后的应用服务器数量(tomcat,jetty)要考量应用服务器自己的处理能力，如常规tomcat基准数据是1000qps,这个只是tomcat在开nio状况下平均的水平。

其处理性能还受到应用程序内处理逻辑，如缓存的应用，服务化应用在应用间rpc的消耗的时间。

最后打在数据库上数据库上以前还有大把的活须要作，减小数据库的负担。
又十点多了，下次再继续吧。

---

文章来自微信平台「麦芽面包」。转载请注明。