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

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

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

单体架构(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 条评论
登录 后参与评论

相关文章

来自专栏华章科技

如何打造高性能大数据分析平台

译者:袁璞,圣特尔•E店宝大数据架构师,关注高性能或可用架构、大数据技术、机器学习。

501
来自专栏林德熙的博客

硬件分配

以前做的是把一个软件分配到硬件,只需要让用背包问题最大化硬件的使用,但是没有让所有资源最大化。

1171
来自专栏DevOps时代的专栏

华为专家 | 轻量化微服务测试实践

前言 在我过去工作的这十年间,IT行业经历了很多的变迁,从单体架构到微服务架构,从传统组织到敏捷组织,我正好都有不同的体验,现在我在华为任软件架构师,华为有各种...

73510
来自专栏我就是马云飞

该如何接手别人遗留下的代码?

在我们开始之前,你应该先了解一些事项。首先,请阅读这篇 Joel Spolsky 的著名文章,了解为什么永远不应该重写代码(https://www.joelon...

1003
来自专栏java一日一条

软件开发中最顶级的 17 个平台和工具

当你在决定使用哪些软件或平台来完成日常工作时,会存在很多选择。所以,我决定写一个我们在开发部门常用的软件开发工具列表,希望能对其他所有人都有所帮助。

1683
来自专栏互联网研发闲思录

个性化推荐系统(七)--- ABTest ab测试平台

       个性化推荐系统、搜索引擎、广告系统,这些系统都需要在线上不断上线,不断优化,优化之后怎么确定是好是坏。这时就需要ABTest来确定,最近想的办法、...

9978
来自专栏喔家ArchiSelf

从应用架构看大数据

如果每个人的心中都有一把青冥剑,那么每个人的眼中有自己大数据。这是一个所谓大数据的年代,但是从应用架构的层面看,大数据应用一般都是数据密集型的应用,可以从分层的...

1063
来自专栏重庆的技术分享区

微服务 - 从想法到迈出第一步

原文地址:https://codeburst.io/microservices-from-idea-to-starting-line-d6e8cd5e9bb4?...

1391
来自专栏ThoughtWorks

Gitflow有害论 | TW洞见

今日洞见 文章作者来自ThoughtWorks:刘尚奇。 本文所有内容,包括文字、图片和音视频资料,版权均属ThoughtWorks公司所有,任何媒体、网站或个...

4369
来自专栏EAWorld

普元微服务平台EOS Platform 8全新发布

普元新一代应用平台EOS Platform 8已经全面拥抱微服务架构,支持分布式架构,为企业业务上云提供云原生应用的支撑。同时该版本完全支持Spring Boo...

2382

扫码关注云+社区