微服务架构并不是一种新模式,但最近变得非常流行,主要原因有两个:云计算和容器。这一组合解决了每个基础设施的两个主要问题:成本降低和基础设施管理,从而帮助提高了采用率。
然而,所有这些美丽都隐藏着一个黑暗的事实:
微服务最难的部分是数据层
当涉及到像MySQL这样的经典关系数据库时,尤其如此。让我们找出原因。
MySQL和微服务
遵循微服务的两大支柱(云计算和容器),在MySQL范围内可以做什么?云计算和容器为数据表带来了什么?
云计算
云的神奇之处在于,它可以让您轻松地向上/向下扩展实例的大小,从而让您具有成本意识。不再浪费资金在大部分时间未充分利用的大型服务器上。有什么问题吗?它必须很快。快速扩展以准备处理流量,快速缩减以在流量较低时降低成本。
容器
容器的神奇之处在于可以根据资源需求分割硬件。这里的问题是容器传统上用于无状态应用程序。一次性容器。 一般来说,关系数据库,尤其是MySQL,扩展速度不快,而且是有状态的。然而,它可以适应云,并用于微服务的数据层。
缩放立方体
Abott和Fisher的《可伸缩性的艺术》一书描述了一个非常有用的三维可伸缩性模型:Scale Cube。在此模型中,通过在负载平衡器后面运行克隆来扩展应用程序称为X轴扩展。其他两种缩放是Y轴缩放和Z轴缩放。微服务体系结构是Y轴伸缩的应用程序:它定义了一个体系结构,将应用程序构造为一组松散耦合的协作服务。
- X轴:服务和数据的水平复制和克隆(READ REPLICAS)
- Y轴:功能分解和分割– 多租户
- Z轴:沿客户边界的服务和数据分区–(分片)
在微服务上,每个服务都有自己的数据库,以便与其他服务解耦。换句话说:服务的事务只涉及其数据库;数据是私有的,只能通过微服务API访问。
很自然,第一种划分数据的方法是使用多租户模式:
实际上,在尝试多租户之前,可以使用每个服务都有一个表的模型,其中每个服务都拥有一组只能由该服务访问的表,但是因为是“软”划分,跳过API直接访问其他服务的表的诱惑是巨大的。
可以采用每个服务对应一个数据库模式(Schema per service),其中每个服务都有一个专用于该服务的数据库模式,这很有吸引力,因为它使所有权更加清晰。很容易为每个数据库创建一个用户,并使用特定的授权来限制数据库访问。
然而,这种“共享数据库”模式也有一些缺点,如:
- 单一硬件:数据库故障会损害所有微服务
- 与特定数据库相关的资源密集型任务将影响其他数据库(考虑DDL)
- 共享资源:需要共享磁盘延迟、IOPS和带宽,以及CPU、网络带宽等其他资源。
另一种选择是“每个服务的对应一个数据库”
这种策略不共享任何内容。更清晰的逻辑分隔。孤立问题。服务是松散耦合的。事实上,这为微服务打开了大门,使其能够使用最适合其需要的数据库,如图形数据库、面向文档的数据库等。 但与所有事情一样,这也有缺点:
- 最明显的是:成本。要部署的更多实例
- 最关键的:分布式事务。正如我们前面提到的,微服务之间是协作的,这意味着事务跨越多个服务。
最简单的方法是使用两阶段提交实现。但这种解决方案只是对大量锁定问题的公开邀请。它完全无法扩展。那么,有哪些替代方案呢?
- 实现跨服务的事务:Saga模式
- 实现跨服务的查询:API组合或命令查询职责分离(CQRS)
saga是一系列本地交易。每个本地事务都会更新数据库,并发布触发saga中下一个本地事务的消息或事件。如果本地交易因任何原因失败,那么该saga将执行一系列补偿交易,撤销之前交易所做的更改。此处是更多Saga 相关信息。
API组合只是一个组合器,它调用每个微服务上的查询,然后执行结果的内存连接:microservices.io/patterns/da…
CQRS保留一个或多个包含来自多个服务的数据的物化视图。这样就无需对查询大小进行连接:microservices.io/patterns/da…
所有这些备选方案有什么共同点?都是API级别考虑解决方案:实现和维护它成为开发人员的责任。数据层保留的仍然是数据,而不是信息。
让它成为云
有一些方法可以让你的MySQL成为云原生的:容易快速地进行缩放;在容器中运行,许多容器;用Kubernetes编排;拥有Kubernetes的所有优点(健康检查等)。
基于Percona XtraDB集群的 MySQL Percona操作符
Kubernetes操作符是一种特殊类型的控制器,用于简化复杂的部署。运营商提供完整的应用程序生命周期自动化,并利用上面的Kubernetes原语来构建和管理应用程序。