Phoenix Architecture 2 - accessing remote services

Access remote services

Remote service invocation

Interprocess communication （Inter-Process Communication,IPC） The way to

• The Conduit （Pipe） Or named pipeline （Named Pipe）： Pass a small number of character streams or byte streams , Common pipes are only used for related processes （ Another process started by one process ） Communication between , Named pipeline gets rid of the limitation that ordinary pipeline has no name , In addition to all the functions of the pipeline , It also allows communication between unrelated processes
• The signal （Signal）： Notifies the target process that an event has occurred
• Semaphore （Semaphore）: Synchronous collaboration means between two processes
• Message queue （Message Queue）: Can transmit a large amount of information , But the real-time performance is relatively limited
• Shared memory （Shared Memory）： Allow multiple processes to access the same common memory space
• Socket interface （Socket）： It can be used for process communication between different machines

RPC There are three basic problems in this paper

• How to represent data ： The data involved in the interaction between the two parties will be transformed into a neutral data stream format agreed in advance for transmission , Convert the data stream back to the corresponding data type in different languages for use （ Such as serialization and deserialization ）
• How to pass data ： Through the network , In two services Endpoint Operate with each other 、 Exchange data （ Application layer protocol ）.
• How to determine the method ： How different languages express the same method

Different RPC

None of them RPC It can perfectly satisfy the above three points , So there are different RPC

• Towards object-oriented development ：RMI, This line has an alias called distributed objects
• Towards performance （ Serialization efficiency and information density ）：gRPC （ be based on HTTP/2 Of , Support multiplexing and Header Compress ） and Thrift（ Transport layer based TCP Protocol to implement , Eliminates the overhead of additional application layer protocols ）
• Towards simplification , Representative for JSON-RPC（ The simplicity and portability of the agreement , The interface and format are more general ）

REST Design style

RPC Procedure call oriented ,REST Resource oriented invocation

Fielding Think , An ideal 、 Completely satisfied REST Style system should meet the following six principles ：

1. The server is separated from the client （Client-Server）： Separate the logic of the user interface from the logic of the data store , It helps to improve the cross platform portability of the user interface
2. No state （Stateless）： In the request sent by the client , All necessary contextual information shall be included , The session information is also saved and maintained by the client , The server executes business processing logic according to the state transmitted by the client
3. Caching （Cacheability）： A well functioning caching mechanism can reduce the number of clients 、 Interaction between servers
4. Layered system （Layered System）： The client does not need to know whether it is directly connected to the final server
5. Unified interface （Uniform Interface）：
6. On demand code （Code-On-Demand）： The client does not need to know in advance how to handle all the information from the server 、 How to run tolerance

Advantages and disadvantages

advantage

1. Reduced learning costs of service interfaces ： Standard operations on resources are mapped to standard HTTP The way up
2. Natural resources have set and hierarchy ： Resource centric abstract interfaces , Because the resource is Noun , Naturally, collections and hierarchies can be generated .GET /users/icyfenix/cart/2
3. REST Bound to HTTP agreement .

Deficiencies and disputes

1. The idea of resource oriented programming is only suitable for CRUD, Process oriented 、 Only object-oriented programming can deal with really complex business logic ： The idea of resource-oriented programming is different from the other two mainstream programming ideas when they are only abstract problems , Only choice questions , There's no difference between high and low
2. REST And HTTP Fully bound , It is not suitable for applications requiring high-performance transmission ： Resource oriented programming is protocol independent , however REST It does depend on HTTP Standard approach to protocol 、 Status code 、 The first aspect of the agreement , For transmission requiring direct control , Such as binary details 、 Coding form 、 Message format 、 In the scene of connection mode and other details ,REST Not really , These scenarios often exist between the internal nodes of the service cluster
3. REST Not conducive to transaction support ： If you give up rigid transactions , Use REST There must be no hindrance
4. REST No transmission reliability support
5. REST Lack of resources “ part ” and “ Batch ” Handling capacity of