Ruby Inter-service communication model for "seven-corner classroom"

Ruby is a gentleman in computer language, if you want to use a word to describe, it must be elegant, there is such a rubyist, his motto is "Write elegant program, do an elegant person", he is from seven cattle small partner "mint" Co-founder and CTO Shevin Wei (English name Vincent). The Mint's core system was built entirely on Ruby, and he shared the Ruby lovers ' seven in the Bull bend Zone class on the Ruby inter-service communication model.

is an example of the Mint App Service division, where various subsystems (services) need to communicate, the main types of communication are as follows.

One, a service needs to use some data sharing database of B service

Application Scenario: The user's age, gender, height, and weight are stored in the account subsystem, and other subsystems often need to use the data.

How to: share a database

APP2 directly establishes a connection to access the APP1 database. The advantage of this method is good performance, avoid the interface processing and the various overhead of message encapsulation, it is suitable for occasions where communication is very frequent or data volume is particularly large. Mint's account and session data will take this approach. However, this approach leads to strong coupling between services, APP2 has a close dependence on APP1 data structure, which makes the implementation of APP1 difficult to change.

To share a database method:

ActiveRecord support for multiple database configurations There are a few things to note:

• can use associations, do not support joins, do not support transactions

• test data is best used Factory_girl

• to avoid data clutter, only one service can be written

Shared model Usage

• Gem Model

• git submodule

Second, a service needs B service to provide a result of a calculation request (synchronous)

Application Scenario: The calculation of budget heat requires the use of a complex mathematical model, which is implemented in the recording subsystem, and other systems need to use the relevant data, through a communication mechanism to get the calculation results.

processing mode:httpapi call and RPC

1) Http API Call

This is the most common form of communication, the service implementation of the mature and reliable, with a simple and clear service margins, while applicable to the external and internal, but the internal call performance is not good enough.

Considerations for using the HTTP API

• access security controls, using IP restrictions, token checksums, etc.

• Avoid call hierarchy too deep, timeout mechanism

• HTTP Client selection (HTTP client is particularly numerous, mainly divided into the following categories)

Mint at present Typhoeus and Faraday use more, reason is: Typhoeus bottom based on curl, performance is better, and support parallel, use asynchronous API way, more reliable, don't worry about multithreading problem.

2) RPC (Remote Procedure Call)

Main Features:

• long connection to avoid creating a network connection for each communication, good performance

• more efficient for HTTP and message protocols

• multiple cross-language RPC scenarios, such as Thriftmsgpack_rpc

RPC Management

Performance has a certain advantage, need to weigh its complexity, complexity lies in service implementation and management methods.

• server-side concurrency mode

• high-availability scenarios, available Haproxy

• Smooth Deployment

RPC is a relatively rare and more common use for teams across multiple languages, and RPC is a relatively mature scenario when a company uses multiple languages and needs to be well integrated.

Third, a service requires B service to process a task Request task processing (asynchronous)

Application Scenario: in the shopping module, an order occurs after payment, you need to send some information to the user, such as texting, mail and mobile phone push. Sending a message can take a long time to complete, and the requester does not need to wait for the result to be processed.

processing mode: Message Queuing

1) Legacy Message Queuing system rabbitmq/active MQ

MQ can have a reduced coupling between services, usually for asynchronous processing between services (traditional MQ has a richer processing mechanism), traditional MQ Ruby service implementations can refer to sneakers, hutch, RACK-AMPQ, Rack-rabbit.

2) Redis-based lightweight Message Queuing is often used within a single application

Resque&sidekiq

3) Sidekiq-postman

It is a gem written by Vincent, based on SIDEKIQ lightweight Message Queuing solution, simple and practical, can be SIDEKIQ task processing across application requests, the following is its core code:

Iv. A service happens, notify B and C for processing subscriptions and notifications

Application Scenarios: such as account basic information, based on performance considerations, in the subsystem stored a copy of the user name. When the user name changes in the account subsystem, other subsystem updates need to be notified.

processing mode: Message Queuing

Sidekiq-driver is a gem that Vincent is writing based on SIDEKIQ Lightweight subscription and notification solutions, and you can look forward to open source for this project.

the "Seven Ngau Bend Area Classroom" is a seven cow for the vast number of developers to provide technical practice sharing classroom, follow-up will regularly invite experts from the technical community to share. The above is the debut of the Ruby China community in the "Seven Corner class". The small partners of the technical community are welcome to share their hands-on experiences in the "Seven Ngau Bend Zone Class" and also to thank you for your contribution to the technology community.

Ruby Inter-service communication model for "seven-corner classroom"