互联网三高架构：高并发、高性能、高可用

后端码匠

发布于 2020-09-15 15:11:27

2.7K0

发布于 2020-09-15 15:11:27

文章被收录于专栏：后端码匠后端码匠

面向互联网的三高系统，最关注的软件质量属性是：性能、可用性、伸缩性、扩展性、安全性。

而构建此类系统，最常见的架构模式有：横向分层、纵向分割、分布式化、集群化、使用缓存、使用异步模式、使用冗余、自动化（发布、部署、监控）。

具体来说，可以在不同层次常用的技术有：

前端架构

浏览器优化技术：合理布局，页面缓存，减少http请求数，页面压缩，减少 cookie 传输。

1）CDN

CDN的基本原理是广泛采用各种缓存服务器，将这些缓存服务器分布到用户访问相对集中的地区或网络中，在用户访问网站时，利用全局负载技术将用户的访问指向距离最近的工作正常的缓存服务器上，由缓存服务器直接响应用户请求。

2）DNS负载均衡
3）动静分离，静态资源独立部署，动态图片独立提供服务

应用层架构

1）业务拆分
2）负载均衡
3）虚拟化服务器、容器化
4）无状态（以及分布式 Session）

分布式Session有如下几种实现方式。

1.Session复制机制

在支持Session复制的Web服务器上，通过修改Web服务器的配置，可以实现将Session同步到其它Web服务器上，达到每个Web服务器上都保存一致的Session。

优点：代码上不需要做支持和修改。

缺点：需要依赖支持的Web服务器，一旦更换成不支持的Web服务器就不能使用了，在数据量很大的情况下不仅占用网络资源，而且会导致延迟。

适用场景：只适用于Web服务器比较少且Session数据量少的情况。

可用方案：开源方案tomcat-redis-session-manager，暂不支持Tomcat8。

2.Session粘滞机制

将用户的每次请求都通过某种方法强制分发到某一个Web服务器上，只要这个Web服务器上存储了对应Session数据，就可以实现会话跟踪。

优点：使用简单，没有额外开销。

缺点：一旦某个Web服务器重启或宕机，相对应的Session数据将会丢失，而且需要依赖负载均衡机制。

适用场景：对稳定性要求不是很高的业务情景。

3.Session集中管理机制

在单独的服务器或服务器集群上使用缓存技术，如Redis存储Session数据，集中管理所有的Session，所有的Web服务器都从这个存储介质中存取对应的Session，实现Session共享。

优点：可靠性高，减少Web服务器的资源开销。

缺点：实现上有些复杂，配置较多。

适用场景：Web服务器较多、要求高可用性的情况。

可用方案：开源方案Spring Session，也可以自己实现，主要是重写HttpServletRequestWrapper中的getSession方法，博主也动手写了一个，github搜索joincat用户，然后自取。

4.基于Cookie管理机制

这种方式每次发起请求的时候都需要将Session数据放到Cookie中传递给服务端。

优点：不需要依赖额外外部存储，不需要额外配置。

缺点：不安全，易被盗取或篡改；Cookie数量和长度有限制，需要消耗更多网络带宽。

适用场景：数据不重要、不敏感且数据量小的情况。

最后的总结

以上四种方式，相对来说，Session集中管理更加可靠，使用也是最多的。

5）分布式缓存

分布式缓存的典型应用场景可分为以下几类:

页面缓存.用来缓存Web 页面的内容片段,包括HTML、CSS 和图片等,多应用于社交网站等;
应用对象缓存.缓存系统作为ORM 框架的二级缓存对外提供服务,目的是减轻数据库的负载压力,加速应用访问;
状态缓存.缓存包括Session 会话状态及应用横向扩展时的状态数据等,这类数据一般是难以恢复的,对可用性要求较高,多应用于高可用集群;
并行处理.通常涉及大量中间计算结果需要共享;
事件处理.分布式缓存提供了针对事件流的连续查询(continuous query)处理技术,满足实时性需求;
极限事务处理.分布式缓存为事务型应用提供高吞吐率、低延时的解决方案,支持高并发事务请求处理,多应用于铁路、金融服务和电信等领域.

异步、事件驱动架构、消息队列

EDA是一种以事件为媒介，实现组件或服务之间最大松耦合的方式。传统面向接口编程是以接口为媒介，实现调用接口者和接口实现者之间的解耦，但是这种解耦程度不是很高，如果接口发生变化，双方代码都需要变动，而事件驱动则是调用者和被调用者互相不知道对方，两者只和中间消息队列耦合。

多线程

动态页面静态化

我们只需要编写这么一个HttpModule就可以了，当用户第一次请求asp处理时，我们可以在ihttpmodule中拦截到这个请求，然后获取到这次请求应该返回的html代码，然后我们返回这些html给用户，并保存刚才我们获取到的html到文件内，当用户下次请求时，我们只需要直接返回我们已经保存的html文件即可。