互联网架构究竟如何演进?

自身“捣鼓”架构多年,也时常与人交流架构的魅力。今天就互联网架构演进聊聊我的看法。

在我看来,互联网架构经历了单体架构、水平分层架构、面向服务架构、微服务架构以及服务网格架构等几个不同阶段,每个架构有什么特点?这些架构间有什么不同?为什么要演进?让我们一探究竟!

单体架构(Monoliths Architecture)

单体架构是指业务功能的实现全部在一个进程(process)内完成。二手交易平台标配的商品推荐功能,单体架构接受APP客户端发送的请求、从数据库获取推荐商品、对推荐的商品列表过滤/排序等业务处理全部在一个进程里完成,如图1所示,最终打包成一个WAR包,放入tomcat等web容器里运行。

图1 单体架构

单体架构的优点第一请求响应延迟低,接收客户端请求,经过一次网络交互从数据库批量获取数据,其余的功能全部在进程内完成,避免了多次网络交互。第二仅一个进程,部署和运维成本小。

那么单体架构适用于哪些场景?第一创业初期,人手紧张,又需要快速完成业务需求。第二是对性能要求极其苛刻场景,哪怕请求慢1ms都无法接受(比如在金融行业,量化交易场景,响应时间就是生命线)。

单体架构的缺点也非常明显,业务功能单元间耦合严重、扩展性差、技术选型单一(在一个进程内是否可以采用多种开发语言?)等。

单体架构最大的问题是架构粒度过粗,导致系统迭代速度快不起来。互联网业务又是持续高速发展的业务,采用单体架构很难满足需求,系统架构如何演进?单体架构需要按照某些维度进行拆分:按照系统水平方向进行拆分(水平分层架构)、按照业务功能垂直拆分(SOA架构)、既按照业务功能垂直拆分又按照系统水平方向进行拆分(微服务架构)。

水平分层架构(Horizontal layered Architecture)

对单体架构在水平方向进行拆分,就会演变成水平分层架构,水平分层架构解决了单体架构存在的高耦合、低扩展性的问题,如图2:

图2 水平分层架构

水平分层架构分为网关层、业务逻辑层、数据访问层以及DB/Cache。每一层都是独立的进程,每个进程职责分明。其中网关层接收客户端请求,对请求合法性校验以及鉴权、对请求根据URI路由转发到相应的业务逻辑层;业务逻辑层负责请求具体的业务逻辑处理,在微信端发送消息给好友,业务逻辑层会对发送消息进行黄反等策略检查、会校验发送者的权限(你遇到过“消息已发送,被对方拒收”的情况吗?)、判断接收方是否在线等等。业务逻辑层不会直接和数据库交互,它需要的数据通过数据访问层获取。数据访问层有三部分功能构成:第一是ORM,接收业务逻辑层发送的数据协议(JSON等文本协议或者PB等二进制协议)转换成SQL协议;第二是Sharding,数据库存储数据超过千万级别时,为了进一步提升性能,会按照业务功能垂直拆分库以及水平方向拆分表。因此在此层提供分库分表支持,对业务逻辑层透明,使之无感知。第三是随着业务请求量继续增大,Sharding后依然无法满足性能需求,进一步增加Cache功能,对业务逻辑层透明。存储层往往使用MySQL提供关系存储,使用Redis提供缓存。

大家熟知的MVC架构,本质上是水平分层架构,分为Model层、View层、Control层。水平分层架构分层不易过多,每增加一层,请求响应延迟相应会增加;分层越多,定位线上问题难度越大。根据业务使用场景的不同,常常对水平分层架构分为三层(MVC)、四层(图2)、五层(图3)。

图3 异步化水平分层架构

图3和图2相比,增加MQ层(消息队列层),APP端更新请求经过网关层后持久化到MQ层,返回给APP端。业务逻辑层从MQ层读取更新请求消费。在架构上,通过MQ层把更新请求的处理进行了异步化。图3即变成了异步化水平分层架构。采用异步化水平分层架构,提升了系统整体吞吐量。在社区等高并发业务场景适合异步化架构。异步化架构会带来数据处理的延迟情况,因此对数据一致性要求苛刻的业务场景,比如金融、支付等,异步化架构不适合,这些场景常使用图2同步水平分层架构。

