网站架构

大型网站技术架构——网站架构的伸缩性设计

眉间皱痕 提交于 2020-04-06 22:45:28
首先,所谓网站的伸缩性,指 不需要改变网站的软硬件设计,仅仅通过改变部署的服务器数量就可以扩大或者缩小网站的服务处理能力 。在整个互联网行业的发展渐进演化中,最重要的技术就是 服务器集群 ,通过不断地向集群中添加服务器来增强整个集群的处理能力。 一、网站架构的伸缩性设计 1.1 不同功能进行物理分离实现伸缩   (1)纵向分离:将业务处理流程上得不同部分分离部署,实现系统的伸缩性;   (2)横向分离:将不同的业务模块分离部署,实现系统的伸缩性; 1.2 单一功通过集群规模实现伸缩   使用服务器集群,即将相同服务部署在多台服务器上构成一个集群整体对外提供服务。具体来说,集群伸缩性又分为应用服务器集群伸缩性和数据服务器集群伸缩性。这两种集群对于数据状态管理的不同,技术实现也有很大的区别。  It is said that 当一头牛拉不动车的时候,不要去寻找一头更强壮的牛,而是用两头牛来拉车 。 二、应用服务器集群的伸缩性设计 2.1 应用服务器那点必须知道的事儿   (1)应用服务器应该被设计成 无状态 的,即应用服务器不存储请求上下文信息;构建集群后,每次用户的请求都可以发到集群中任意一台服务器上处理,任何一台服务器的处理结果都是相同的;   (2)HTTP本身是一个无状态的连接协议,为了支持客户端与服务器之间的交互,我们就需要通过不同的技术为交互存储状态

互联网公司分布式集群架构图入门解析(简单通俗易懂,超详细)

旧巷老猫 提交于 2020-04-01 00:06:23
互联网公司分布式集群架构图入门解析(简单通俗易懂,超详细) 置顶 2018年11月08日 09:32:44 英俊帅比林 阅读数:1769 标签: 集群 分布式 互联网架构 java 更多 个人分类: JavaWeb 一、小型公司网络架构 狗子是某大学计算机专业本科应届毕业生,由于自己的技术不错,再加上互联网产业的巨大利润的驱使,狗子决定走上创业这条路,于是,狗子联合了同学二黑,鸡子,狗蛋等人花费了几个月的时间写出了一套网站,是关于足球资讯的pc端网站加上手机APP客户端。现在产品测试成功了,准备发布了,狗子想到了两个问题: 1.网站需要服务器 狗子之前所有的代码测试都是在本地服务器或者局域网上进行的,现在需要把产品发布到外网上,让所有的人都能访问,因此再用自己的电脑当服务器显然很不现实,于是,狗子去买了一台服务器,在上面装了jdk,tomcat,mysql等必备环境,把网站搭了起来,又经过了很多测试,运行毫无问题了,通过网站的ip可以访问并且实现功能了,而且app的后台也在服务器上测试成功了,目前公司的架构如图所示: 那么问题又来了: 2.网站需要域名 显然,如果让各地的用户需要记住你服务器的ip地址才能访问你的网站的话,那是会被用户拿刀追着砍的。因此,狗子需要一个便于记住的域名,以后在浏览器输入这个域名就能够访问这个网站,所以,狗子拿着申请下来的各种资质,找到了域名贩卖商

【Other】最近在研究的, Java/Springboot/RPC/JPA等

可紊 提交于 2020-03-29 07:13:10
Dubbo-大波-服务化框架 dubbo_百度搜索 Dubbo与Zookeeper、SpringMVC整合和使用(负载均衡、容错) - 好库文摘 User Guide-zh - Dubbo - Alibaba Open Sesame User Guide-zh - Dubbo - Alibaba Open Sesame 简单之美 | Dubbo架构设计详解 DUBBO Hprose RPC框架 java rpc_百度搜索 谁能用通俗的语言解释一下什么是 RPC 框架? - 知乎 Java程序员的现代RPC指南 - 西代零零发 - 博客频道 - CSDN.NET Hprose_百度搜索 Hprose Hprose Home Hprose首页、文档和下载 - 高性能跨语言 RPC - 开源中国社区 项目 - 码云 - 开源中国 hprose/hprose-doc: Hprose 文档汇总 hprose_百度百科 thrift 和 Hprose有什么区别吗?_百度知道 hprose具体用途案例是什么,看到这个东西但是想不出来具体应用实例和优势? - 知乎 Hprose使用经历 - xiang_quan123的专栏 - 博客频道 - CSDN.NET Hprose 2.0.0 for HTML5 发布,高性能跨语言RPC - 开源中国社区 为什么采用hprosehttpclient

大型网站架构系列:负载均衡详解(2)

