正式定档!QCon 北京站改期为2024年4月11-13日,地点:北京·国测国际会议会展中心 >>> 了解详情
写点什么

孙玄谈:微服务架构何去何从?

  • 2020-04-21
  • 本文字数:4237 字

    阅读完需:约 14 分钟

孙玄谈:微服务架构何去何从?

分布式技术的发展,深刻地改变了我们编程的模式和思考软件的模式。2019 岁末,PingCAP 联合 InfoQ 共同策划出品“分布式系统前沿技术 ”专题, 一起探索这个古老领域的新生机。


微服务架构模式经过 5 年多的发展,在各行各业如火如荼地应用和实践。如何在企业中优雅地设计微服务架构?是企业面对的一个重要问题。本文将讲述微服务架构 1.0 设计与实践以及面临问题和破局,最后讲述微服务架构 2.0 设计与实践等方面,尝试去回答这个难题。

微服务架构 1.0 设计与实践

1.1 微服务架构定义

2014 年马丁福勒提出了微服务架构设计模式,微服务架构最核心的设计有二点(如图 1 绿框所示):第一,把单体服务拆分成一系列小服务;第二,拆分后的这些小服务是去中心化的,即每个服务都可以使用不同的编程语言,也可以使用不同的数据库和缓存存储数据[1]。



图 1 微服务架构模式

1.2 微服务架构拆分设计实践

第一个问题是服务如何拆分的问题。架构拆分没有新鲜事,即不同领域的架构设计在道(哲学)的层面都是相通的。


我们来思考一下公司数据库集群遇到读写和存储的性能问题时,是如何解决的?假如公司电商业务包含用户、商品以及交易等数据,每种数据使用一张单独的表存储,这些数据放在一个数据库(DB4Global)中。随着请求量的增加和数据存储量的增加,单独的 DB4Global 数据库会遇到性能瓶颈。为了解决数据库的性能问题,需要对 DB4Global 库拆分,首先对 DB4Global 库按照业务领域进行垂直拆分,拆分为多个独立的用户库(DB4User)、商品库(DB4Info)、交易库(DB4Trade)等;其次为了进一步提升数据库的性能,再次根据功能对每个表进行水平方向的拆分,例如用户表 10 亿记录,主键为用户 UID。Partition Key 选择为 UID,按照 UID % 128 水平拆分。


架构设计之道是相通的,微服务拆分同样遵循业务领域的垂直拆分以及功能的水平拆分。继续以电商业务为例,首先按照业务领域的垂直拆分,分为用户微服务、商品微服务、搜索微服务、推荐微服务、交易微服务等等。


继续思考一个问题,在垂直方向仅仅按照业务领域进行拆分是否满足所有的业务场景?答案是否定的。例如用户服务分为用户注册(写请求)和用户登陆(读请求)等。写请求的重要性往往是大于读请求,在互联网大流量下,读写比例 10:1,甚至更高的情况下,大量的读往往会直接影响写。为了避免大量的读对写请求的干扰,需要对服务进行读写分离,即用户注册为一个微服务,用户登陆为一个微服务。此时按照 API 的细粒度继续进行垂直方向的拆分。


在水平方向,按照请求的功能拆分,即对一个请求的生命周期继续进行拆分。请求从用户端发出,首先接受到请求的是网关服务,网关服务对请求进行请求鉴权、通用参数检查、协议转换以及路由转发等。接下来业务逻辑服务对请求进行业务逻辑的编排处理(比如微信发送消息,需要进行好友关系检查、对消息内容进行风控检查、进行消息的存储和推送等)。对业务数据进行存储和查询就需要数据访问服务,数据访问服务提供了基本的 CRUD 原子操作,并负责海量数据的 Sharding(分库分表)以及屏蔽底层存储的差异性等功能。最后是数据持久化和缓存服务,比如可以采用 NewSQL TiDB 以及 Redis Cluster 等。


通过以上的拆分,普适的微服务架构如图 2 所示。



图 2 普适的微服务架构