水平分层架构解决了单体架构的问题,它存在明显问题是每层粒度过粗,在每一层并没有按照业务功能单元进一步垂直拆分。

面向服务化架构(SOA Architecture)

单体架构按照业务功能在垂直方向进行拆分,就变成了SOA架构,如图4:

图4 SOA架构

图4按照业务功能单元进行拆分,分为了交互服务、信息服务等,每一个服务都是单体,单体服务之间通过企业服务总线(ESB)进行交互。可知SOA架构仅进行了垂直方向拆分,对每个服务并没有按照水平方向进一步拆分,因此SOA架构拆分也不彻底。

微服务架构(MicroServices Architecture)

服务架构的出现,解决了水平分层架构以及SOA架构拆分不彻底的问题。微服务架构是Martin Fowler 在2014年提出的架构模式(如图5),微服务架构有如下特点:按照业务领域拆分服务、一系列小服务构成、服务独立部署、独立运行、服务间去中心化管理(任何一个服务都可以采用任何开发语言 C/PHP/Go/Java等,也可以运行于任何的平台Linux/Windows等,理想是丰满的,现实呢?)。微服务首先按照业务领域模型垂直拆分,即根据不同的业务功能单元进行垂直拆分。对垂直拆分后的服务,在水平方向继续进行拆分。

图5 微服务定义

二手交易平台转转,包括了用户功能、商品功能、交易功能、搜索功能以及推荐功能。各个业务单元相对独立,首先按照业务垂直拆分成用户、商品、交易、搜索、推荐微服务。对每一个功能单元(商品等),继续进行水平拆分,分为商品网关层、商品业务逻辑层、商品数据访问层、商品DB/Cache,对用户、交易、搜索、推荐等业务同样方式进行水平拆分,最终微服务架构如图6:

图6 微服务架构

那么典型的微服务架构由哪些元素组成?如图6,包括网关、微服务业务逻辑层(聚合层)、数据访问层(原子层)、数据存储、注册中心、配置中心。网关负责请求接入,聚合层用于各种业务逻辑的处理,数据原子层用做数据访问代理,提供ORM、数据Sharding以及屏蔽底层存储的差异性等功能。

因此,第一从业务角度看,微服务架构本质上一个业务架构,对业务了解越深刻,微服务拆分越合理;第二从系统角度看,微服务架构是水平分层架构和SOA架构的结合体。

采用微服务架构后,一方面请求链条变长,对请求响应要求苛刻的场景不适合微服务架构;另一方面服务变多,实施数据一致性的难度变大,对数据要求强一致性的场合也不适合使用微服务架构。

采用微服务架构后,项目能够做到快速迭代,持续交付。微服务架构也存在明显的弊端:开发人员除了关注业务逻辑的实现外,还需要在微服务模块里处理一系列问题,比如服务注册、服务发现、服务通讯、负载均衡、服务熔断、请求超时重试等,这是非常糟糕的。业务开发团队的强项在于业务理解,而不是技术。能否让业务开发人员仅关注业务开发,服务间通讯以及请求管理功能不再关心?服务网格架构解决了这个问题,让业务开发人员真正解脱。

服务网格架构(Service Mesh Architecture)

服务网格由Buoyant公司提出,2017年初Buoyant公司CEO William Morgan给出服务网格的定义如下 (图7):

图7 服务网格定义

服务网格是一个基础设施层,用于处理服务间通信。对于有着复杂拓扑结构的云原生服务,服务网格负责实现这些服务间请求的可靠传递。在实践中,服务网格通常实现为一组轻量级网络代理,它们与应用程序部署在一起,并对应用程序透明。

我们来看个简单的例子,如图8:

图8 简单服务网格例子

一个应用请求首先发送给远程的服务网格实例,服务网格完成服务发现、服务通讯、负载均衡等完整调用流程,最后将请求发送给目标服务。

继续看一个复杂的例子,如图9:

图9 复杂服务网格例子

图9左边绿色方格表示服务,右边蓝色的方格表示服务网格,蓝色之间的线表示服务间的调用关系。服务网格连接就形成了一个网络,这就是服务网格名字的由来。

