标签墙

微服务

基于数据库复制的技术架构讨论

背景 这里的数据库复制指的是将 业务数据库实例上的库通过同步机制(比如 MySQL binlog)实时(比如最大延迟为 3s)复制到其他数据库实例上,这些实例库只做查询,不做数据写入。 这套架构设计的主要优势: * 各业务应用能够方便地在自己的 DB 实例上进行业务查询,比如通过 join 主业务库 * 在不明确业务边界、没有梳理好业务对应技术模块时可以最小成本进行变更或扩展 * 实现读写分离,提升性能 ### 一些问题 实际在实施过程中主要遇到两个问题: 1. 不可能实时完成数据同步,将造成业务上面的不一致,比如调用主库服务更新数据后,在业务库上不能实时查询到已更新的数据 2. 很难保证高可用(在使用阿里 DTS 时出现过多次问题,自己做主从可能会好一些) 为了满足业务发展,复制库的数量会逐步增多(比如新开一个产品可能就需要多复制一套库),以上两个问题可能会导致严重的故障, [CAP] 不能兼得。 ### 服务化 基于数据库复制架构的核心理念是将数据源暴露给应用,开发者直接针对数据源进行开发,是一种非常直接的方式。 但随着业务的逐渐清晰,一些业务逻辑是可以抽....

More...

理解 Eureka 的 P2P 通讯

Eureka 客户端会和在同一个可用区(Zone)的服务端进行通讯,如果通讯失败或者服务端没有和客户端在一个可用区,则客户端将进行失效转移:对其他可用区的服务端发起通讯。 服务端接收到客户端信息后,会进行一些列操作将信息同步给其他服务端节点。如果某步操作失败,信息将在下一次心跳时同步给其他服务端节点。 当一个 Eureka 服务端节点启动后,它将向其他服务端节点获取所有实例的注册信息。服务端获取到实例列表后将根据信息创建续约(renew)相关数据并准备接收来自客户端的续约请求。如果在某个时刻客户端续约失败(15 分钟内低于 85%),服务端将停止实例过期防止该实例注册信息丢失。 在 Netflix 内部,上述过程称作自我保护模式,是 Eureka 客户端和服务端通讯时发生断网的一个保护机制。在这个场景下,服务端将尝试保存住已有的注册信息。此时客户端获取的实例列表中有可能有的实例已经不能正常服务了,客户端需要自己保证 Eureka 服务端返回的实例在不存在或不响应情况下是弹性的,最好的处理方式就是对该实例的调用设置较短超时并尝试其他服务器。 当服务端没法从其他节点获取注册信息时,....

More...