Technology Sharing

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

Service Split:

1. Single Responsibility Principle: In a microservice architecture, a service should only be responsible for one function or business area. Each service should have clear definitions and boundaries and only focus on its own specific business area.

2. Service autonomy: Service autonomy means that each microservice should have a high degree of autonomy, that is, each service should be able to be independently developed, tested, built, deployed, and run.

3. One-way Dependency

Microservices must have one-way dependencies, and circular dependencies and two-way dependencies are strictly prohibited.

Circular dependency: A->B->C->A

Bidirectional dependency: A->B, B->A

Examples:

1. Order list

2. Product List

Order service: provide order ID and get order details

Product service: Return product details based on product ID

When querying order information based on an order, obtain product details based on the product ID in the order

accomplish:

Implementation idea: The order-service service sends an HTTP request to the product-service service, combines the returned result with the order result, and returns it to the caller

Implementation method: Use RestTemplate provided by Spring

1. Define RestTemplate

@Configuration

public class BeanConfig{
        @Bean

       public RestTemplate restTemplate{

           return  new RestTemplate();

      }

}

2. Use restTemplate in order-controller

RestTemplate:

Rest（Representational  State TRanfer) Representation layer resource state transfer

Resources: Data on the Internet, such as pictures, videos, text, etc. are all resources

Presentation layer: the representation of resources (for example, text is represented as txt, images are represented as jpg, and some resources are represented as json, xml, or binary)

State transfer: When we access resources through the network, adding, modifying, deleting, etc., the resource state will change. Simply put: REST describes a form of interaction between Client and Server in the network. REST itself is not practical, but how to design a RESTful API (REST-style network interface) is used.

The Restful style has the following characteristics:

1. Resources

2. Unified interface: Operations on resources, such as obtaining, creating, modifying and deleting, correspond to the GET, POST, PUT and DELETE methods provided by the http protocol. In other words, if you use a RESTful interface, you may only locate the resource from the interface, but you cannot know what specific operations it has performed. To know what specific operations have occurred, you need to judge from the type of http request method (for example, the same url: GET/blog/{blogId}: query blog DELETE/blog/{blogId} delete blog)

RESTful API Disadvantages:

1. The operation method is cumbersome. RESTful API usually distinguishes the operation actions on resources based on GET, POST, PUT, and DELETE. However
HTTP Method is not directly visible and can only be observed through tools such as packet capture. It is more direct to put the action on the URL.
It is more conducive to team understanding and communication.
2. Some browsers are not very friendly to requests other than GET and POST, and require additional processing.
3. Over-emphasis on resources. Actual business needs may be more complex, and cannot be met simply by adding, deleting, modifying, and checking.
RESTful API will increase development difficulty and cost.

Project has problems
1. When calling remotely, the URL's IP and port number are hardcoded (http://127.0.0.1:9090/product/). If you change the IP, you need to modify the code.
code
2. How can the caller not rely on the IP of the service provider?
3. How to share the pressure when deploying multiple machines?
4. When making a remote call, the URL is easy to be written incorrectly, and the reusability is not high. How to implement remote calls elegantly?
5. All services can call this interface. Is there any risk?