微服务架构通过业务垂直拆分以及水平的功能拆分,服务演化成更小的颗粒度,各服务之间相互解耦,每个服务都可以快速迭代和持续交付,从而在公司层面能够达到降本增效的终极目标。但是服务粒度越细,服务之间的交互就会越来越多,更多的交互会使得服务之间的治理更复杂。服务之间的治理包括服务间的注册、通信、路由、负载均衡、重试、限流、降级、熔断、链路跟踪等。


微服务架构技术选型,包括微服务本身的研发框架以及服务治理框架。目前研发框架主流的 RPC 有两类:一种是 RPC Over TCP,典型代表是 Apache Dubbo;另外一种是 RPC Over HTTP,典型代表是 Spring Cloud。企业根据团队的研发基因二者选一即可。在服务治理方面包含了服务注册、服务配置、服务熔断、服务监控等方面,服务注册本质是 AP 的模型,可以选用 Nacos,服务配置可以选用 CTrip Apollo,服务熔断可以选用 Netflix Hystrix 组件,服务监控可以选用 Open-Falcon 等配套框架。

1.3 微服务架构 1.0 面临问题以及破局

在微服务架构 1.0 中每个服务包含了服务自身的功能设计以及服务治理的功能设计,他们耦合在一起,这些服务治理的功能和服务自身功能没有关系,业务方也不需要关注。使得微服务 1.0 架构不再是银弹,存在以下几个方面的问题:


第一,每一个业务服务为了和其他业务服务交互,都必须关注和引入服务间服务治理组件,使得业务服务迭代速度变慢,如图 3 所示。



图 3 业务服务迭代速度慢


第二,服务治理组件和服务自身功能耦合在一个进程内,使得服务治理组件的升级强依赖于业务服务自身,造成基础设施研发团队的交付能力和交付速度大大降低。如图 4 所示,服务降级功能从 V1 升级到 V2,需要业务服务更换服务降级功能的组件,重新打包编译和发布。



图 4 服务治理组件升级困难


第三,如[1]所示,马丁福勒对微服务架构的期望是每个服务都可以使用业务团队熟悉的语言来编写,但是在服务自身和服务治理耦合在一起的情况下,每个语言都需要一套完整的服务治理组件,必然造成公司研发投入成本增大,ROI 不高。如图 5 所示,Java 语言编写的应用程序 A 和应用程序 C 交互,就需要一套完整的 Java 语言服务治理组件,同样,世界上最好语言编写的应用程序 B 和应用程序 C 交互,就需要一套完成的 PHP 语言服务治理组件。



图 5 多套服务治理组件


那么造成这些问题的本质原因在于服务自身功能和服务治理功能的物理耦合,把服务治理功能完全解耦出来,变成一个独立的服务治理进程,从而以上三个问题得以彻底解决。

微服务架构 2.0 设计与实践

2.1 Serive Mesh 定义

微服务架构 1.0 继续演进,就变成了微服务架构 2.0,即 Service Mesh 架构(Service Mesh)。Servie Mesh 架构最早由开发 Linkerd 的 Buoyant 公司提出,并在内部使用。2016 年 09 月 29 日第一次公开使用,2017 年初进入国内技术社区视野。Service Mesh 到底是什么?我们来看看 Linerd 公司 CEO Willian Morgan 对 Service Mesh 的定义如图 6 所示:



图 6 Service Mesh 定义


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

2.2 微服务架构 2.0 破局


图 7 Service Mesh 架构


如图 7 所示,应用程序 A 和应用程序 B 交互,请求调用关系如下:应用程序 A 调用本地的 Sidecar A,Sidecar A 在通过网络交互调用远端的 Sidecar B,再由 Sidecar B 把请求传递给应用程序 B。请求回应关系也是类似:应用程序 B 调用 Sidecar B,Sidecar B 在通过网络交互调用远端的 Sidecar A,再由 Sidecar A 把请求回应传递给应用程序 A。通过把服务治理功能从服务自身中物理剥离出来,下沉形成独立的进程,从而物理解耦。