北战南征 提交于 2020-03-29 05:20:40
本文是负载均衡详解的第一篇文章,介绍负载均衡算法, 硬件负载均衡。部分内容摘自读书笔记。 三、负载均衡算法 常用的负载均衡算法有,轮询,随机,最少链接,源地址散列,加权等方式; 3.1 轮询 将所有请求,依次分发到每台服务器上,适合服务器硬件同相同的场景。 优点:服务器请求数目相同; 缺点:服务器压力不一样,不适合服务器配置不同的情况; 3.2 随机 请求随机分配到各个服务器。 优点:使用简单; 缺点:不适合机器配置不同的场景; 3.3 最少链接 将请求分配到连接数最少的服务器(目前处理请求最少的服务器)。 优点:根据服务器当前的请求处理情况,动态分配; 缺点:算法实现相对复杂,需要监控服务器请求连接数; 3.4 Hash(源地址散列) 根据IP地址进行Hash计算,得到IP地址。 优点:将来自同一IP地址的请求,同一会话期内,转发到相同的服务器;实现会话粘滞。 缺点:目标服务器宕机后,会话会丢失; 3.5 加权 在轮询,随机,最少链接,Hash’等算法的基础上,通过加权的方式,进行负载服务器分配。 优点:根据权重,调节转发服务器的请求数目; 缺点:使用相对复杂; 四、硬件负载均衡 采用硬件的方式实现负载均衡,一般是单独的负载均衡服务器,价格昂贵,一般土豪级公司可以考虑,业界领先的有两款,F5和A10。 使用硬件负载均衡,主要考虑一下几个方面: (1)功能考虑

国内图片网站Yupoo的架构

冷暖自知 提交于 2020-03-28 09:50:21
之前向大家介绍过全球最大在线图片服务网站 Flickr网站架构 ,Yupoo(又拍网)作为国内最大的图片服务提供商,我们也一起来看看它的架构,同样是提供图片服务,看看他与Flickr的差别在哪里,大家看完本文可以思考一下。 一、先来看看Yupoo网站的基本信息: 带宽:4000M/S ( 参考 ) 服务器数量:60 台左右 Web服务器:Lighttpd, Apache, nginx 应用服务器:Tomcat 其他:Python, Java, MogileFS 、ImageMagick 等 其架构图如下: 原图链接 二、关于 Squid 与 Tomcat Squid 与 Tomcat 似乎在 Web 2.0 站点的架构中较少看到。我首先是对 Squid 有点疑问,对此阿华的解释是"目前暂时还没找到效率比 Squid 高的缓存系统,原来命中率的确很差,后来在 Squid 前又装了层 Lighttpd, 基于 url 做 hash, 同一个图片始终会到同一台 squid 去,所以命中率彻底提高了" 对于应用服务器层的 Tomcat,现在 Yupoo! 技术人员也在逐渐用其他轻量级的东西替代,而 YPWS/YPFS 现在已经用 Python 进行开发了。 名次解释: YPWS--Yupoo Web Server YPWS 是用 Python开发的一个小型 Web 服务器,提供基本的

高可用网站多点部署架构实战经验总结

落花浮王杯 提交于 2020-03-24 06:27:42
本文是学习大型分布式网站架构的技术总结。对架构一个高性能,高可用,可伸缩,可扩展的分布式网站进行了概要性描述,并给出一个架构参考。一部分为读书笔记,一部分是个人经验总结。对大型分布式网站架构有很好的参考价值。 一、大型网站的特点 用户多,分布广泛 大流量,高并发 海量数据,服务高可用 安全环境恶劣,易受网络攻击 功能多,变更快,频繁发布 从小到大,渐进发展 以用户为中心 免费服务,付费体验 二、大型网站架构目标 高性能:提供快速的访问体验。 高可用:网站服务一直可以正常访问。 可伸缩:通过硬件增加/减少,提高/降低处理能力。 安全性:提供网站安全访问和数据加密,安全存储等策略。 扩展性:方便的通过新增/移除方式,增加/减少新的功能/模块。 敏捷性:随需应变,快速响应; 三、大型网站架构模式 分层:一般可分为,应用层,服务层,数据层,管理层,分析层; 分割:一般按照业务/模块/功能特点进行划分,比如应用层分为首页,用户中心。 分布式:将应用分开部署(比如多台物理机),通过远程调用协同工作。 集群:一个应用/模块/功能部署多份(如:多台物理机),通过负载均衡共同提供对外访问。 缓存:将数据放在距离应用或用户最近的位置,加快访问速度。 异步:将同步的操作异步化。客户端发出请求,不等待服务端响应,等服务端处理完毕后,使用通知或轮询的方式告知请求方。一般指:请求——响应——通知 模式。 冗余

架构基本概念和架构本质