因此服务网格是一个基础设施层,独立于服务之外,对服务透明,实现了请求的可靠传递。有了服务网格,业务开发人员再也不用关注服务发现、负载均衡、服务重试、熔断等,可以专注在业务开发上。

开源的服务网格产品陆续Release出来:来自buoyant公司的Linkerd、来自Lyft公司的Envoy、来自nginx的nginmesh以及来自Google/IBM/Lyft公司的Istio等。最值得关注的当数Isto,出身名门,王者风范,期待Istio像k8s一样成为现象级的重量产品。

服务网格这个词仅出现一年的时间,服务网格产品实施落地还需要一些时间,期待后续继续完善,使业务开发同学能够真正回归业务开发本身。

互联网架构究竟如何继续演进,且行且期待。

We Are Hiring Now.

转转公司基础架构部、大数据部(Hadoop生态构建)、搜索推荐技术部招聘工程师,只要能力强,薪资上不封顶,简历砸过来吧:sunxuan@zhuanzhuan.com

个人简介

孙玄 转转公司基础架构负责人,前58集团技术委员会主席,百度高级工程师,毕业于浙江大学。“架构之美”公众号作者。

原文发布于微信公众号 - 架构之美(beautyArch)

原文发表时间:2017-11-10

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏SEO

Googleblog更新:针对网页速度给出3个官方工具进行评估页面性能

用户都是希望能够尽快找到自己问题的答案。研究表明,用户都比较关心页面的速度。虽然速度已经在排名中使用了一段时间,但该信号主要集中在PC端搜索上。谷歌官方宣布从2...

912
来自专栏云计算D1net

混合云/多云环境如何部署微服务

微服务能够为混合云或多云部署带来大量的好处,但是它们也能够带来与网络、安全性等相关的新挑战。 ? 大多数IT企业已经开始认识到在开发和部署中实施软件组件化的好处...

3269
来自专栏IT米粉

技术知识和稳定的系统之间,可能还差这些?

艺术的展现除了术,还需要道。程序的术是大家都能得到的共识,各种各样提升自己技术的文章到处都是,这里我们说说程序的道,也就是方法。这也是大家经常忽略或者不重视的地...

4168
来自专栏web前端教室

大前端?/前端开发职位的未来方向/

对于许多新人来说,他们最开始接触前端这行,都是从前端开发工资高啊,好找工作啊,入门门槛低,这些方面开始了解的。当他们开始学习前端一段时间之后,许多人不可避免的开...

762
来自专栏LiveEdu在线科技教育平台

工作流程,编程,调试,性能:Unity游戏开发者应该学习的20个改进技巧

Unity 是一个备受欢迎的游戏开发平台。它的功能令人印象深刻,同时也迎合了不同的游戏开发需求。游戏开发者可以使用 Unity 创建任何类型的游戏,从世界级的 ...

3289
来自专栏腾讯移动品质中心TMQ的专栏

腾讯TMQ沙龙|移动互联网APP应用的服务端测试方案和实践

移动互联网APP应用的服务端测试方案和实践 活动时间:2016年9月8日 QQ群视频交流 活动介绍:TMQ在线沙龙第八期分享 本次分享的主题是介绍移动互联网AP...

1875
来自专栏BestSDK

未来APP产品开发的方向

未来的移动App开发不仅仅是让它适应一方小小的屏幕,采用不同的编程语言,基于不同的操作系统。那它是怎样的呢?现在我想我们应该把注意力转向建立现代化的App了。 ...

2497
来自专栏Rainbond开源「容器云平台」

干货下载:谷歌、亚马逊等十大公司微服务案例精选

1634
来自专栏钱塘大数据

干货丨10款非常实用的网站数据实时分析工具

1. Google Analytics 这是一个使用最广泛的访问统计分析工具,几周前,Google Analytics 推出了一项新功能,可以提供实时报告。你可...

3437
来自专栏HTML5学堂

了解页面重构吗?

了解页面重构吗? 正文 HTML5学堂:在HTML5的职业发展当中,存在着一种职位叫做“页面重构师”,这种职位到底是什么?又和我们的HTML5开发工程师、WEB...

35015

扫码关注云+社区