当前位置：网站首页>Get started quickly and conquer three different distributed architecture calling schemes

Get started quickly and conquer three different distributed architecture calling schemes

2022-08-10 10:53:00 【InfoQ】

Author: Knowledge Talk, CSDN Contract Lecturer, CSDN Blog Expert, Huawei Cloud Cloud Sharing Expert, Alibaba Cloud Star Blogger
Field of Expertise: Full StackEngineers, crawlers, ACM algorithms
Public account: Knowledge Talk
Contact vx: zsqtcc

Three different distributed architecture call schemes

Load balancer scheme

UsersWhen accessing nginx, nginx accesses different server nodes through the polling strategy of the complex balancer.

null

SpringCloud solution

Introduce the registration center, so that service consumers and service providers can register with the registration center. Consumers/providers need to know the IP address and port information of the other party in the registration center, and then communicate through http.

null

Google's Isto grid scheme

The ground test is based on the scheme of k8s+registry+EnvoyProxy.

null
In addition to service provisionIn addition to producers and service consumers, there is also Envoy. Envoy mainly communicates by encapsulating information, rather than allowing service producers and service consumers to communicate directly.

Comparison of the three schemes

Horizontal comparison
  • Load balancer scheme
  • Supports automatic expansion: not supported, requires operation and maintenance intervention
  • Core components: Nginx, HaProxy, F5
  • Application coupling degree: high
  • Load balancing granularity:Independent process
  • Communication efficiency (theoretical): depends on the specific product
  • Communication mode: all, depends on the load balancing product
  • The cost of upgrading the old system: easy and happy
  • Recommended Scenario: Traditional Enterprise Application
  • Spring Cloud Solution
  • Support automatic expansion: support, service registration discovery
  • Core components: Eureka,Nacos,Consul
  • Application coupling degree: low
  • Load balancing granularity: In-process
  • Communication efficiency (theoretical): High
  • Communication mode: all, default RESTful, support various RPC (DUBBO)
  • Old system upgrade cost: barely usable
  • Recommended scenarios: enterprise application transformation, Internet application products
  • lsto service grid solution
  • Support automatic expansion: support, service registration discovery
  • Core components: k8s,Istio pilot-discovery,Envoy
  • Application coupling: low
  • Load balancing granularity: independent process
  • Communication efficiency (theoretical): General
  • Communication mode: default RPC(GRPC), extended support for RESTFul
  • Old system upgrade cost: uncomfortable
  • Recommended scenarios: cloud native and large-scale cloud infrastructure applications

Summary

The above is about the use of three different distributed architectures, which can be used for reference and analysis.
原网站

版权声明
本文为[InfoQ]所创，转载请带上原文链接，感谢
https://yzsam.com/2022/222/202208101020461126.html

边栏推荐

猜你喜欢

随机推荐