除了「加机器」,其实你的微服务还能这样优化

开发 架构
本文从「AKF扩展立方」说起,介绍了提高服务负载能力的几种服务治理方式。除了X轴扩展(加机器)外,还可以通过Y轴扩展(功能/业务拆分)、Z轴扩展(数据分区)等方式,更优雅、更精细地进行优化。​

​生产实践中,如果遇到业务流量变高导致服务负载升高甚至报警,我们的第一反应往往是「加机器」。

俗话说,能用钱解决的问题都不是问题。

俗话又说,充钱你就能变得更强。

但是,作为一个有理想有抱负的架构师,除了「加机器」,其实你的微服务还能更优雅、更精细地进行优化。

本文预计阅读时间 10分钟,将从以下三个方面展开:

  • 从「AKF扩展立方」说起
  • Y轴扩展的常用模式
  • z轴扩展的思想与应用

1.从「AKF扩展立方」说起

在上一篇文章,我们从「服务维度」学习架构师的常用能力——微服务设计与治理。

围绕着微服务生命周期的七个阶段,总结了常用的16条原则。

其中原则15在微服务服务治理实践中非常重要,本文将重点进行拆解分析。

原则15:参考「AKF扩展立方」模型,服务除了「水平扩容」外,还可以考虑「功能拆分」或者 「数据分区」。

所谓AKF扩展立方体(AKF Scale Cube),是一个描述从单体应用到一个分布式可扩展架构的模型概念。

图片

  • X轴:服务和数据的水平扩容。
  • Y轴:功能/业务拆分
  • Z轴:沿客户边界的服务和数据分区​

「水平扩容」比较容易理解,就是我们常见的操作——加机器。

根据AKF模型,面对服务负载升高的情况,其实除了加机器外,我们还可以考虑「功能拆分」或者 「数据分区」。

2.Y轴扩展的常用模式

「Y轴扩展」相对复杂,我总结了几种模式:

微服务拆分。根据具体业务模型、领域模型拆分更细粒度的微服务。

业务隔离拆分。利用消息队列,将在线业务(OLTP)和耗费大量资源的计算任务拆分隔离。

核心与非核心隔离。对于一个微服务,可以将SKA客户与普通客户进行隔离,SKA客户使用独立的集群资源,提高稳定性。

2.1 微服务拆分

某个微服务负载过高,一个非常常见的原因就是这个微服务承担了过多的职责。这个时候,我们需要根据具体业务模型、领域模型拆分更细粒度的微服务。也是我们常说的「垂直拆分」。

图片

最典型的拆分方法论就是按照领域驱动设计(DDD)进行拆分。

以电商领域为例,按照领域可以拆分为:

  • 用户服务
  • 商品服务
  • 订单服务
  • 评价服务
  • 其他

图片

系统按照领域拆分为多个微服务后,各个微服务由单独的团队负责整个生命周期的维护,单独部署运行。

这种隔离拆分的方式,能带来以下优势:

  • 提高整体系统的负载能力
  • 各个微服务间具备 独立扩缩容、故障隔离 等能力。

2.2 耗时任务隔离拆分

「Y轴扩展」除了按照领域进行服务拆分之外,另外一种非常重要的拆分方式,是将在线业务(OLTP)类型服务中「耗时任务」进行隔离拆分。

我们服务一般会采用Tomcat或者Jetty部署,同时采用同步调用的方式。以Jetty为例,默认线程池最大线程数为200。如果请求中有耗时任务,影响了同步请求的RT,那么线程池满后就会阻塞请求。

