Ruby是计算机语言中的绅士，如果要用一个词来形容，那一定是优雅，有这么一位Rubyist，他的座右铭是“写优雅的程序，做一个优雅的人”，他是来自七牛小伙伴“薄荷”的Co-founder兼CTO谢文威（英文名Vincent）。薄荷的核心系统完全基于Ruby构建，关于Ruby服务间通信模式，他在“七牛弯区课堂”给Ruby爱好者们做了一次分享。
上图是薄荷App服务划分的例子，各子系统（服务）间需要进行各种通信，主要通信种类如下。
一、A服务需要使用Ｂ服务的一些数据 共享数据库
应用场景：用户的年龄、性别、身高和体重等数据存储在账号子系统中，其它子系统经常需要使用这些数据。
处理方式：共享数据库
App2直接建立连接访问 App1的数据库。这种方式的优点是性能较好，避免了接口处理和消息封装种种开销，适用于通信特别频繁或者数据量特别大的场合。薄荷的账号和会话数据即采取这种方案。但是，该方式导致服务间有很强的耦合，App2对App1的数据结构有紧密的依赖，导致App1的实现难以变更。
共享数据库方法：
ActiveRecord支持多数据库配置有一些注意的事项：
可以使用关联，不支持join，不支持事务
测试数据最好使用factory_girl
为避免数据混乱，只有一个服务可写
共享模型使用
gem model
git submodule
二、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则是一种比较成熟的方案。
三、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任务处理，以下是其核心代码：
四、A服务发生某件事，通知Ｂ和Ｃ进行处理 订阅和通知
应用场景：比如账号基本信息，基于性能考虑，在子系统中存储了用户名副本。当用户名在账户子系统中发生变化时，需要通知其它子系统更新。
处理方式：消息队列
Sidekiq-driver 是Vincent正在写的基于sidekiq轻量订阅和通知解决方法的gem，大家可以尽情期待这个项目的开源。
这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.