互联网时代,我眼中的架构变迁

标签: 架构 互联网 微服务 | 发表时间:2017-01-05 02:07 | 作者:网易蜂巢
分享到:
出处:https://segmentfault.com/blogs

作者简介:黄庆兵,网易蜂巢首席技术布道师,浙大硕士毕业,从事云计算、Docker、Go等相关开发及技术布道工作;喜欢开源,乐于分享,勤于布道,折腾过开源小工具,制作过Docker课程,分享过 Gopher Meetup。欢迎一起来探讨技术!个人主页: http://bingohuang.com/

以下为正文:

互联网在变,架构也在变,架构的变迁亦是互联网的变迁。所以,我们有必要来聊聊互联网的架构及其变迁。

何为架构?往大的说,宇宙有架构,社会有架构,往小的说,建筑要有架构,软件要有架构,往玄乎的说,它由分工而来,回归整体而去,往实际的说,架构的核心就是为了解决问题,包括业务的问题、人的问题。

立足互联网行业,架构通常指的是技术架构,更具体一点的说是系统架构、软件架构,或者是最常见的网站架构。本文就来探讨一下互联网时代,技术架构的演进过程及其优缺点,其中若有不足之处,还望指正,促进交流。

为了方便表述,我姑且的把互联网的架构演进过程分为三个时代:单机时代、集群时代和分布式时代。三个时代并非按照历史时间顺序排列,更多的是由团队或产品所处的时期来决定。

单机时代

互联网早期,好比杭研某个产品团队初创之时,资源有限,人力不足,为了快速开发一个产品,或上线一个网站,单机往往是一个不错的选择,此时会将应用程序、文件服务、数据库服务等资源集中在一台 Server 上。其中应用程序通常整体打包和部署,具体格式依赖于应用的语言和框架,例如 Java 的 WAR 文件、Rails 的目录文件,此种架构通常称为单体架构。

单体架构

其系统架构图往往长这个样子:

图片描述

图-1: 单机时代-ALL IN ONE

优点:如上文所述,简单快速,易于开发,易于测试,易于部署
缺点:也非常显著,只适合早期项目,变大后不易维护,且存在单点,升级需要停服

分层架构

明眼的人很快发现,此时的应用程序架构显得杂乱无章,这在早期的 Web 开发中可能存在,比如使用 JSP+JDBC,ASP+ADO,但这显然不是一个友好的标准架构,于是分层架构应运而生,分层架构如下图所示,一般分为表现层(presentation)、业务层(business)、持久层(persistence)和数据库(database)。这其实也是最常见的 MVC 架构了。

图片描述

图-2: 单机时代-软件架构-分层架构

改造之后的系统架构图如下:

图片描述

图-3: 单机时代-分层架构

  • 优点:结构简单,分工明确,分层测试,如果你不知道用什么软件架构时,推荐用它

  • 缺点:扩展性差,迭代开发效率低,有时候层次过多导致流程复杂
    数据分离

添加了分层架构,应用上好看点了,团队的开发效率有了一定的提升。此时业务量进一步增大,并且有了一定的用户规模,逐渐发现一台主机上应用和数据资源争夺的非常厉害。因为每种服对硬件资源的要求是不同的,应用服务器需要更快的CPU,文件服务器需要更大的硬盘,数据库服务器需要更大的内存和硬盘,于是决定把应用和数据服务分离,形成了如下架构:

图片描述

图-4: 单机时代-数据分离

  • 优点:资源分散,提高不同服务对硬件的利用率,方便维护

  • 缺点:增加了资源消耗和网络开销,同时还存在单点

缓存登场

产品有了一定的口碑,用户量持续增长,访问开始频繁,想提升访问速度,缓存必不可少,闪亮登场。

图片描述

图-5: 单机时代-缓存登场

服务端缓存又可以分为本地缓存和远程缓存,各有优劣,本地缓存访问速度快,但数据量有限,而且后续集群化不方便共享;远程缓存可以共享,可以集群,容量不受限制,但要注意缓存更新的问题。

  • 优点:简单有效,减少对 DB 的查询

  • 缺点:增加逻辑判断,不适合存储大对象,此架构同样有单点

读写分离

市场反响不错,业务也在持续增长,但性能又有所下降,分析整个架构,发现数据库读写非常频繁,甚至有些业务,读大于写,单台数据库服务器又成了瓶颈,此时就可以尝试做读写分离和主从复制了。