正如利特尔法则(Little's law)表述的:在一个稳定的系统(L)中,长期的平均顾客人数,等于长期的有效抵达率(λ),乘以顾客在这个系统中平均的等待时间(W);或者,我们可以用一个代数式来表达:

因此,耗时任务会显著提高服务负载、降低在线业务服务的吞吐能力。

通过引入消息队列或者任务队列框架,我们可以将耗时任务从在线业务服务中进行隔离拆分。

图片

这种隔离拆分的方式,能带来以下优势:

  • 提高在线服务的吞吐能力
  • 避免耗时任务影响在线业务的稳定性。

2.3 核心与非核心隔离拆分

「Y轴扩展」的第三种方式,是将 核心 与 非核心 进行拆分。

比如,我们通常可能会将「核心接口」与「非核心」接口通过一个服务内的不同线程池实现隔离。但是在节点资源(cpu/内存/带宽等)上并不能实现隔离。

因此,我们可以更进一步,通过集群拆分的形式进行隔离。

图片

通过服务路由的配置,将核心接口路由到核心集群(一般节点配置更高),非核心接口路由到非核心集群。

另外,也有saas服务,通常会对SKA客户做独立集群,也是类似的逻辑。

图片

其实按用户拆分隔离跟「数据分区」有一点类似,也可以归类到「z轴扩展」

这种隔离拆分的方式,能带来以下优势:

  • 精细化提高服务吞吐能力(针对核心接口、核心客户)
  • 核心业务独享资源,提高核心业务稳定性
  • 避免非核心接口/用户 影响 核心接口/用户 的稳定性

3.Z轴扩展的思想与应用

Z轴扩展的核心思想,是基于请求者或用户独特的需求,进行系统划分,并使得划分出来的子系统是相互隔离但又是完整的。

生产实践中,常用的z轴扩展有两种应用:

  • 单元化架构
  • 数据分区

3.1 单元化架构

单元化架构主要关注的是应用部署、调用层面的问题。

一个单元,是一个五脏俱全的缩小版全站,它部署了所有微服务。

图片

但它又不是真正的全站,因为每个单元只能操作一部分数据。

从这里我们也能看出,单元化架构要求系统必须具备的一项能力——数据分区。

当然,仅把数据分区了还不够,单元化的另外一个必要条件是,全站所有业务数据分区所用的拆分维度和拆分规则都必须一样。

一般来说,我们绝大多数系统都是面向用户的,按用户维度对数据分区,是一个最佳实践。

当然,如果是全球化部署的单元化架构,还需要考虑按照地域进行分区。

3.2 数据分区

数据分区(shard),即是将全局数据按照某一个维度水平划分开来,每个分区的数据内容互不重叠,这也就是数据库「水平拆分」所做的事情。

前面提到了「数据分区」是「单元化」的必要条件,但是「数据分区」还有其他很多场景应用。

最典型的,就是MySQL单机瓶颈后,需要进行「分库分表」。在服务中需要引入一些支持数据拆分和路由的中间件,如sharding-jdbc、mycat等,在数据层面需要配置相应的分片逻辑。

另外,其他数据库的分区扩展(如redis集群、mongo集群等),也是非常典型的应用场景。

一般包括以下几种数据划分的方式:

  • 数据类型(如:业务类型)
  • 数据范围(如:时间段,用户 ID)
  • 数据热度(如:用户活跃度,商品热度)
  • 按读写分(如:商品描述,商品库存)

4.小结

本文从「AKF扩展立方」说起,介绍了提高服务负载能力的几种服务治理方式。

除了X轴扩展(加机器)外,还可以通过Y轴扩展(功能/业务拆分)、Z轴扩展(数据分区)等方式,更优雅、更精细地进行优化。​

责任编辑:武晓燕 来源: 阿丸笔记
相关推荐

2020-06-19 10:07:36

人工智能人脸识别技术

2020-06-05 18:45:44

Python监视Google

2020-07-27 10:09:02

微服务架构规则

2020-08-24 07:19:13

主键自增数据库

2022-04-11 08:20:36

编程辅助工具GitHubCopilot

2020-11-16 13:38:31

PostMessage

2023-12-01 07:38:33

微服务订单服务

2019-06-18 05:00:52

5G4G网络

2015-05-20 14:01:27

程序程序会做饭

2021-10-29 07:49:22

Spring事务管理

2021-07-28 06:10:47

拖拽设计器 transmat

2021-09-05 07:55:37

前端Emoji 表情

2012-10-11 09:46:20

2016-09-24 22:30:00

2022-12-05 09:08:12

微服务灰度发布

2020-05-08 09:11:50

Eureka微服务调通

2023-12-08 17:24:14

Redis缓存服务器

2012-07-13 11:32:16

网络出口

2018-10-28 18:09:22

微服务Microservic架构

2012-10-12 10:13:26

eclips代码编写Editplus
点赞
收藏

51CTO技术栈公众号