互联网高性能高可用高并发结构理解

1|0互联网中三高架构的理解

王建军

(石家庄铁道大学，河北省石家庄市 054000)

摘要：一个小型的网站，可以使用最简单的 html、h5等静态页面或者简单动态页面加数据库就实现了，此种网站只需要简单的系统架构，对于性能的要求不高。但是随着移动应用与网站等多种互联网产品的业务和应用不断壮大，访问用户不断增大，一般的技术架构势必无法承受大量用户高并发访问带来的压力。移动应用与大型网站等多个平台在处理大量用户访问及请求问题时，其基本解决方式为使用高并发的处理技术架构，或性能较高的数据量与服务器，又或是效率较高的编程语言等。

关键词：互联网；负载均衡；高并发；高可用；高性能

1 引言

随着互联网的发展，Web服务端开发技术也经历了几次大的变迁。早期的Web服务器只简单地响应浏览器端的请求，返回静态的 HTML。随着CGI ( Common GatewayInterface，通用网关接口)技术的出现，Web服务端可以根据不同用户请求产生动态页面内容。CGI 处理动态请求的基本过程如图B.1所示，Web服务器将请求数据交给CGI程序，CGI程序进行运算处理，生成HTML输出，通过Web服务器返回给浏览器。早期主要的CGI编程语言是 Perl，高效便捷的开发特性使其成为当时许多网站开发的首选。

1 高并发

高并发英文名称为 High Concurrency，是指通过合理的设计确保系统可以在同一时间内处理众多请求，是一种在分布式网络系统结构设计中重点考虑的因素。与其相关的常用指标有相应时间、吞吐量、并发用户数以及每秒查询率 QPS 等。响应时间：是指系统在请求时所需相应的时间。比如：系统在处理某个 HTTP 请求时，需要花费200ms，那么200ms 就是响应时间。吞吐量：是指在单位时间内的请求处理数量。每秒查询率 QPS：是指每秒相应的请求数。在互联网领域内，此指标与吞吐量的区别并不明显。并发用户数：是指在同一时间内系统能够正常运行时所承载的用户数量。比如：在即时通讯系统中，同时在线数量在某种程度上为并发用户数。

2 高性能、高可用

高可用、高性能是互联网应用与传统应用开发之间差异较大部分，要保证程序高可用、高性能需要架构设计、实现、算法等每个点都是合理的简洁可靠的。因为一个点性能差、一个点不稳定会导致整个系统性能不稳定。高可用互联网程序高可用，即线上服务要保证99.9%以及99.99%可用率。要保证程序高可用需要首先要保证服务存在，服务存在是前提，就需要服务是集群或者分布式的，通过数量备份来保证服务

高可用

集群分布式两种事物本身不是一个概念，但很多人会搞混，集群：一般情况下是多个节点提供相同服务，通过多个节点避免服务只有单个节点，单个节点不可用时线上服务不可用。web服务一般通过nginx反向代理技术，将请求通过ip hash、url hash、随机、轮训、加权轮训等负载均衡算法转发给后端tomcat。

实现高可用

分布式系统：分布式是多个节点协调提供一次计算服务，比如ElasticSearch，用户发出一次请求，多个节点分别进行查询，最终由主节点进行合并排序，排序后将打分结果按分高分低进行返回。线上微服务高性能一是外部存储采用高性能存储，当前互联网公司一般采用redis进行数据存储，redis作为分布式缓存，核心原理是采用hash或树形结构存储数据已达到存储高性能读取数据。使用redis要注意，redis单个节点不稳定，原因有可能是网络，也有可能是有热点key导致，热点key一般是应用程序对于通用数据未采用定时获取方式。redis单个节点会导致集群不稳定、集群不稳定会导致所有线上依赖服务均不稳定。在谈电商双11大促活动备战，双11大促备战时曾遇到这两个问题。

线上服务要在合适场景使用合适数据结构，该使用HashSet时就不能使用ArrayList对于各种各样数据结构操作时间复杂度要详细掌握。HashMap put、get操纵时间复杂度时O(n)，当hash冲突解决采用链表解决的时候。

对于字符串匹配要采用KMP算法，对于搜索中字典统计要采用Trie树结构。

3 伸缩性架构

伸缩性架构设计能力是网站架构师必须具备的能力。

伸缩性架构设计是简单的，因为几乎所有稍有规模的网站都必须是可伸缩的，有很多案例可供借鉴，同时又有大量商业的、开源的提供伸缩性能力的软硬件产品可供选用。然而伸缩性设计又是复杂的，没有通用的、完美的解决方案和产品，网站伸缩性往往和可用性、正确性、性能等耦合在一起，改善伸缩性可能会影响一些网站的其他特性，网站架构师必须对网站的商业目标、历史演化、技术路线了然于胸，甚至还需要综合考虑技术团队的知识储备和结构、管理层的战略愿景和规划，才能最终做出对网站伸缩性架构最合适的决策。

一个具有良好伸缩性架构设计的网站，其设计总是走在业务发展的前面，在业务需要处理更多访问和服务之前，就已经做好充足准备，当业务需要时，只需要购买或者租用服务器简单部署实施就可以了，技术团队亦可高枕无忧。反之，设计和技术走在业务的后面，采购来的机器根本就没办法加入集群，勉强加了进去，却发现瓶颈不在这里，系统整体处理能力依然上不去。技术团队每天加班，却总是拖公司发展的后腿。架构师对网站伸缩性的把握，一线之间，天堂和地狱。

4 总结

上面简单回顾了Web开发的技术发展历程和一些早期主要架构模式，这些模式在企业 Web应用开发中也有许多实践。但是随着互联网应用的快速发展，需求场景和业务领域都有一些和传统企业应用不同的特点，对系统的可用性、扩展性、响应性能、伸缩性、安全性都提出了更高的要求，网站技术架构也和企业应用技术架构脱离，走上了一条更具创新性的发展之路。使项目组内的不同角色专注于自己的工作,让应用软件的设计开发不再难以移植、扩展。

参考文献：

[1] 百度百科，MVC框架，https://baike.baidu.com/item/MVC%E6%A1%86%E6%9E%B6.

[2] 刘克. 上海交通大学软件学院. MVC架构及其在Web应用开发中的应用.

[3] CSDN, MVC架构探究及其源码实现(1)-理论基础, https://blog.csdn.net/zhiqiangzhan/article/details/4697443.

[4] 博客园, MVC在Web框架中的应用，https://www.cnblogs.com/goldenyi/p/6939654.html.

__EOF__

本文作者：往心。
本文链接：https://www.cnblogs.com/lx06/p/16274692.html
关于博主：评论和私信会在第一时间回复。或者直接私信我。
版权声明：本博客转载请注明出处！
声援博主：如果您觉得文章对您有帮助，可以点击文章右下角【推荐】一下。您的鼓励是博主的最大动力！