互联网应用架构

互联网应用架构

1. Web服务器和应用服务器的区别

Web服务器的设计目的是提供HTTP内容，应用服务器也可以提供HTTP内容，但不限于HTTP，它还可以提供其他协议支持，如RMI / RPC。

1.1 Web服务器

Web服务器的基本功能是提供Web信息浏览服务，它只需支持HTTP协议、HTML文档格式及URL。

如：IIS、Apache、Nginx、lighttpd

1.2 应用服务器

应用服务器一般用于处理动态请求，如请求一个jsp页面，Tomcat应用服务器处理该jsp文件动态生成html页面，再返回前端或返回Web服务器。

如：WebSphere、 WebLogic、JBoss、Tomcat

1.3 两种服务器在应用架构中的层次

Web服务器处于上层，直接面向前端应用，而应用服务器处于Web服务器的下层；通常Web服务层会做反向代理，在外部请求页面时，并不能感知到应用服务器的存在，事实上应用服务层是一个应用服务器集群，处于局域网中，不分配公网IP，能被外部访问且具有公网IP的是Web服务器。

为了提高网站的响应速度，减轻应用服务器（Tomcat，Jboss等）的负载，需要动静分离，对于静态资源比如图片，js，css等文件，可以在反向代理服务器中进行缓存，这样浏览器在请求一个静态资源时，代理服务器就可以直接处理，而不用将请求转发给后端服务器。用户请求的动态文件比如servlet、jsp则转发给Tomcat，Jboss服务器处理。

As web servers are well suited for static content and app servers for dynamic content, most of the production environments have web server acting as reverse proxy to app server. That means while servicing a page request, static contents (such as images/Static HTML) are served by web server that interprets the request. Using some kind of filtering technique (mostly extension of requested resource) web server identifies dynamic content request and transparently forwards to app server.

由于web服务器非常适合用于提供静态内容，而应用服务器适合提供动态内容，因此大多数生产环境都有web服务器充当应用服务器的反向代理。这意味着在页面请求时，web服务器会通过提供静态内容(例如图像/静态HTML)来解释请求，并且它还会使用某种过滤技术(主要是请求资源的扩展)识别动态内容请求，并透明地转发到应用服务器。

2. 互联网应用架构模型

2.1 架构图

2.2 前台应用

指直接供互联网用户使用的应用

2.3 后台应用

指供企业内部运营人员使用的应用，也叫内部管理系统，如：CMS

2.4 功能需求上的不同

前台应用与后台应用面向的用户不同，其功能需求也是不同的，即使有相同的功能需求，也只是一小部分

2.5 非功能需求上的不同

非功能需求	前台应用	后台应用	备注
支撑并发数	用户数量比较多，并且有时不可预估	相对比较固定，主要是相关运营人员使用，所以产生的并发数也相对固定	前台应用应具有很好的伸缩性，支持水平扩容
性能需求	性能要求比较高	性能要求一般，在可接受范围即可	前台应用相对后台应用要配备更多的资源，才能为用户提供更优质的服务。前台应用分配的资源需要足够的富余，避免洪峰到来时，击垮系统，而后台应用则够用即可
数据实时性	通常允许短时间的不一致	通常需要强一致	前台应用使用CAP原理和BASE思想进行设计，为了保证可用性，保证数据的最终一致；而后台应用使用数据事务保证数据强一致
可用性	尽量实现高可用	可用性要求相对比较低	后台应用不可用了，但依然可以找人合作，人工完成一些事情；而前台应用于用户的沟通成本非常高，因系统不可用造成的损失，后果非常严重
部署频率	严格控制应用发布频率	在内部协商后，就可以发布	应用发布都会影响用户的使用，而后台应用因能方便与使用者进行沟通，协调发布时间，而前台应用需要选择使用低峰进行发布
数据查询方式	通常结合缓存，并尽量使用单表查询	尽量少用缓存，以保证数据的实时性，通常会有一些复杂的关联查询	前台应用为了保证数据查询效率，需要使用缓存进行加速，并避免使用复杂的查询；而后台应用通常会做些大批量的数据查询以及复杂的关联查询，以满足业务的需要
安全性	高	一般	前台应用是直接暴露在互联网，需要面对各种风险；而后台应用只能内网访问，风险相对要小些

2.6 架构原则

• 前台应用与后台应用分离

  这里的分离不仅要求部署是分离的，业务相关的代码也是完全分离。

• 前端与后端进行分离

  为了满足不同用户的需求，前端可多种不同的实现，如PC Web页面、H5页面、Android APP、IOS APP，以及各种小程序等。前端与后端的交互通过后端暴露的接口实现，后端接口层可以依赖多个服务，可以组合多个服务的数据返回给前端应用，使用接口层可以屏蔽调用服务的复杂性并实现复用。

• 构建服务应坚持的原则

  • 一个服务只依赖一个数据库
  • 每个服务只依赖单个缓存服务，使依赖更简单，避免相互之间的冲突

• 前台应用的服务与后台应用的服务通过MQ进行解耦

  架构的主要目标是解耦，其次才是复用

3. 架构演进

3.1 单机

简单Web应用

• 访问量小
• Apache/php/Mysql在同一主机上
• 瓶颈
  
  • 通常先出现在数据库，然后才是Apache/php
  • 硬盘I/O (Innodb) 或MyISAM锁等待

3.2 双机

• 访问量逐渐增大
• Apache/php在Server A；MySQL在Server B
• 瓶颈
  
  • 硬盘 I/O (Innodb) 或MyISAM锁等待
  • 网络 I/O

3.3 多机

• 访问量继续增大
• MySQL主从复制及读写分离（master负责insert、update、delete，slave负责select）
• select，insert / update / delete可以在应用程序内指定访问不同服务器（如使用不同的handle或db adapter）
• Web Server可能需要使用负载均衡

3.4 新问题

• Mysql 每台Slave数据完全一样，有的忙，有的闲；数据量越来越大，单表过大，查询效率太低

  通常采用memcached、redis缓存数据，Mysql水平扩展（分库、分表）

• Web Server负载过高

  静态文件缓存 Squid / Varnish / CDN；负载均衡

4. 分布式架构演进

https://www.jianshu.com/p/ab35b6d74fed

5. 常见的互联网分层架构

• 58沈剑 互联网高可用架构技术实践

  https://gitbook.cn/books/583c1335c7f2666319396f7f/index.html

  https://mp.weixin.qq.com/s/8HZoFCYoqVnKUAAkZrwcjw

• https://blog.csdn.net/djr2ss666666/article/details/79619080

6. References

https://blog.csdn.net/zhengchao1991/article/details/52131496

https://www.zhihu.com/question/20096067

https://cloud.tencent.com/developer/article/1008822

https://www.slideshare.net/thinkinlamp/ss-6168749

https://www.jianshu.com/p/ab35b6d74fed

https://gitbook.cn/books/583c1335c7f2666319396f7f/index.html

https://mp.weixin.qq.com/s/8HZoFCYoqVnKUAAkZrwcjw

https://blog.csdn.net/djr2ss666666/article/details/79619080