官术网_书友最值得收藏!

The need for REST

REST is a dominant communication style used in SOAs. The business domain model is exposed as resources, where each resource is a published web service that has a defined API contract. These APIs take input using a message format such as JSON and share a response compliant to the protocol used. The microservice itself will have additional external dependencies, such as other APIs for which it acts as the REST client. Since the communication is over the network, it adds to the latency of a service call and thus it's vital to keep this communication lightweight. Each service would also need to be resilient to failures in other services.

To deal with failures and performance issues in other services, a service may incorporate strategies to overcome such cases. As an example, a users service may invoke the tickets API/resource for fetching the latest tickets. For some reason, if the tickets resource is unable to return a response (due to being slow or just not available), then the users service may use a default list which is kept internally for such cases. There are other strategies such as Bulkhead, Circuit-breaker, and Timeout that aid in dealing with the complexity of distributed communication.

Since microservices are fine-grained and modeled around business capabilities, they need to communicate with other services to get work done. In a large, complex application, a request often gets processed by more than one service. When processing a use case such as opening a new ticket or assigning a ticket to a user, there can be multiple services that will participate in this request. Microservices typically communicate with each other using REST. REST APIs facilitate lightweight communication over HTTP with flexible message formats, such as JSON/XML/text, and so on.

Each service publishes a API, which is then consumed by other services which act as its REST Client. Communication among the services can be point-to-point, or based on the use case, it can be asynchronous publish-subscribe model, which is also lightweight. Here's how the communication between our issue management microservices can be visualized:

As you can see, while this is an acceptable practice, as the number of services grow, so will the complexity inherent with point-to-point communication. Here's where an API Gateway adds value to microservices by providing certain benefits:

  • A single entry point for external calls which gets routed to your services internally
  • Acts as a layer of security, preventing any attacks from external sources
  • Can act as an adapter, allowing for the handling of different message protocols
  • Can provide monitoring and logging across services
  • It also takes away the problem of service discovery from the clients
  • The gateway can also apply the Circuit-breaker pattern for fault tolerance:

While the gateway does act as a layer for routing and message translations (almost similar to an enterprise service bus), it's important to keep it dumb and not add any business logic to it. This would allow the endpoints to evolve, without having to worry about part of its logic residing on the gateway.

主站蜘蛛池模板: 将乐县| 锦州市| 和硕县| 应城市| 射阳县| 工布江达县| 巴彦淖尔市| 高要市| 阿拉善盟| 乌拉特前旗| 博客| 镇雄县| 南川市| 蚌埠市| 冷水江市| 武平县| 麻栗坡县| 枣阳市| 霍州市| 子洲县| 凤阳县| 平罗县| 安化县| 巴南区| 巴林右旗| 合川市| 富顺县| 石家庄市| 南康市| 镇远县| 浮山县| 左云县| 南江县| 屏东市| 洪泽县| 邵阳县| 仪陇县| 堆龙德庆县| 平潭县| 大渡口区| 永川市|