在这样的架构模式下,业务应用程序再也不需要关注服务治理的功能,服务治理的功能升级也不要依赖于服务自身,从而能够让业务迭代更快速和高效。同时由于服务治理功能变成一个独立的进程,只需要使用一种语言打造即可,业务服务自身可以选择业务团队擅长的语言进行编写,从而能够真正达到马丁福勒对微服务的期望。


我们再深入分析下协议,在通信协议方面,业务应用程序和 Sidecar 的通信可以基于 TCP 长连接,也可以基于 HTTP 1.0 或者 2.0 的长连接(思考下:是否一定要使用长连接?),Sidecar 间的通信协议没有特殊要求;在数据传输协议方面,可以是 JSON/XML 等跨语言的文本协议,也可以选择 Protobuffers/MessagePack 等跨语言的二进制协议。


保证了通信协议和数据传输协议的跨语言,不同语言的应用程序就可以无缝地和 Sidecar 进行交互。在应用程序和对应的 Sidecar 部署层面,需要部署在同机(可以是同一台物理机/虚拟机,也可以是同一个 Pod),思考下,如果部署在不同的机器上,就会又引入服务通信交互的问题,那么就会变成无解的难题:为了解决通信交互的问题,又引入新的通信交互的问题。

2.3 微服务架构 2.0 实践

按照新的微服务架构 2.0 打造,微服务架构 1.0 的升级演变如图 8 所示:



图 8 微服务架构 2.0


Service Mesh 架构框架方面,业内陆续开源了不少的优秀框架,Istio 是集大成者,由 Google、IBM、Lyft 等三家公司联合打造,并已经开源,社区版本也已经发展到 V1.4.2。IstioService Mesh 逻辑上分为数据面板(执行者)和控制面板(指挥者),数据面板由一组智能代理(Envoy)组成,代理部署为 Sidecar,调解和控制微服务之间所有的网络通信。控制面板负责管理和配置代理来路由流量,以及在运行时执行策略。如图 9 所示,控制面板(Pilot、Mixer、Citadel)加数据面板(Envoy Proxy)即是服务治理功能,svcA 和 svcB 是业务服务自身。



图 9 Istio 架构

未来展望

与纯粹的微服务架构相比,Service Mesh 又向前迈了一步。它最大的优势是解耦应用业务,企业能够彻底从业务角度考虑问题,同时还可以与容器编排部署平台的集成,成为企业级应用编排部署和服务治理的标准形态。


但是企业想要全面切换到 Service Mesh 并不是一件易事,还有一段路需要走。以 Istio 为例,如果要切换,会面临以下问题:


  • 老服务切换到 Istio 的过程中,由于历史服务使用的框架不同,如何保证老服务的平稳迁移以及新老服务如何无缝交互,是企业面临的第一个难题;

  • 切换到 Istio 后,由于通信链路会变长,必将增加请求的响应延迟,对请求响应延迟极其敏感的业务场景,比如量化交易等场景,增加的请求相应延迟对业务来说是致命的,如何

  • 进一步优化处理;

  • Istio 的 Mixer 功能存在单点瓶颈问题,那么对高并发的业务场景如何突破,是公司需要考虑和解决的问题;

  • 切换到 Istio,将会增加基础设施团队的运维成本,并且遇到业务问题,定位问题涉及到业务研发团队和基础设施研发团队频繁沟通交互,自然成本也会相应增加。

  • Istio 的 Mixer 功能存在单点瓶颈问题,那么对高并发的业务场景如何突破,是公司需要考虑和解决的问题;

  • 切换到 Istio,将会增加基础设施团队的运维成本,并且遇到业务问题,定位问题涉及到业务研发团队和基础设施研发团队频繁沟通交互,自然成本也会相应增加。


本文转载自技术琐话公众号。


原文链接:https://mp.weixin.qq.com/s/_F3PnV3uHoOHiX7sqdpPvA


2020-04-21 17:38649

评论

发布
暂无评论
发现更多内容

世界500强开滦集团的财务共享建设路径

用友BIP

财务共享

