通过轻量级远程通信协议(比如REST)来交互

互联网发展史_互联网_IT/计算机_专业资料。Web架构技术变迁 谢彦浩 1 发展史 什么是架构 架构通常指的是技术架构,更具体一 点的说是系统架构、软件架构,或者 是最常见的网站架构...


  互联网发展史_互联网_IT/计算机_专业资料。Web架构技术变迁 谢彦浩 1 发展史 什么是架构 架构通常指的是技术架构,更具体一 点的说是系统架构、软件架构,或者 是最常见的网站架构。 单机时代 分布式时代 集群时代 1 单

  Web架构技术变迁 谢彦浩 1 发展史 什么是架构 架构通常指的是技术架构,更具体一 点的说是系统架构、软件架构,或者 是最常见的网站架构。 单机时代 分布式时代 集群时代 1 单机时代 互联网早期,产品团队初创之时,资源有限,人力不足, 为了快速开发一个产品,或上线一个网站,单机往往是一 个不错的选择,此时会将应用程序、文件服务、数据库服 务等资源集中在一台 Server 上。 1 单体架构 单机时代 优点:简单快速,易于开发,易 于测试,易于部署 缺点:也非常显著,只适合早期 项目,变大后不易维护,且存在 单点,升级需要停服 应用程序通常整体打包和部署,具体格式依赖于应用的语言和框架,例如 Java 的 WAR 文件、Rails 的目录文件,此种架构通常称为单体架构。 1 分层架构 单机时代 优点:结构简单,分工明确,分 层测试,如果你不知道用什么软 件架构时,推荐用它 单体架构显得杂乱无章,这在早期的 Web 开发中可能存在,比如使用JSP+JDBC, ASP+ADO,但这显然不是一个友好的标准架构,于是分层架构应运而生,分层架构如下 图所示,一般分为表现层(presentation)、业务层(business)、持久层(persistence) 和数据库(database)。这其实也是最常见的MVC架构了。 缺点:扩展性差,迭代开发效率 低,有时候层次过多导致流程复 杂 1 数据分离 单机时代 优点:资源分散,提高不同服务 对硬件的利用率,方便维护 添加了分层架构,应用上好看点了,团队的开发效率有了一定的提升。此时业务量进一 步增大,并且有了一定的用户规模,逐渐发现一台主机上应用和数据资源争夺的非常厉 害。因为每种服务对硬件资源的要求是不同的,应用服务器需要更快的CPU,文件服务 器需要更大的硬盘,数据库服务器需要更大的内存和硬盘,于是决定把应用和数据服务 分离 缺点:增加了资源消耗和网络开 销,同时还存在单点 1 缓存 单机时代 优点:简单有效,减少对 DB 的 查询 产品有了一定的口碑,用户量持续增长,访问开始频繁,想提升访问速度,缓存必 不可少,闪亮登场。 服务端缓存又可以分为本地缓存和远程缓存,各有优劣,本地缓存访问速度快,但 数据量有限,而且后续集群化不方便共享;远程缓存可以共享,可以集群,容量不受限 制,但要注意缓存更新的问题。 缺点:增加逻辑判断,不适合存 储大对象,此架构同样有单点 1 单机时代 读写分离----一主多从,读写分离,主动同步 优点:降低数据库单台压力,从 机的数量可以灵活变更 市场反响不错,业务也在持续增长,但性能又有所下降,分析整个架构,发现数据 库读写非常频繁,甚至有些业务,读大于写,单台数据库服务器又成了瓶颈,此时就可 以尝试做读写分离和主从复制了。 读写分离主要解决“数据库读性能瓶颈”问题,在数据库扛不住读的时候,通常读 写分离,通过增加从库线性提升系统读性能。 缺点:架构开始变得复杂,维护 难度加大 1 集群时代 单机时代,做了不少措施来缓解数据库层的压力,包括 服务器分离、引入缓存、数据分离等,但随着访问量的猛 增,对高可用的要求越来越高,减轻应用层压力、解决单 点问题是当务之急,这就是集群时代需要做的事情。 1 负载均衡 集群时代 优点:去除应用层单点,可用性 得到保证,性能有所提高 代码是架构的基础,但前期改造代码的工作量较大,如果人员变动频繁,那风险就 更高了,所以提高服务器性能,常用的手段还是先将应用集群化,做负载均衡。 缺点:这时要注意应用之间的一 致性问题,比如对缓存的访问, 对Session的存储 1 动静分离 集群时代 优点:减轻应用服务器压力,缓 存静态文件,加快响应速度,前 后端分离,开发可以并行。 动静分离是让动态网站里的动态网页,根据一定规则把不变的资源和经常变的资源 区分开来,动静资源做好了拆分以后,我们还可以根据静态资源的特点将其做缓存操作 (后来的CDN),以加快响应速度。 常用做法还会将前后端分离,后端应用提供API,根据前端的请求进行处理,并将处 理结果通过JSON格式返回至前端。 缺点:静态文件缓存更新失效问 题,前后端沟通成本提高 1 CDN加速 集群时代 优点:解决网络带宽小、用户访 问量大、网点分布不均等问题, 提高用户访问的响应速度,减轻 应用负载压力。 将源内容同步到全国各边缘节点,配合精准的调度系统,将用户的请求分配至最适 合他的节点,使用户可以以最快的速度取得他所需的内容。 缺点:显然成本上去了,CDN服 务一般是按流量计费,同时也存 在静态文件缓存更新失效问题。 1 冗余集群 集群时代 优点:去单点,高可用。 以上一个中型网站架构基本成型。当中型网站继续向大型网站演进,最终的目标是 要保证“三高”:高并发、高性能、高可用。以上架构基本可以满足性能需求,接下来 更多的是关注“高可用”,确保“无单点”。 此时,就要对关键的服务,做冗余集群负载。 理想情况下,我们将以下服务/应用都集群化: 数据库服务集群、文件服务集群、缓存服务集群、应用服务集群、负载均衡调度器集群 静态内容服务集群、CDN服务器集群 缺点:数据有状态问题、数据一 致性问题,资源成本、人力维护 成本都上去了。 到此为止,一个大型网站的架构也基本成型了,能“加机器”的地方都加完了。 终结???? NO 1 分布式时代 伴随着分布式时代的到来,大流量和大数据的场景的出 现,对应用提出了更高的要求,接下来就需要对应用程序 开刀了。 1 应用拆分 分布式时代 优点:应用解耦,分拆团队负责, 分而治之。 缺点:架构变复杂。 在前面,我们只是把应用程序做了分层架构,在创业初期或产品前期还是一个不错 的选择。虽然应用也做了集群和负载均衡,但应用架构层面还是“集中式”的。随着业 务越来越复杂,网站的功能越来越多,应用拆分势在必行了。 应用拆分之后,还伴随着一个相互依赖、公共模块的问题,特别是依赖于相同的逻 辑或功能代码。这时就可以考虑将这些共用的服务提取出来,独立部署,统一治理,提 高重用度,这就是面向服务的架构(service-oriented architecture,缩写 SOA)了。 1 消息队列 分布式时代 优点:异步、解耦,提高吞吐量。 缺点:消息消费延迟等问题。 应用拆分、服务独立部署之后,还是会出现一些通信或依赖问题,这时就可以引入 消息队列,提高吞吐量。 1 数据分库 分布式时代 优点:DB分压,降低耦合。 缺点:数据访问模块冗余、复杂。 应用拆分之后,DB分库理所当然,否则多个应用连接在单个数据库上,连接数、QPS、 TPS、I/O处理能力都非常有限。 1 分布式时代 微服务架构 优点:扩展性好,服务之间耦合 性低,服务间相互独立,容易部 署,易于开发,方便测试每一个 服务。 缺点:容易过度关注服务的大小,可能 拆分的很细,导致系统依赖于大量的微服 务,而服务之间的相互通信也会变得复杂, 系统集成复杂度增加,很难实现原子性操 作。 微服务架构由多个微小服务构成,每个服务就是一个独立的可部署单元或组件,它 们是分布式的,相互解耦的,通过轻量级远程通信协议(比如REST)来交互,每个服务 可以使用不同的数据库,而且是语言无关性的。它的特征是彼此独立、微小、轻量、松 耦合,又能方便的组合和重构,犹如《超能陆战队》中的微型机器人,个体简单,但组 合起来威力强大。 微服务之所以这么火,另一个原因是因为Docker的出现,它让微服务有一个非常完美的运行环境, Docker 的独立性和细粒度非常匹配微服务的理念,Docker的优秀性能和丰富的管理工具,让大家对微服务 有了一定的信息,概括来说 Docker 有如下四点适合微服务: 独立性:一个容器就是一个完整的执行环境,不依赖外部任何的东西。 细粒度:一台物理机器可以同时运行成百上千个容器。其计算粒度足够的小。 快速创建和销毁:容器可以在秒级进行创建和销毁,非常适合服务的快速构建和重组。 完善的管理工具:数量众多的容器编排管理工具,能够快速的实现服务的组合和调度。 当然,好的架构和技术,要应用于实践、让用户认可才行,这就需要在微服务架构和 Docker 技术之上有 丰富的场景化应用。 对比 至此,架构变迁的三个时代介绍完成。总的来说架构不是 一成不变的,时间不停,进步不止,人如此,架构依然。 2 接入层技术演进 2 接入层技术演进 nginx、lvs、keepalived、f5、DNS轮询,每每提到这 些技术,往往讨论的是接入层的这样几个问题: 1)可用性:任何一台机器挂了,服务受不受影响 2)扩展性:能否通过增加机器,扩充系统的性能 3)反向代理+负载均衡:请求是否均匀分摊到后端的操作单元执行 2 接入层技术演进 名词解释 1)nginx:一个高性能的web-server和实施反向代理的软件 2)lvs:Linux Virtual Server,使用集群技术,实现在linux操作系统层面的一个高性能、 高可用、负载均衡服务器 3)keepalived:一款用来检测服务状态存活性的软件,常用来做高可用 4)f5:一个高性能、高可用、负载均衡的硬件设备(听上去和lvs功能差不多?) 5)DNS轮询:通过在DNS-server上对一个域名设置多个ip解析,来扩充web-server性能 及实施负载均衡的技术 2 接入层技术演进 单机时代----裸奔时代 优点:非高可用,web-server挂 了整个系统就挂了。 缺点:扩展性差,当吞吐量达到webserver上限时,无法扩容。 裸奔时代的架构图如上: 1)浏览器通过DNS-server,域名解析到ip 2)浏览器通过ip访问web-server 2 DNS轮询 接入层技术演进 假设tomcat的吞吐量是1000次每秒,当系统总吞吐量达到3000时,如何扩容是首先 要解决的问题,DNS轮询是一个很容易想到的方案。 优点: 1)零成本:在DNS-server上多配几个ip即可,功 能也不收费。 2)部署简单:多部署几个web-server即可,原系 统架构不需要做任何改造。 3)负载均衡:变成了多机,但负载基本是均衡的。 此时的架构图如上: 1)多部署几份web-server,1个tomcat抗1000,部署3个 tomcat就能抗3000 2)在DNS-server层面,域名每次解析到不同的ip 缺点: 1)非高可用:DNS-server只负责域名解析ip,这 个ip对应的服务是否可用,DNS-server是不保证的, 假设有一个web-server挂了,部分服务会受到影响 2)扩容非实时:DNS解析有一个生效周期。 3)暴露了太多的外网ip。 2 nginx 接入层技术演进 tomcat的性能较差,但nginx作为反向代理的性能就强多了,假设线w,就比 tomcat高了10倍,可以利用这个特性来做扩容。 优点: 1)DNS-server不需要动 2)负载均衡:通过nginx来保证 3)只暴露一个外网ip,nginx-tomcat之间使用内 网访问 4)扩容实时:nginx内部可控,随时增加webserver随时实时扩容 5)能够保证站点层的可用性:任何一台tomcat挂 了,nginx可以将流量迁移到其他tomcat 缺点: 1)时延增加+架构更复杂了:中间多加了一个反 向代理层 2)反向代理层成了单点,非高可用:tomcat挂了 不影响服务,nginx挂了怎么办? 此时的架构图如上: 1)站点层与浏览器层之间加入了一个反向代理层,利用高 性能的nginx来做反向代理。 2)nginx将http请求分发给后端多个web-server。 2 接入层技术演进 keepalived 为了解决高可用的问题,keepalived出场了 优点: 1)解决了高可用的问题 此时: 1)做两台nginx组成一个集群,分别部署上keepalived,设 置成相同的虚IP,保证nginx的高可用 2)当一台nginx挂了,keepalived能够探测到,并将流量自 动迁移到另一台nginx上,整个过程对调用方透明 缺点: 1)资源利用率只有50% 2)nginx仍然是接入单点,如果接入吞吐量超过的 nginx的性能上限怎么办,例如qps达到了50000咧? 2 lvs/f5 接入层技术演进 nginx毕竟是软件,性能比tomcat好,但总有个上限,超出了上限,还是扛不住。 lvs就不一样了,它实施在操作系统层面;f5的性能又更好了,它实施在硬件层面;它们 性能比nginx好很多,例如每秒可以抗10w,这样可以利用他们来扩容,常见的架构图如 下: 此时: 1)如果通过nginx可以扩展多个tomcat一样,可以通过lvs来 扩展多个nginx 2)通过keepalived+VIP的方案可以保证可用性 2 接入层技术演进 99.9999%的公司到这一步基本就能解决接入层高可用、扩展性、负载均衡的问题。 这就完美了嘛?还有潜在问题么? 好吧,不管是使用lvs还是f5,这些都是scale up的方案,根本上,lvs/f5还是会有性能上限,假设每秒能处 理10w的请求,一天也只能处理80亿的请求(10w秒吞吐量*8w秒),那万一系统的日PV超过80亿怎么办 呢?(好吧,没几个公司要考虑这个问题) 2 DNS轮询 接入层技术演进 如之前文章所述,水平扩展,才是解决性能问题的根本方案,能够通过加机器扩充性能 的方案才具备最好的扩展性。 facebook,google,baidu的PV是不是超过80亿呢,它们的域名只对应一个ip么,终点又是 起点,还是得通过DNS轮询来进行扩容: 此时: 1)通过DNS轮询来线性扩展入口lvs层的性能 2)通过keepalived来保证高可用 3)通过lvs来扩展多个nginx 4)通过nginx来做负载均衡,业务七层路由 2 MOMODA POWERPOINT 1)接入层架构要考虑的问题域为:高可用、扩展性、反向代理+扩展均衡 2)nginx、keepalived、lvs、f5可以很好的解决高可用、扩展性、反向代理+扩展均衡 的问题 3)水平扩展scale out是解决扩展性问题的根本方案,DNS轮询是不能完全被 nginx/lvs/f5所替代的 THANK YOU

发表评论
加载中...

相关文章