浪尽此生 提交于 2020-03-22 17:26:59
CSDN看到一篇介绍架构设计的博客,内容提纲挈领,内容丰富。依据原文整理,加上自己的理解和总结。 推荐给大家。点击原文可以查看出处。 原文链接: https://blog.csdn.net/hguisu/article/details/78258430 什么是架构和架构本质 在软件行业,对于什么是架构,都有很多的争论,每个人都有自己的理解。此君说的架构和彼君理解的架构未必是一回事。因此我们在讨论架构之前,我们先讨论架构的概念定义,概念是人认识这个世界的基础,并用来沟通的手段,如果对架构概念理解不一样,那沟通起来自然不顺畅。 Linux有架构,MySQL有架构,JVM也有架构,使用Java开发、MySQL存储、跑在Linux上的业务系统也有架构,应该关注哪一个? 想要清楚以上问题需要梳理几个有关系又相似的概念:系统与子系统、模块与组建、框架与架构: 区分系统、模块、组件、框架和架构 S君: 区分系统、模块、组件、框架和架构 系统(system)和子系统:有 关联 的个体,根据某种 规则 运行,共同完成独特的 功能 。子系统:系统的组成部分。 模块(module)和组件(component):模块和组件都是系统的组成部分,只是从不同角度拆分系统而已。 从逻辑角度拆分得到的是模块,从物理角度拆分得到的是组件。 模块是为了实现职责分离, 组件是为了实现复用。 框架

架构基本概念和架构本质

可紊 提交于 2020-03-22 17:04:00
3 月,跳不动了?>>> CSDN看到一篇介绍架构设计的博客,内容提纲挈领,内容丰富。依据原文整理,加上自己的理解和总结。 推荐给大家。点击原文可以查看出处。 原文链接: https://blog.csdn.net/hguisu/article/details/78258430 什么是架构和架构本质 在软件行业,对于什么是架构,都有很多的争论,每个人都有自己的理解。此君说的架构和彼君理解的架构未必是一回事。因此我们在讨论架构之前,我们先讨论架构的概念定义,概念是人认识这个世界的基础,并用来沟通的手段,如果对架构概念理解不一样,那沟通起来自然不顺畅。 Linux有架构,MySQL有架构,JVM也有架构,使用Java开发、MySQL存储、跑在Linux上的业务系统也有架构,应该关注哪一个? 想要清楚以上问题需要梳理几个有关系又相似的概念:系统与子系统、模块与组建、框架与架构: 区分系统、模块、组件、框架和架构 S君: 区分系统、模块、组件、框架和架构 系统(system)和子系统:有 关联 的个体,根据某种 规则 运行,共同完成独特的 功能 。子系统:系统的组成部分。 模块(module)和组件(component):模块和组件都是系统的组成部分,只是从不同角度拆分系统而已。 从逻辑角度拆分得到的是模块,从物理角度拆分得到的是组件。 模块是为了实现职责分离, 组件是为了实现复用。 框架

大型网站架构——百万PV网站

给你一囗甜甜゛ 提交于 2020-03-17 01:04:03
实验架构: 黑线是正常情况数据的流向 红色是异常情况下数据流向 实验环境: CentOS7-1(master) 192.168.13.128 nginx反向代理(主)、redis缓存处理器(主)、mysql数据库(主) CentOS7-2(backup) 192.168.13.129 nginx反向代理(备)、redis缓存处理器(备)、mysql数据库(从) CentOS7-3(tomcat1) 192.168.13.130 tomcat(主) CentOS7-4(tomcat2) 192.168.13.131 tomcat(备) 1,安装部署nginx和keepalive服务(主备都需安装) [root@master ~]# systemctl stop firewalld.service ##关闭防火墙 [root@master ~]# setenforce 0 [root@master ~]# rpm -ivh http://nginx.org/packages/centos/7/noarch/RPMS/nginx-release-centos-7-0.el7.ngx.noarch.rpm ##安装nginx源 [root@master ~]# yum install -y keepalived nginx ##下载nginx和keepalive服务 [root

大型网站架构之分布式消息队列

北城余情 提交于 2020-03-14 13:15:45
以下是消息队列以下的大纲,本文主要介绍消息队列概述,消息队列应用场景和消息中间件示例(电商,日志系统)。 本次分享大纲 消息队列概述 消息队列应用场景 消息中间件示例 JMS消息服务 常用消息队列 参考(推荐)资料 本次分享总结 一、消息队列概述 消息队列中间件是分布式系统中重要的组件,主要解决应用耦合,异步消息,流量削锋等问题。实现高性能,高可用,可伸缩和最终一致性架构。是大型分布式系统不可缺少的中间件。 目前在生产环境,使用较多的消息队列有ActiveMQ,RabbitMQ,ZeroMQ,Kafka,MetaMQ,RocketMQ等。 二、消息队列应用场景 以下介绍消息队列在实际应用中常用的使用场景。异步处理,应用解耦,流量削锋和消息通讯四个场景。 2.1异步处理 场景说明:用户注册后,需要发注册邮件和注册短信。传统的做法有两种1.串行的方式;2.并行方式。 (1)串行方式:将注册信息写入数据库成功后,发送注册邮件,再发送注册短信。以上三个任务全部完成后,返回给客户端。(架构KKQ:466097527,欢迎加入) (2)并行方式:将注册信息写入数据库成功后,发送注册邮件的同时,发送注册短信。以上三个任务完成后,返回给客户端。与串行的差别是,并行的方式可以提高处理的时间。 假设三个业务节点每个使用50毫秒钟,不考虑网络等其他开销,则串行方式的时间是150毫秒