转载

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的消耗的时间。

最后打在数据库上数据库上之前还有大把的活需要做,减少数据库的负担。又十点多了,下次再继续吧。

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

正文到此结束
Loading...