【七牛弯区课堂】Ruby服务间通讯模式

Ruby是计算机语言中的绅士，若是要用一个词来形容，那必定是优雅，有这么一位Rubyist，他的座右铭是“写优雅的程序，作一个优雅的人”，他是来自七牛小伙伴“薄荷”的Co-founder兼CTO谢文威（英文名Vincent）。薄荷的核心系统彻底基于Ruby构建，关于Ruby服务间通讯模式，他在“七牛弯区课堂”给Ruby爱好者们作了一次分享。

上图是薄荷App服务划分的例子，各子系统（服务）间须要进行各类通讯，主要通讯种类以下。

1、A服务须要使用Ｂ服务的一些数据 共享数据库

应用场景：用户的年龄、性别、身高和体重等数据存储在帐号子系统中，其它子系统常常须要使用这些数据。

处理方式：共享数据库

App2直接创建链接访问 App1的数据库。这种方式的优势是性能较好，避免了接口处理和消息封装种种开销，适用于通讯特别频繁或者数据量特别大的场合。薄荷的帐号和会话数据即采起这种方案。可是，该方式致使服务间有很强的耦合，App2对App1的数据结构有紧密的依赖，致使App1的实现难以变动。

共享数据库方法：

ActiveRecord支持多数据库配置有一些注意的事项：
可使用关联，不支持join，不支持事务
测试数据最好使用factory_girl
为避免数据混乱，只有一个服务可写

共享模型使用
gem model
git submodule

2、A服务须要Ｂ服务提供某个计算结果 请求结果（同步）

应用场景：计算预算热量须要使用复杂的数学模型，它放在记录子系统中实现，别的系统须要用到相关的数据时，经过一种通讯机制拿到计算结果。

处理方式：HttpAPI Call和RPC

1）Http API Call

这是最多见的一种通讯方式，服务实现方案成熟可靠，具备服务边际简单清晰的特色，同时适用于外部和内部，但内部调用性能不够好。

使用Http API注意事项
访问安全控制，使用ip限制，token校验等
避免调用层次过深，超时机制
Http Client选择（Http Client特别多，主要分为如下几类）

薄荷目前typhoeus和faraday用的较多，缘由是：typhoeus底层基于curl，性能比较好，而且支持并行，用异步API的方式，比较可靠，不用担忧多线程问题。

2）RPC（Remote Procedure Call）

主要特色：
长链接，避免每次通讯建立网络链接，性能较好
对http、消息协议更高效
多种跨语言RPC方案，如thriftmsgpack_rpc
RPC管理
性能上有必定优点，须要权衡其复杂度，复杂度在于服务实现方案和管理方法。
服务端并发模式
高可用方案，可用HAProxy
平滑部署

RPC的用法比较少见，更多地用于跨多语言的团队，当公司使用多种语言且须要很好地整合时，RPC则是一种比较成熟的方案。

3、A服务须要Ｂ服务处理一项任务 请求任务处理（异步）

应用场景：在购物模块里面，一个订单发生支付后，须要给用户推送一些信息，好比发短信、邮件和手机推送等。发送消息可能须要比较长的时间才能完成，请求方不须要等待处理结果。

处理方式：消息队列

1）传统消息队列系统RabbitMQ/Active MQ
MQ能够有下降服务之间耦合度，一般用于服务之间的异步处理（传统MQ有更丰富的处理机制），传统MQ ruby服务实现方案，能够参考sneakers, hutch, rack-ampq, rack-rabbit。
2）在单个应用内部经常使用基于redis的轻量消息队列
resque&sidekiq
3）sidekiq-postman

它是Vincent写的一个gem，基于sidekiq轻量消息队列解决方法，简单实用，能够跨应用请求sidekiq任务处理，如下是其核心代码：

4、A服务发生某件事，通知Ｂ和Ｃ进行处理 订阅和通知

应用场景：好比帐号基本信息，基于性能考虑，在子系统中存储了用户名副本。当用户名在帐户子系统中发生变化时，须要通知其它子系统更新。

处理方式：消息队列

Sidekiq-driver 是Vincent正在写的基于sidekiq轻量订阅和通知解决方法的gem，你们能够尽情期待这个项目的开源。

【七牛弯区课堂】是七牛为广大开发者提供的技术实践分享课堂，后续将按期邀请各技术社区的专家进行分享。以上内容便是Ruby China社区在“七牛弯区课堂”的处女做。欢迎各技术社区的小伙伴来【七牛弯区课堂】分享实践心得，也感谢各位为技术社区所贡献的力量。