复杂Flink任务Task均衡调度和优化措施

Openlab_cosmoplat

大数据

大型 3D 互动开发和优化实践 | 京东云技术团队

京东科技开发者

游戏 3D 企业号 6 月 PK 榜 互动游戏

玩转服务器之应用篇:从零开始构建小型高可用环境

京东科技开发者

高可用 云主机 云服务器 企业号 6 月 PK 榜

魔法门之英雄无敌3下载,死亡阴影 for Mac中文版

魔仙苹果mac堡

mac游戏 英雄无敌3 英雄无敌3高清中文版 魔法门之英雄无敌3下载 死亡阴影中文版

【5.26-6.02】写作社区优秀技术博文一览

InfoQ写作社区官方

热门活动 优质创作周报

TiDB集群数据库灾难恢复手册

TiDB 社区干货传送门

管理与运维 备份 & 恢复

TiDB数据迁移实践DM工具

TiDB 社区干货传送门

迁移 实践案例

我又和redis超时杠上了

蓝胖子的编程梦

redis 性能分析 云服务器 线上事故 接口超时

客服都要下岗了? 当ChatGPT遇见私有数据,秒变AI智能客服!

WorkPlus

TiDB 落地SAS机器实践

TiDB 社区干货传送门

实践案例 应用适配 HTAP 场景实践

含有CPU芯片的PCB设计需要考虑的五个主要方面

华秋电子

这本数智平台白皮书讲透了大型企业数智化升级业务痛点

用友BIP

白皮书 数智底座 数智平台 平台白皮书 数智化转型白皮书

数据隐私为先:EMQX Cloud BYOC 架构解析

EMQ映云科技

物联网 云服务 mqtt

亿级大表毫秒关联,荔枝微课基于腾讯云数据仓库Doris的统一实时数仓建设实践

科技热闻

rocketmq4 docker安装 阿里云linux2(centos7)

folo

Docker centos RocketMQ部署

简洁实用的文本编辑器:FSNotes中文版

真大的脸盆

Mac Mac 软件 文本编辑器 文本管理 文本处理工具

行云堡垒V7亮点有哪些?具体看这里!

行云管家

IT运维 行云堡垒

一文读懂责任分配矩阵,解决你80%的项目难题

敏捷开发

项目管理 Scrum 敏捷开发 责任分配矩阵 RACI矩阵

一次网络请求中的流量分发过程 | 京东云技术团队

京东科技开发者

数据传输 企业号 6 月 PK 榜 流量分发 网络请求

实现mac电脑与安卓互通|MacDroid 破解版

魔仙苹果mac堡

MacDroid for mac 安卓设备文件传输助手 MacDroid中文 MacDroid破解 mac与安卓同步

让AI无处不在!Intel拿出全新VPU:超高能效碾压GPU

E科讯

强化学习基础篇[2]:SARSA、Q-learning算法简介、应用举例、优缺点

汀丶人工智能

人工智能 深度学习 强化学习

人工智能工程总体介绍

紫晖

人工智能 软件工程 数据开发

堡垒机重要吗?为什么?求解!

行云管家

堡垒机 安全运维 录像审计

手把手实践丨基于STM32+华为云设计的智慧烟感系统

华为云开发者联盟

云计算 华为云 华为云开发者联盟 企业号 6 月 PK 榜

BFF层聚合查询服务异步改造及治理实践 | 京东云技术团队

京东科技开发者

优化技巧 企业号 6 月 PK 榜 BFF层 异步优化

重新思考流处理与流数据库

吴英骏

开源 云原生 流处理 ​Rust 实时数据库

强化学习基础篇【1】:基础知识点、马尔科夫决策过程、蒙特卡洛策略梯度定理、REINFORCE 算法

汀丶人工智能

人工智能 深度学习 强化学习

单点登录的三种实现方式

Authing

SSO 单点登录

圣邦股份:品类持续深挖,高端加速推进,模拟龙头稳健发展

华秋电子

孙玄谈:微服务架构何去何从?_文化 & 方法_技术琐话_InfoQ精选文章