图片描述

图-6: 单机时代-读写分离

  • 优点:降低数据库单台压力,从机的数量可以灵活变更

  • 缺点:架构开始变得复杂,维护难度加大

自此,单机时代的架构已然成型,“麻雀虽小五脏俱全”,初期已经能很好的支撑业务的运转。但随着业务的增长,各个模块还是可能出现瓶颈。而单机时代最大的问题,就是整个架构都存在单点,这个问题将在集群时代一一解决。

集群时代

单机时代,做了不少措施来缓解数据库层的压力,包括服务器分离、引入缓存、数据分离等,但随着访问量的猛增,对高可用的要求越来越高,减轻应用层压力、解决单点问题是当务之急,这就是集群时代需要做的事情。

负载均衡

代码是架构的基础,但前期改造代码的工作量较大,如果人员变动频繁,那风险就更高了,所以提高服务器性能,常用的手段还是先将应用集群化,做负载均衡。

图片描述

图-7: 集群时代-负载均衡

  • 优点:去除应用层单点,可用性得到保证,性能有所提高

  • 缺点:这时要注意应用之间的一致性问题,比如对缓存的访问,对Session的存储

动静分离

希望进一步降低应用服务器的压力,可以采用动静分离技术。

动静分离是让动态网站里的动态网页,根据一定规则把不变的资源和经常变的资源区分开来,动静资源做好了拆分以后,我们还可以根据静态资源的特点将其做缓存操作,以加快响应速度。

在杭研内部,常用做法还会将前后端分离,后端应用提供 API,根据前端的请求进行处理,并将处理结果通过JSON格式返回至前端

图片描述

图-8: 集群时代-动静分离

  • 优点:减轻应用服务器压力,缓存静态文件,加快响应速度,前后端分离,开发可以并行。

  • 缺点:静态文件缓存更新失效问题,前后端沟通成本提高

CDN 加速

内容分发网络(Content Delivery Network),简称 CDN),可以进一步加快网站相应,其原理是将源内容同步到全国各边缘节点,配合精准的调度系统,将用户的请求分配至最适合他的节点,使用户可以以最快的速度取得他所需的内容。

图片描述

图-9: 集群时代-CDN 加速

  • 优点:解决网络带宽小、用户访问量大、网点分布不均等问题,提高用户访问的响应速度,减轻应用负载压力。

  • 缺点:显然成本上去了,CDN服务一般是按流量计费,同时也存在静态文件缓存更新失效问题。

冗余集群

以上一个中型网站架构基本成型。当中型网站继续向大型网站演进,最终的目标是要保证“三高”:高并发、高性能、高可用。以上架构基本可以满足性能需求,接下来更多的是关注“高可用”,确保“无单点”。

此时,就要对关键的服务,做冗余集群负载。

理想情况下,我们将以下服务/应用都集群化:

  • 数据库服务集群

  • 文件服务集群

  • 缓存服务集群

  • 应用服务集群

  • 负载均衡调度器集群

  • 静态内容服务集群

  • CDN服务器集群

图片描述

图-10: 集群时代-冗余集群

  • 优点:去单点,高可用

  • 缺点:数据有状态问题、数据一致性问题,资源成本、人力维护成本都上去了

到此为止,一个大型网站的架构也基本成型了,能“加机器”的地方都加完了,是不是就终结?当然不是!伴随着 DT/分布式 时代的到来,大流量和大数据的场景的出现,对应用提出了更高的要求,接下来就需要对应用程序开刀了。

分布式时代

应用拆分

在前面,我们只是把应用程序做了分层架构,在创业初期或产品前期还是一个不错的选择。虽然应用也做了集群和负载均衡,但应用架构层面还是“集中式”的。随着业务越来越复杂,网站的功能越来越多,应用拆分势在必行了。

  • 优点:应用解耦,分拆团队负责,分而治之

  • 缺点:架构变复杂

应用拆分之后,还伴随着一个相互依赖、公共模块的问题,特别是依赖于相同的逻辑或功能代码。这时就可以考虑将这些共用的服务提取出来,独立部署,统一治理,提高重用度,这就是面向服务的架构(service-oriented architecture,缩写 SOA)了。

消息队列

应用拆分、服务独立部署之后,还是会出现一些通信或依赖问题,这时就可以引入消息队列,提高吞吐量。

  • 优点:异步、解耦,提高吞吐量

  • 缺点:消息消费延迟等问题

