Spring Cloud Alibaba reading notes_3: Service governance under the microservice architecture

Service governance under the microservice architecture

RPC

Remote Procedure Call (Remote Procedure Call) is a computer communication protocol. This protocol allows a program running on a computer to call a subprogram in another address space (usually a computer on an open network), and the programmer is like calling a local program without additional programming for this interaction (no need Pay attention to details).
RPC is a server-client (Client/Server) model. The classic implementation is a system that exchanges information by sending a request and receiving a response. [From Wikipedia]
Process :

• The client calls the client stub (client stub). This call is made locally and pushes the call parameters to the stack.
• The client stub (client stub) wraps these parameters and sends them to the server machine through a system call. The packaging process is called marshalling. (Common methods: XML, JSON, binary encoding)
• The client's local operating system sends information to the server. (Can be transmitted through custom TCP protocol or HTTP)
• The server system transmits information to the server stub (server stub).
• The server stub (server stub) parses the information. This process is called unmarshalling.
• The server stub (server stub) calls the program and returns it to the client in a similar way.
  

Apache Dubbo

Reasons for the frame:

• After large-scale servicing, when the service provider fails or needs to dynamically expand, the relevant configuration needs to be updated, and the maintenance cost is very high. It is extremely important to realize the dynamic line perception of the service up and down and the dynamic maintenance of the service address.
• Service indicator monitoring requires reasonable regulation and allocation of server resources according to the access conditions of different services to improve machine utilization.
  

ZooKeeper

ZooKeeper is a high-performance distributed coordination middleware , which mainly solves the access control problem of each service process in a distributed environment . ZooKeeper is not a registry, but the business scenario of a registry can be realized based on the characteristics of ZooKeeper itself.

• Znode
  • Installation note:
    • Downloaded by default zk_sample.cfg, make a copy and name itzk.cfg
    • In the version above 3.5, the 8080port will be ZooKeeper Admin Serveroccupied, you need to zk.cfgconfigure the admin.serverPortconfiguration.
  • Data structure [ structured hierarchical storage ]

ZooKeeper tree each node is called Znode, Znodeit maintains a statstate information, wherein the data comprises a time varying versions and the like. Each Znodemay be a set valuevalue, and the data of each node is allowed to read and write to. Read: get specified Znodeon the valuedata; write: modify specified Znodeon the valuedata.

• Type [ Under the same level directory, the name of the node must be unique , the root node: /dubbo ]
  • Persistent node: The node data needs to be persisted to the disk disk.
  • Temporary node: The life cycle of the node is the same as the life cycle of the client that created the node. When the client session ends, the temporary node will be automatically deleted.
  • Ordered node: an increasing sequence will be added behind the created node , which is unique under the same level of parent node . Persistent nodes or temporary nodes can also be set as ordered nodes.
  • Container node (3.5.3+): When the last child node under the container node is deleted, the container node will be automatically deleted .
  • TTL node (3.5.3+): For persistent nodes or persistent ordered nodes , the survival time can be set . If the node has no modification and no child nodes within the survival time, it will be automatically deleted.
• Watcher mechanism [ Znodesubscription/notification mechanism ]
  • Observation operation provided the existsAPI: getChildren, ,getData
  • Operation Trigger observation createAPI: delete, ,setData
  • Description of the trigger mechanism: Event triggers are all one-offs. After the client sets the observation and registration monitoring, if the service node changes data, the client will receive a notification. But when the data modification of the service node occurs again, the client cannot receive the Watcher event. Therefore, the client must register for the event again in the event notification callback.
• Application scenario
  • Distributed lock: In a distributed architecture, multiple processes access the same shared resource with data security issues, which need to be resolved in the form of locks. Combining the exclusiveness of locks, it realizes the control of multi-process shared resource access in the process of acquiring and releasing locks.
  • Master election
    • A node at the same level cannot repeatedly create an existing node, which is analogous to a distributed lock. Non-Master nodes register for Watcher events, and when a node is in a non-survival state, the Master election will be re-elected.
    • Election is achieved through temporary ordered nodes. Temporary nodes are time-sensitive. Ordered nodes will have an increasing sequence. In a single session, with the increasing sequence, each node will be arranged in order. In accordance with the latter's principle of looking at the former, register Watcher Event, when the current node is deleted, the next node of the current node is elected as the Master node.
• More acute problems with RPC communication:
  • Service dynamic online and offline awareness: maintenance service configuration management, dynamic processing
  • Load balancing: According to the actual situation, perform reasonable scheduling, allocation and management of service configuration resources
    

Apache Dubbo Advanced Application

• The service supports multiple protocols publish, by default dubbo://, support rest://, webservice://, thrift://and so on.
• It supports several different registries, such as Nacos, ZooKeeper, Redisand so on.
• Support multiple serialization technique, such as avro, fst, fastjsonand the like.

Examples of service governance applications :

• Cluster fault tolerance: an elegant solution for service exceptions [In actual applications, the default Failover strategy is recommended for query operations, and the Failfast strategy is recommended for addition, deletion, and modification operations]
  • Failover: automatic switching on failure, the default number of retries is 2, suitable for read operations, transactional operations will cause data duplication problems
  • Failfast: fail fast, only initiate a call, suitable for idempotent write operations, stop loss in time
  • Failsafe: fail safe, ignore exceptions
  • Failback: automatically reply after failure, retransmit regularly, suitable for message notification operation
  • Forking: Invoke multiple services in the cluster in parallel, and return after successful one
  • Broadcast: Broadcast calls to all service providers, if a failure occurs, the call fails, which is suitable for notifying service providers to update services or local cache resources
• Load balancing: balance service provider pressure and request forwarding
  • Random: Random algorithm, set a larger weight value for the server with excellent performance, there is a greater chance of random selection
  • RoundRobin: Rotation training, set the rotation training ratio according to the agreed weight
  • LeastActive: Least active, slower processing and poorer performance will receive fewer requests
  • ConsistentHash: Consistent hash, requests with the same parameters will be assigned to the same service provider
• Service degradation: system protection strategy, non-essential services are shut down or downgraded according to business scenarios
  • According to whether it is automated or not, it can be divided into automatic downgrade and manual downgrade
  • According to the function, it can be divided into read service degradation and write service degradation