前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >互联网架构究竟如何演进?

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

作者头像
孙玄@奈学教育
发布2018-07-03 17:11:46
1.5K0
发布2018-07-03 17:11:46
举报
文章被收录于专栏:架构之美

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

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

单体架构(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集团技术委员会主席,百度高级工程师,毕业于浙江大学。“架构之美”公众号作者。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2017-11-10,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 架构之美 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
服务网格
服务网格(Tencent Cloud Mesh, TCM),一致、可靠、透明的云原生应用通信网络管控基础平台。全面兼容 Istio,集成腾讯云基础设施,提供全托管服务化的支撑能力保障网格生命周期管理。IaaS 组网与监控组件开箱即用,跨集群、异构应用一致发现管理加速云原生迁移。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档