数据分库

应用拆分之后,DB分库理所当然,否则多个应用连接在单个数据库上,连接数、QPS、TPS、I/O处理能力都非常有限。

  • 优点:DB分压,降低耦合

  • 缺点:数据访问模块冗余、复杂

提到分库,不少人会想到分表,这一块我并未实践过,不好下笔。但想来会引入更复杂的数据架构和数据一致性问题,而且市面身上成熟开源的分库分表方案并没有,保不准又是一个深坑。拆或不拆,也是一个值得思考的问题。

微服务架构

微服务架构(microservices architecture)一度成为热点,在文章、博客、大会演讲上经常被提及。微服务并不是凭空出现,有人说,它是面向服务的架构(SOA)的升级,在此之前,还有诸如集中式架构、分布式的架构等。这里借用一副抽象的图来描述下常见的几种架构:

图片描述

图-11: 分布式时代-微服务架构-抽象对比

微服务架构由多个微小服务构成,每个服务就是一个独立的可部署单元或组件,它们是分布式的,相互解耦的,通过轻量级远程通信协议(比如REST)来交互,每个服务可以使用不同的数据库,而且是语言无关性的。它的特征是彼此独立、微小、轻量、松耦合,又能方便的组合和重构,犹如《超能陆战队》中的微型机器人,个体简单,但组合起来威力强大。

图片描述

图-12: 分布式时代-微服务架构

  • 优点:扩展性好,服务之间耦合性低,服务间相互独立,容易部署,易于开发,方便测试每一个服务

  • 缺点:容易过度关注服务的大小,可能拆分的很细,导致系统依赖于大量的微服务,而服务之间的相互通信也会变得复杂,系统集成复杂度增加,很难实现原子性操作。

微服务之所以这么火,另一个原因是因为 Docker 的出现,它让微服务有一个非常完美的运行环境,Docker 的独立性和细粒度非常匹配微服务的理念,Docker的优秀性能和丰富的管理工具,让大家对微服务有了一定的信息,概括来说 Docker 有如下四点适合微服务:

  • 独立性:一个容器就是一个完整的执行环境,不依赖外部任何的东西。

  • 细粒度:一台物理机器可以同时运行成百上千个容器。其计算粒度足够的小。

  • 快速创建和销毁:容器可以在秒级进行创建和销毁,非常适合服务的快速构建和重组。

  • 完善的管理工具:数量众多的容器编排管理工具,能够快速的实现服务的组合和调度。

当然,好的架构和技术,要应用于实践、让用户认可才行,这就需要在微服务架构和 Docker 技术之上有丰富的场景化应用。网易蜂巢也在积极探索微服务架构和容器云平台的场景化服务,欢迎一起来实践落地。

至此,架构变迁的三个时代介绍完成。总的来说架构不是一成不变的,时间不停,进步不止,人如此,架构依然。

后记

对我来说,架构之路小有实践,但实属尚浅,想探讨下这个话题,一下不知从何下笔,沉思良久,想到之前读过不少业界前辈对于架构的论述,比如王概凯老师执笔的《架构漫谈》,比如 O'Reilly 免费出版的小册子《Software Architecture Patterns》,比如前人对架构的探索总结,受益匪浅,汇集成文。

相关 [互联网 时代 架构] 推荐:

互联网时代,我眼中的架构变迁

- - SegmentFault 最新的文章
作者简介:黄庆兵,网易蜂巢首席技术布道师,浙大硕士毕业,从事云计算、Docker、Go等相关开发及技术布道工作;喜欢开源,乐于分享,勤于布道,折腾过开源小工具,制作过Docker课程,分享过 Gopher Meetup. 互联网在变,架构也在变,架构的变迁亦是互联网的变迁. 所以,我们有必要来聊聊互联网的架构及其变迁.

互联网时代的应用设计

- james - 所有文章 - UCD大社区
在互联网时代如何开发一个成功的应用. 先发放一万份调查问卷,找几十个人关在黑屋子里花两年时间研发,然后期待着一旦推出就颠覆整个互联网. 我不得不抱歉地说,以这样一种方式研发一款互联网应用,在互联网时代已经不太适用. 互联网应用单纯地从和传统应用的运行环境下的不同所带来的差异就足够决定互联网应用并不是把传统应用简单地搬到网上.

