赞
踩
在当今数字化时代,企业需要面对不断变化的市场需求和竞争压力,以及日益复杂的应用开发和部署挑战。在这样的背景下,云原生 PaaS(Platform as a Service)服务应运而生,为企业提供了一种现代化的应用开发和部署平台,帮助他们更快速、更高效地构建和运行应用程序。
云原生 PaaS 服务是一种云计算服务模式,旨在为开发人员提供一个全面的、灵活的应用开发和部署平台。与传统的基础设施即服务(IaaS)相比,PaaS 更加注重于应用层面的服务,提供了更高级别的抽象和自动化,使开发人员能够专注于应用程序的逻辑开发,而无需关心底层的基础设施管理。
作为更加注重于应用层面的服务,他具有以下特点:
基于云原生 PaaS 服务特点的总结,我们再来看它的优势:
现阶段云原生 PaaS 服务一般适用与以下场景:
企业级分布式应用服务是一种围绕应用和微服务的 PaaS 平台,提供高可用和分布式的应用支撑。它整合了资源管理、服务管理系统、分布式服务框架、服务治理、统一配置管理、分布式链路追踪、高可用性和数据化运营等功能。利用这一平台,企业能够轻松构建微服务架构,建设大规模分布式系统,实现应用发布和管理,协助IT系统转型,以满足不断增长的业务需求。
在分布式应用服务平台可视化的管控界面上,支持一站式完成应用生命周期的管控,包括创建、部署、启动、停止、扩容、缩容和应用上下线等。
分布式应用打包后部署在 Web 运行容器中,以 Java 为例,应用部署支持 war、jar、镜像等多种形式,分布式应用服务提供多样的应用发布和轻量级微服务解决方案,帮助用户解决在应用和服务管理过程中的监控、诊断和高可用等运维问题,为应用的生命周期管理、弹性伸缩以及全链路的追踪监控提供了很好的支持。分布式应用服务拥有完善的鉴权体系,为业务每一次调用保驾护航,其运行容器包括的功能及组件如下图所示:
分布式应用服务平台一般提供的主要功能主要包括:
配置中心是一个用于统一管理项目中所有配置的系统,包括应用运行过程中与环境、业务规则相关的变量。在单体架构中,这些变量通常保存在配置文件或数据库中;而在分布式微服务架构中,使用统一的配置中心来管理这些重要信息,使得可以动态修改程序运行时的配置。
随着企业应用从单体架构向分布式微服务架构演进,传统的配置文件方式出现了诸多问题,如多环境隔离、历史版本追溯、权限控制等。因此,分布式配置中心应运而生。它将各种配置、参数、开关集中到一个地方进行统一管理,并提供标准接口。各服务需要配置时可从配置中心获取,配置更新时也能实时同步。
分布式配置中心解放了业务开发者的繁琐配置工作,提升了开发和运维效率。配置和发布的解耦进一步提高了发布的成功率,同时为运维提供了更精细的管控和应急处理支持。
配置中心一般采用 C/S 模式,服务器负责配置信息的管理和推送,客户端 SDK 负责订阅和拉取配置。为了提高可用性,服务器端一般采用分布式架构。
分布式配置中心的功能特点包括配置信息的增删改查、导入导出、命名空间隔离、变更历史版本管理、配置推送、数据安全性、高性能和高可用性、高并发支持等。
虽然可以根据原理自行实现配置中心,但业内已有许多成熟的开源产品和方案可供选择,以下是其中的 6 个热门开源组件。
ZooKeeper 是一个分布式应用程序协调服务,是谷歌 Chubby 的开源实现。它是一个为分布式应用提供一致性服务的软件,提供的功能包括配置维护、域名服务、分布式同步、组服务等。Dubbo 微服务框架使用 ZooKeeper 作为其服务注册中心。在 Hadoop 集群等场景下,ZooKeeper 同时充当应用配置管理的角色。但是由于它是 CP[Consistency(一致性),Partition Tolerance(分区容错性)]类应用,因此在可用性和性能上都会受到一定的影响。
和 ZooKeeper 类似,etcd 是一个高可用的键值存储系统,主要用于配置共享和服务发现。随着 CoreOS 和 Kubernetes 等项目在开源社区日益火热,它们项目中都用 etcd 组件作为一个高可用一致性的服务发现存储仓库,etcd 也渐渐为开发人员所关注。etcd 是 CoreOS 团队于 2013 年 6 月发起的开源项目,它的目标是构建一个高可用的分布式键值(key-value)数据库。etcd 内部采用 Raft 协议作为一致性算法,它的灵感来自 ZooKeeper 和 Doozer,它使用 Go 语言编写,并通过 Raft 一致性算法处理日志复制,以保证强一致性。etcd 和 ZooKeeper 类似,同样可以用于应用管理配置。但是由于它是强一致的管理类应用,因此其可用性和性能在某些场景会受到一定影响。
Consul 是 HashiCorp 公司推出的开源产品,用于实现分布式系统的服务发现、服务隔离、服务配置。每一个功能既可以根据需要单独使用,也可以同时使用所有功能。Consul 既可以用来做分布式服务注册中心,也可以用来做分布式配置中心。Consul 是一个用来实现分布式系统的服务发现与配置的开源工具,组成部分如下。
Spring Cloud Config Server 为服务器端和客户端提供了分布式系统的外部配置支持。配置服务器为各应用的所有环境提供了一个中心化的外部配置,配置服务器默认采用 Git 来存储配置信息,其配置存储、版本管理、发布等功能都基于Git或其他外部系统来实现。客户端基于 RESTful API 和 Spring Cloud 规范来访问服务器端的配置信息,同时也支持其他语言客户端。Spring Cloud Config Server 不提供可视化的操作界面,配置也不是实时生效的,需要重启或刷新,所以比较适用于小型项目。
Nacos 是阿里巴巴开源的配置中心,对应的阿里云商业产品是应用配置管理(Application Configuration Management,ACM),是目前应用较为广泛的开源配置中心产品。尤其随着微服务架构的流行,Nacos 除了提供配置中心的功能,还提供动态服务发现、服务共享与管理的功能,以降低服务化改造过程的难度。Nacos 注册中心分为服务器端与客户端,服务器端采用 Java 语言编写,为客户端提供注册发现服务与配置服务;而客户端可以用多语言实现,客户端与微服务嵌套在一起,Nacos 提供 SDK 和 OpenAPI,如果没有 SDK 也可以根据 OpenAPI 手动编写服务注册与发现和配置拉取的逻辑。Nacos 使用起来相对比较简洁,更适用于对性能要求比较高的大规模场景。
Disconf 是百度开源的一个分布式配置中心,是一套完整的基于 ZooKeeper 的分布式配置统一解决方案,依靠 ZooKeeper 的 watch 机制来做配置修改的实时推送。Disconf 包含了客户端 disconf-Client 和管理端 disconf-Web 两个模块,均由 Java 语言实现。Disconf 支持两种开发模式:基于 XML 配置或者基于注解,可完成复杂的配置分布式化。配置信息持久化存储在 MySQL 数据库上。
随着互联网的发展,企业信息系统的数据呈爆发性增长。传统单机关系型数据库在面对不断增长的数据量时存在着先天性的弊端。为了解决这些问题,分布式数据访问代理服务应运而生,其主要作用是使传统单机数据库易于扩展、可拆分、提升性能,并规避单体结构的缺陷。
数据库的拆分方式主要有垂直拆分和水平拆分两种。
首先,垂直拆分是首选的方法。在垂直拆分中,一个关系型数据库中的表按照业务进行分类,分布到不同的数据库上。例如,交易相关的表放在一个交易库,用户相关的表放在一个用户库,商品相关的表放在一个商品库中。这样可以将数据分担到不同的库上,以降低压力。
其次,水平拆分是另一种常见的方法,通常用于解决单机瓶颈问题。水平拆分与垂直拆分的不同之处在于,水平拆分将同一个表的数据按照某个字段的规则分散到多个数据库中。简单来说,水平拆分是按行进行拆分,将表中的某些行分散到一个数据库中,而将其他行分散到其他数据库中。
在进行水平拆分时,需要选择拆分键(即分库/分表字段)。选择拆分键应遵循以下原则:
分布式数据库中间件解决的是单机数据库面临的存储数据量和并发请求量的瓶颈问题。通过物理数据库横向扩展,将数据按照拆分键的规则存储到多个单机数据库中,从而分散整体访问压力。分布式数据库中间件通过增加分库的数量和迁移相关数据来实现数据库的扩容,提高系统的数据容量和请求吞吐量。
分布式数据库屏蔽了后端的物理分库访问路由及数据聚合的复杂性,使用户能够在逻辑上获得与访问单机数据库几乎相同的体验。该服务层本身是一个集群,支持高可用性,避免了单点故障。此外,它支持分库分表存储,包括横向和纵向拆分,负责数据操作的解析和执行,并提供会话管理、分库分表策略、语义解析、请求路由、数据合并、切换控制等功能。
为实现对应用的完全透明,分布式数据库中间件高度兼容标准SQL协议和语法,无需与开发语言绑定。在功能方面,它提供以下核心能力:
在处理跨库查询时,应尽量避免性能损耗。如果无法避免,可采取以下方法:
以下是几款常用的分布式数据库中间件产品:
在应用系统中,常需要定时或周期性执行一些任务,如订单系统的状态判断、缓存数据更新、邮件发送以及定期报表生成等。单机程序通常使用线程的 while(true) 和 sleep 组合、定时器或 Quartz 框架来处理这些任务。然而,为什么我们需要分布式定时任务呢?主要有以下三点原因:
分布式定时任务产品通过集群管理调度和分布式部署,具有以下优势:
市面上有许多分布式定时任务产品,它们的核心设计思路都是将调度和任务解耦。任务节点分布式部署,通过调度中心进行任务调度。以下是五种当前流行的分布式定时任务框架:
业务实时监控服务是一种综合性产品,提供端到端的实时监控解决方案,属于应用性能管理(APM)类监控产品。它能够通过海量数据,快速为企业IT应用提供秒级的监控和响应能力。
监控分为系统监控和业务监控两大类。系统监控包括服务器资源、并发量、异常、调用链、端口和 HTTP 等监控;而业务监控则关注业务数据的正常运行,通常需要在代码中埋点以采集数据,并依赖日志系统进行底层支持。
分布式微服务架构带来了架构伸缩性和开发效率的提升,但也带来了应用监控、运维和诊断等方面的挑战。业务实时监控服务通过特定的任务配置,定义数据采集、实时处理、存储、展示分析和告警等任务,以满足各种应用场景需求。
此类产品通常提供了丰富的预设监控场景,包括业务定制监控、前端体验监控、应用性能监控和统一告警报表平台等。它们利用大数据实时计算和存储技术,为个性化业务监控提供了快速开发能力。
技术架构一般由数据采集、实时处理、存储和监控等模块组成。数据流经过数据通道、实时计算引擎、持久化存储平台和数据展示层,最终展示为各类统计分析和告警通知。
在分布式应用场景中,链路追踪技术被广泛应用,以实现应用服务的全链路追踪分析。 Prometheus 作为云原生监控框架之一,在容器和微服务领域得到了广泛应用,通过丰富的数据采集工具,提供全面的系统运行健康状态监控。
云原生业务实时监控服务能够全方位解决分布式应用监控领域的痛点,为应用系统提供无侵入的整体监控解决方案,从业务关键指标到用户体验,为用户的站点提供全方位的监控保障。
随着软件产业生态的形成,企业需要以 API 方式整合核心业务资产,并向合作伙伴或第三方开放,以促进业务模式创新、服务水平提升和合作空间拓展。服务网关(API Gateway,APIG)在企业内外系统间提供跨系统、跨协议的服务能力互通,有助于实现企业内外部门及合作伙伴之间业务能力的整合和创新。通过服务网关,企业最大化地复用IT及业务能力,从而专注于核心业务,实现共赢。
服务网关提供以下支持:
服务网关将企业内外部应用提供的服务发布为 API,提供审批授权、服务管控和计量监控等功能。它支持各种灵活的开放方式,包括内到内、内到外、外到内、外到外。服务网关提供完整的 API 发布、管理和生命周期维护管理,用户可快速、低成本、低风险地开放数据或服务,并自动生成 SDK 和 API 说明文档。
服务网关是系统对外应用接入的统一入口,封装了应用程序的内部结构,为外部调用方提供统一服务界面。它承担非功能逻辑,如认证、鉴权、监控、缓存、负载均衡、流量管控、计量计费和安全防护。核心功能包括:
服务网关充当应用程序或服务之前的系统,管理授权、访问控制和流量限制,保护 REST API 接口服务,并对所有调用者透明。这样,业务系统可以专注于核心业务处理逻辑,而不必处理基础设施。常用的服务网关包括 Zuul、Spring Cloud Gateway、Kong、OpenResty 等,以及云服务厂商的相关产品,如阿里云的 Cloud Service Bus(CSB)和API网关,腾讯云的里约网关,华为云的 APIG。
实际应用系统开发运行过程中,为了解决特定领域的问题,会用到大量的技术组件。这些技术组件大部分有成熟的产品工具或解决方案,而且经过大量用户的验证反馈,相对成熟可靠,我们可以直接使用或者借鉴,无须自行开发。
用户认证是验证某个用户是否为系统中的合法主体,即判断用户是否有权限访问系统的过程。根据系统安全等级,常见的用户认证方式包括:
在认证实现技术方面,主要包括 OAuth 2.0 和 JSON Web Token(JWT)两种方式,使用 Spring Security 框架完成相关的认证和授权验证。
OAuth 是一种授权框架,提供了详细的授权机制,用户或应用可以通过公有或私有设置授权第三方访问特定资源。OAuth 2.0 的特点包括简单、安全和开放,定义了 4 种授权模式和 4 种角色。
JWT 是一种开放标准,定义了一种紧凑且独立的方式,用于在各方之间安全地传输信息。JWT 基于数字签名验证用户凭证的合法性,认证成功后生成 token,用户可以使用 token 访问服务器上受限的资源。
Spring Security 是一个为基于 Spring 的企业应用系统提供声明式安全访问控制解决方案的安全框架,通过配置 Bean 实现声明式的安全访问控制,减少了重复编写安全控制代码的工作。
单点登录(Single Sign-On,SSO)服务允许用户在多个相互信任的应用系统中只需登录一次即可访问所有服务。在大型网站中,如阿里巴巴,存在数百个子系统,用户的操作可能涉及多个子系统的协作。如果每个子系统都要用户重新认证,将会增加用户的负担,并消耗大量资源。实现 SSO 的关键是生成和存储信任凭证,以及其他系统验证这些凭证的有效性。
通常,系统采用 session 共享方案来实现 SSO,即将用户认证信息保存在 session 中。在单个站点内,这是直接且简单的方式。然而,当用户验证、用户信息管理与业务应用分离时,就会面临 SSO 的挑战。在应用体系简单、子系统较少的情况下,可以考虑采用 session 共享方法。
session 服务用于存储与用户相关的数据,通常由 Web 容器管理。在单机情况下,所有用户的 session 数据由一台服务器持有,不存在数据不一致的情况。但在分布式环境下,用户的请求可能转发到不同的后端服务器上,如果不进行 session 共享,就会出现数据不一致的情况。因此,为了构建高可用的分布式系统,应将 session 管理从容器中独立出来,使用统一的脱离容器的 session 存储机制,通常通过分布式缓存来实现,如基于 Redis 服务器的方案。
客户端请求时,可以通过 cookie 或 URL 参数传递 sessionID,服务器根据 sessionID 从分布式缓存中获取完整的 session 数据,进行身份认证和权限判断。
为确保大型应用的各业务子系统的 session 共享,避免跨域导致的无法共享 session 的问题,各业务子系统的二级域名应配置相同的父域名。对于跨域问题,可以使用 JSONP 技术。用户登录后,与 session 匹配的 cookie 会存储在客户端中。当用户需要登录子应用时,授权应用访问父应用提供的 JSONP 接口,并在请求中携带父应用域名下的 cookie。父应用接收请求,验证用户登录状态,返回加密信息。子应用通过解析返回的加密信息验证用户,实现用户登录。
全局唯一序列号生成是设计分布式系统时常遇到的需求。特别是在数据库采用分库分表时,传统的数据库自增主键已不再能够保证全局唯一性。通常情况下,应用系统会利用开发框架提供的组件来实现全局序列号服务,以便生成全局唯一的数字序列,用于主键、唯一索引等值的生成。在某些场景下,业务需要利用序列号进行排序,因此需要生成的全局唯一序列号是有序递增的。为满足分布式环境下全局序列号服务的要求,需要考虑以下几个方面:
针对上述需求,目前业界常见的全局序列号生成技术包括:
针对高可用问题,可以采用诸如双主架构、多个 getIdService 服务获取 ID、CAS 等优化方案来解决。这些方案能够保证系统的高可用性和性能需求,并且在大部分业务场景中都具备较好的适用性。
Java 语言对数据库的访问规范是一套 API,即 JDBC API(Java数据库连接接口)。这一组标准的 Java 接口和类允许 Java 客户端程序访问各种类型的数据库。
在实际项目开发中,为了将代码与特定数据库解耦,方便应用代码在不同数据库间的迁移,通常会使用某种数据库持久化框架来进行数据访问和写入。对象关系映射(ORM)技术是对 JDBC 的封装,解决了 JDBC 存在的各种问题,是关系型数据库持久化的核心。JDBC 位于数据访问层,但使用 JDBC 编程时,必须了解后台数据库的细节,如数据库类型、表结构、字段类型、表关系等。而使用 ORM 技术,则可以完全隐藏数据库层,仅暴露 Java 对象给程序员。程序员只需调用 Java 对象的方法,而无需关注底层数据库的细节。通过隐藏 SQL 细节,ORM 技术能显著提高开发效率。
目前市场上主流的两种开源 ORM 框架分别是 Hibernate 和 iBatis/MyBatis。Hibernate 是全自动的,能够自动生成 SQL 语句,但有时效率不高。MyBatis 是半自动的,开发者需要手动编写 SQL 语句,但能够根据需求编写最优化的 SQL 语句。
随着 Spring MVC 和 Spring Boot 的广泛应用,曾经流行的 SSH 框架逐渐被取代,Hibernate 也失去了往日的优势。MyBatis 成为 Java 中常用的持久化服务,支持定制化 SQL、存储过程和高级映射。MyBatis 避免了几乎所有的JDBC代码和手动设置参数以及获取结果集的操作。MyBatis 可以使用简单的 XML 或注解对配置和原生映射进行处理,将接口和普通的 Java 对象映射成数据库记录。
数据库连接是一种关键、有限、昂贵的资源,在应用系统中对其管理直接影响着系统的可伸缩性、健壮性和性能指标。为了降低因频繁创建和释放数据库连接而带来的资源开销,生产环境的应用系统通常采用数据库连接池技术。
数据库连接池负责分配、管理和释放数据库连接,它允许应用系统重复利用现有的数据库连接,而不必重新建立连接。通过释放空闲时间超过最大空闲时间的数据库连接,避免了因未释放数据库连接而导致的数据库连接泄露问题,从而显著提高了数据库操作的性能。其基本思想是在应用启动时预先创建一定数量的数据库连接并放入连接池中,当需要建立数据库连接时,从连接池中获取一个连接,使用完毕后再归还给连接池。这样一来,连接池大大节省了数据库连接的打开和关闭开销,显著提升了系统性能。
当前 Java 开源市场主流的数据库连接池技术及产品主要包括 C3P0、数据库连接池(DBCP)、Druid 和 HikariCP。其中,C3P0 和 DBCP 作为第一代数据库连接池产品已逐渐淡出市场,新项目一般不再使用。Druid 和 HikariCP 作为第二代数据库连接池产品,借鉴了前代产品的优点,并在此基础上进行了进一步的优化和改进。
Druid 是阿里巴巴开源平台上的数据库连接池实现,具有高效、可管理、可扩展等优点。它综合了 C3P0、DBCP、Proxool 等连接池的优点,并加入了日志监控等功能,适用于需要监控连接池连接和SQL执行情况的场景。Druid 还提供了 FilterChain 模式的扩展 API,可以实现性能监控、SQL 审计、日志等功能。
HikariCP 是一款由日本程序员开源的数据库连接池组件,具有轻量、高速的特点。据官方提供的数据,在 i7 处理器开启 32 个线程 32 个连接的情况下,HikariCP 的速度是 C3P0 的数百倍。在 Spring Boot 2.0 中,官方也推荐使用 HikariCP。
在 GitHub 上有人对阿里巴巴的 Druid 与 HikariCP 进行了比较,认为 HikariCP 在性能上胜过 Druid 连接池。对此,阿里巴巴的工程师解释称,Druid 的性能稍差是因为锁机制不同,并且 Druid 提供了更丰富的功能。阿里巴巴的 Druid 有中文的开源社区,交流更加方便,并且经过阿里巴巴内部应用的验证,非常稳定可靠。而 HikariCP 是 Spring Boot 2.0 默认的连接池,在全球范围内使用广泛。对于大部分业务来说,两者的性能差异不大,用户可以根据自己的需求和偏好自由选择。
绝大多数生产系统的应用开发框架使用了 Spring 框架的事务管理机制,Spring 支持编程式事务管理和声明式事务管理两种方式。编程式事务管理通过 Spring 提供的事务模板(TransactionTemplate、PlatformTransactionManager)直接在代码中启动、回滚和提交事务。这种方式灵活但对代码具有强侵入性,因此在实际项目中使用较少。声明式事务管理是一种非侵入式的开发方式,也是 Spring 所推崇的方式。声明式事务管理可以通过基于 TX 和 AOP 命名空间的 XML 配置文件或在控制事务的代码方法上使用 @Transactional 注解来实现。
在并发情况下,不同事务同时对同一份数据进行读写可能导致数据一致性问题,主要有脏读、不可重复读和幻读三种情况。解决这些问题需要根据具体业务场景选择合适的事务隔离级别,包括读未提交、读已提交、可重复读和串行化等级别。事务传播行为是指一个事务方法被另一个事务方法调用时应该如何进行,Spring 的 TransactionDefinition 接口定义了 7 种事务传播行为类型。
以上介绍的是单机数据库中的事务一致性解决方案,但在分布式微服务架构下,事务管理的范围扩展到了不同子系统、数据库、缓存、消息队列和对象存储等多种数据存储形式。在这种情况下,事务管理不再局限于 ACID 特性,而是更广泛的数据一致性概念。目前尚无完全解决分布式事务一致性的成熟产品,尤其在高并发场景下难以保证 100% 的数据一致性。因此在实际生产环境中,需要根据具体业务场景逐个设计解决方案,包括业务调整、架构优化、分布式数据下沉以及采用最终一致性的柔性事务等方案。
异常管理在 Java 应用开发中至关重要。为了实现异常的统一处理和展现,通常建议在项目基础的开发框架中对异常进行统一拦截处理,实现对控制层、业务处理层及数据访问层的异常捕获和信息封装。业务开发人员只需在各个层次中抛出对应的业务异常和数据访问异常,框架会进行统一拦截处理,无需手动进行异常处理,从而减少代码量、提高开发效率,并实现整个系统的异常统一管理。
为实现异常的统一管理,开发框架通常定义一个异常基类 AppException,所有应用开发过程中的异常均继承自该基类。AppException 下还可以根据不同的异常种类进一步封装子类,如业务异常 BusinessException、数据访问异常 DataAccessException、权限异常 AuthException、远程调用异常 RpcException等。每个业务子系统定义自己的异常类(统一继承自 BusinessException)。
在系统运行过程中,若在控制层、业务服务层、业务逻辑层、数据访问层发生异常,Spring MVC 通过提供的统一异常处理器 UniHandlerExceptionResolver 对异常信息进行拦截处理,并记录异常日志。然后将经业务封装后的异常信息返回给UI层进行提示。应用代码开发中,捕获的异常一般直接抛到上一层,由框架在 MVC 控制层进行统一拦截。
框架采用前后端分离技术,前端通过 HTTP 请求后台服务,数据统一使用 JSON 格式。服务器端响应数据采用统一的规范格式和状态码。为方便问题定位排查和服务质量统计分析,具体项目的应用开发中,异常基类 AppException 中定义错误码 code 属性,应用代码抛出异常时需要定义该属性。
针对无法捕获的“特殊”异常,开发框架统一封装实现了Thread.UncaughtExceptionHandler 接口。通过 AOP 的方式在请求的入口方法中设置当前线程的 UncaughtExceptionHandlerAspect,以拦截处理当前线程中无法正常捕获的各种异常。
各业务系统的数据形式多样,包括结构化数据、非结构化数据、半结构化数据,以及根据数据应用场景划分的在线数据、离线数据等。面对如此复杂的数据网络情况,需要一款能够适应多样性的数据同步工具,能够实现实时增量与离线全量数据的多源异构接入和集成。
数据传输服务是一种支持关系型数据库及大数据等多种数据源之间数据交互的数据服务。它提供了数据迁移、数据实时订阅及数据实时同步等多种数据传输能力。通过数据传输服务,可以实现不停服的数据迁移、数据异地灾备、跨域数据同步、缓存更新等多种业务应用场景,助力企业构建安全、可扩展、高可用的数据架构。
数据迁移旨在实现各种数据源之间的方便快速迁移,包括上云、跨实例迁移和数据库扩容等业务场景。支持同异构数据源之间的迁移,提供库表列三级映射、数据过滤等特性。迁移过程包括结构、全量和增量数据迁移,旨在最大程度减少停机时间,保障数据一致性。
数据同步功能旨在实现两个数据源之间的实时数据同步,可应用于异地多活、数据灾备、查询分流等业务场景。支持库、表、列级别的同步对象选择,以及多种同步拓扑结构,如一对一、一对多、多对一、双向同步等。
数据订阅旨在实现关系型数据的实时增量获取,可用于缓存更新、异步解耦、跨境数据同步等场景。通过解析数据库的增量日志来获取增量数据,不影响业务和数据库性能。
对于开源数据传输工具,目前主流产品包括:
这些工具都具备丰富的功能和插件体系,可根据具体需求选择合适的工具进行数据管理和同步。
云原生 PaaS 服务作为现代应用开发和部署的重要组成部分,为企业提供了快速、灵活、可靠的应用开发和部署平台,助力他们实现业务的数字化转型和创新发展。随着云原生技术的不断成熟和普及,相信 PaaS 服务将在未来发挥越来越重要的作用,成为企业实现持续创新和竞争优势的关键驱动力量。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。