服务提供者需要支持通过配置、注解、API调用等方式,把本地接口发布成远程服务;对于消费者,可以通过对等的方式引用远程服务提供者,实现服务的发布和引用。

1 服务发布设计

服务发布流程:

1.1 服务发布的几种方式

  1. XML配置化方式:业务代码零侵入
  2. 注解方式:业务代码低侵入
  3. API调用方式:业务代码侵入较强
阅读全文 »

1 几个概念

1.1 服务提供者

1.2 服务消费者

1.3 服务注册中心

服务注册中心是分布式服务框架的目录服务器,相比于传统的目录服务器,它有如下几个特点:

  1. 高 HA:支持数据持久化、支持集群。
  2. 数据一致性问题:集群中所有的客户端应该看到同一份数据,不能出现读或者写数据不一致。
  3. 数据变更主动推送:当注册中心的数据发生变更时(增加、删除、修改)需要能够及时将变化的数据通知给客户端。
阅读全文 »

1. 第一次聚会:2018/06/08 南京

序号 达到日期 起始时间 起始地点 车次号 婚育概要
1 陈佳慧 2018-06-08 全天 南京~南京 未婚
2 孔令洲 2018-06-08 全天 南京~南京 未婚
3 高帅星 2018-06-08 全天 南京~南京 未婚
4 蒋鑫 2018-06-08 全天 南京~南京 未婚
5 王雨木 2018-06-08 16:10~18:45 长春~南京禄口 DZ6258 未婚
6 黄菡璐 2018-06-08 20:09~22:10 义乌~南京南 G1504 未婚
7 谢飘飘 2018-06-08 20:42~22:10 杭州东~南京南 G1504 未婚
8 陈圳 2018-06-08 18:39~22:12 汉口~南京南 D2374 未婚
9 吴琦薇 2018-06-08 20:35~22:27 上海~南京南 G7286 未婚
10 李文广 2018-06-08 20:35~22:27 上海~南京南 G7286 未婚
11 孙任 未婚
12 李婷婷 未婚
13 杨璐菡 未婚
阅读全文 »

由于惯性思维,很多人会将传统 MVC架构/RPC架构的做法带入到分布式服务框架的架构设计中,其中有些思想存在误区,或者已经过时,它们会破坏分布式服务框架的架构品质。

1 几个误区

1.1 NIO 就是异步服务

NIO 只解决了通信层面的异步问题,跟服务调用的异步没有必然关系,也就是说,即便采用传统的 BIO 通信,依然可以实现异步服务调用,只不过通信效率和可靠性比较差。
下面对异步服务调用和通信框架的关系进行说明:

用户发起远程服务调用之后,经历层层业务逻辑处理、消息编码,最终序列化后的消息会被放入到通信框架的消息队列中。业务线程可以选择同步等待、也可以选择直接返回,通过消息队列的方式实现业务层和通信层的分离是比较成熟、典型的做法。
采用 NIO还是 BIO对上层的业务是不可见的,双方的汇聚点就是消息队列。业务线程将消息放入到发送队列中,可以选择主动等待或者立即返回,跟通信框架是否是 NIO 没有任何关系。

阅读全文 »

集群服务调用失败后,服务框架需要能够在底层自动容错。

1 集群容错场景

在分布式服务框架中,业务消费者不需要了解服务提供者的具体未知,它发起的服务调用请求也不包含服务提供者具体地址信息。因此,某个服务提供者是否可用对消费者而言无关紧要,最终的服务调用成功才是最重要的。
经过服务路由之后,选定某个服务提供者进行远程服务调用,但是服务调用可能会出错,下面进行故障场景进行分析。

阅读全文 »

分布式服务框架上线运行时都是集群组网,这意味着急群众存在某个服务的多实例部署,消费者如何从服务列表中选择合适的服务提供者进行调用,这就涉及到服务路由。

1 透明化路由

1.1 基于服务注册中心的订阅发布

在分布式服务框架中,服务注册中心用于存储服务提供者地址信息、服务发布相关的属性信息,消费者通过主动查询和被动通知的方式获取服务提供者的地址信息,而不需要像之前那样在代码中硬编码服务提供者地址信息。消费者只需要知道当前系统发布了哪些服务,而不需要知道服务具体存在于什么位置,这就是透明化路由。它的工作原理就是基于服务注册中心(例如 ZooKeeper)的订阅发布机制。
服务注册中心的工作原理如下:

阅读全文 »

1 关键技术点分析

1.1 是否必须支持多协议

分布式服务框架需要具备通过扩展的方式支持多协议的能力,协议栈应该作为一个架构扩展点开放出来。

1.2 公有协议还是私有协议

以 Web Service 公有协议为例,它的性能存在如下缺陷:

  1. SOAP 消息使用 XML 进行序列化,相比于 PB 等二进制序列化框架,性能低很多。
  2. SOAP 通常由 HTTP 协议承载,HTTP 1.0 不支持双向全工通信,而且一般使用短连接通信,性能比较差。
阅读全文 »

1 几个关键概念澄清

通常我们习惯将序列化(Serialization)称为编码(Encode),它将对象序列化为字节数组,用于网络传输、数据持久化或其它用途。
反之,反序列化(Deserialization)/解码(Decode)把从网络、磁盘等读取的字节数组还原成原始对象(通常是原始对象的副本)。

1.1 序列化与通信框架的关系

阅读全文 »

恭喜 RNG,恭喜 UZI

六年
恋恋不忘
必有回响


1 关键技术点分析

1.1 长连接还是短连接

绝大多数的分布式服务框架(RPC框架)都推荐使用长连接进行内部通信,为什么选择长连接而不是短连接呢?具体原因如下:

  1. 相对比短连接,长连接更节省资源。长连接只会在首次创建时或者链路断连重连才创建链路,链路创建成功之后服务提供者和消费者会通过业务消息和心跳维系链路,实现多消息复用同一个链路节省资源。
  2. 远程通信是常态,调用时延是关键指标:服务化之后,本地 API 调用变成了远程服务调用,大量本地方法演进成了跨进程通信,网络时延称为关键指标之一。相比于一次简单的服务调用,链路的重建通常耗时更多,这就会导致链路层的时延消耗远远大于服务调用本身的损耗,这对于大型的业务系统而言是无法接受的。
阅读全文 »

1 分布式服务框架诞生背景

1.1 集中式到分布式

  1. 业务发展、应用规模变大,大型复杂应用的开发维护成本高,部署效率低,应用数量膨胀,数据库连接数变高。
  2. 代码复用低:由于公共模块都是进程内部的本地 API 调用,开发者按需开发,导致大量相同功能的 API 被重复开发。一旦涉及到公共模块的功能变更,所有重复实现都需要重新修改、编译和测试。
  3. 敏捷持续交付:想要在一个架构师都无法理解的巨无霸业务中新增或者修改一个功能,难度是非常大的。业务模块之间的循环依赖、重复 API 定义和开发、不合理的调用、冗长复杂的业务流程对新特性的上线简直是梦魇。
阅读全文 »