淘宝的可伸缩高性能互联网架构

- 浪客 - 博客园-首页原创精华区
一 应用无状态(淘宝session框架).          假如在session中保存了大量与客户端的状态信息,保存状态信息的server宕机时.          通常通过集群解决,不仅有负载均衡,更重要的是要有失效恢复failover.          tomcat用集群节点广播复制,jboss用配对复制等session状态复制策略,但严重影响系统的伸缩性,不能通过增加更多的机器达到良好的水平伸缩.

一个移动互联网应用地图服务架构

- Ian - 出家如初,成佛有余
    在移动互联网中,各种与位置相关的服务都严重依赖于地图服务,地图服务质量的好坏很大程度决定了所提供服务的高低. 尽管有Google Map等免费或收费的地图服务可供使用,但没有那一家地图服务提供商能够完整提供移动互联网应用所必须的各种地图服务及数据,尤其是针对那些垂直行业应用.     在中国特色的制度下,除了技术因素外,值得注意的是由于地图牌照发放问题带来的政策上的不确定性对架构实现的冲击和挑战.

[转][转]互联网系统架构的演进

- - heiyeluren的blog(黑夜路人的开源世界)
来源: http://www.csdn.net/article/2013-08-27/2816716. 摘要:多终端接入、开放平台给互联网带来了前所未有的用户数量和访问规模,信息之多、传播速度之快,是传统网站难以想象的. 本文将从发展演进的角度,解读高性能互联网系统架构. 多终端接入、开放平台给互联网带来了前所未有的用户量级和访问规模,SNS网站产生了海量的UGC(用户产生内容),而且这些内容依托关 系链扩散速度之快、传播范围之广是传统网站难以想象的,海量数据的计算存储也一直是近年互联网领域的热点.

移动互联网系统架构十大陷阱

- - 五四陈科学院-坚信科学,分享技术
以下内容由 [五四陈科学院]提供. 过去的三年,54chen一直奋斗在中国移动互联网一线,历经各种坑爹的情况. Top 1.时不我待 连通性. cmwap cmnet这样的词语以后应该都会消失在人世间. 三年前,经常性地有移不动联不通手机连不上服务器机房的情况. 相信未来会越来越好,时代在召唤. Top 2.生不逢时 HTML5.

中大型移动互联网公司技术架构选择

- - 五四陈科学院
以下内容由 [五四陈科学院]提供. 总结这些年经验,进行构架演进的方向选择时,大致要做到下面的目标:. 可快速开发部署 (五分钟写出来一个经过测试的hello world并可访问/调用,并可在公网访问). 天然可扩展(业务层无状态,尽可能全部放到最后). 自动化(内存不足了,除了报警,应该自动加点机器进去; 新的项目,基础代码应该都不用写,自动生成即可).

[转]各大互联网公司架构演进之路汇总

- - 鸟窝
原文地址: 各大互联网公司架构演进之路汇总 by HollisChuang. 请转载时务必保留文章的上述原始出处. 支付宝和蚂蚁花呗的技术架构及实践. 支付宝的高可用与容灾架构演进. 聚划算架构演进和系统优化 (视频+PPT). 淘宝交易系统演进之路 (专访). 淘宝技术发展历程和架构经验分享(视频+PPT)(2.3日更新).

移动互联网时代的本质与机会

- 彭全兵 - 互联网的那点事...
在2008年,2009年的系列前文《Web3.0:呼唤虚拟机器人时代的到来》,《心理学与SNS:观察与实践》,从信息与信任的角度,辨析了Web的下一步发展方向,并为互联网界的同仁引入一个社会网络分析的视角. 今天,继续心理学的视角,从物理计算与心智计算的交互角度,探讨移动互联网时代的本质与投资机会,同样,希望为新时代来临而兴奋的各位提供一个计算心理学的视角.

几款移动互联网时代的本地化应用

- WanZheng - 爱范儿 · Beats of Bits
从未想到基于手机的生活方式会变成这样,也没想到手机会变成如此的重要. 变化如此之快,真的难以想象,这就是移动互联网时代的移动生活. 大家都知道移动互联网是一座金矿,而且很多的互联网从业者或者是爱好者已经投入到挖矿过程当中. 在这样的时代背景下不断产生很多有价值的商业模式和很 Cooool 的产品,而且它们在不断融入到我们的生活当中.