github.com/tickoalcantara12/micro/v3@v3.0.0-20221007104245-9d75b9bcbab9/docs/v2/library/go-interfaces.md (about)

     1  ---
     2  title: Interfaces
     3  keywords: go-micro, interfaces
     4  tags: [go-micro, interfaces]
     5  sidebar: home_sidebar
     6  permalink: /go-interfaces
     7  summary: A description of the go-micro interfaces
     8  ---
     9  
    10  Go Micro is a pluggable framework which makes use of interfaces for its abstractions and building blocks. This enables 
    11  us to create strongly defined abstractions for underlying distributed systems concepts for which the implementations 
    12  can be swapped out.
    13  
    14  <p align="center">
    15    <img src="images/go-micro.svg" />
    16  </p>
    17  
    18  
    19  ## Interfaces
    20  
    21  Go micro is composed of the following list of interfaces;
    22  
    23  - **auth** - for authentication and authorization
    24  - **broker** for asynchronous messaging
    25  - **client** for high level requests/response and notification
    26  - **config** for dynamic configuration
    27  - **codec** for message encoding
    28  - **debug** for debugging; logs, trace, stats
    29  - **network** for multi-cloud networking
    30  - **registry** for service discovery
    31  - **runtime** - for running services
    32  - **selector** for load balancing
    33  - **server** for handling requests and notifications
    34  - **store** for data storage
    35  - **sync** for synchronisation, locking and leadership election
    36  - **transport** for synchronous communication
    37  - **tunnel** for establishing vpn tunnels
    38  
    39  An explanation for each interface can be found below
    40  
    41  TODO: fill the blanks
    42  
    43  ### Broker
    44  
    45  The broker provides an interface to a message broker for asynchronous pub/sub communication. This is one of the fundamental requirements of an event 
    46  driven architecture and microservices. By default we use an inbox style point to point HTTP system to minimise the number of dependencies required 
    47  to get started. However there are many message broker implementations available in go-plugins e.g RabbitMQ, NATS, NSQ, Google Cloud Pub Sub.
    48  
    49  ### Client
    50  
    51  The client provides an interface to make requests to services. Again like the server, it builds on the other packages to provide a unified interface 
    52  for finding services by name using the registry, load balancing using the selector, making synchronous requests with the transport and asynchronous 
    53  messaging using the broker. 
    54  
    55  The  above components are combined at the top-level of micro as a **Service**.
    56  
    57  We additionally provide some other components for distributed systems development:
    58  
    59  ### Codec
    60  
    61  The codec is used for encoding and decoding messages before transporting them across the wire. This could be json, protobuf, bson, msgpack, etc. 
    62  Where this differs from most other codecs is that we actually support the RPC format here as well. So we have JSON-RPC, PROTO-RPC, BSON-RPC, etc. 
    63  It separates encoding from the client/server and provides a powerful method for integrating other systems such as gRPC, Vanadium, etc.
    64  
    65  ### Config
    66  
    67  Config is an interface for dynamic config loading from any number of sources which can be combined and merged. Most systems actively require configuration 
    68  that changes independent of the code. Having a config interface which can dynamically load these values as needed is powerful. It supports 
    69  many different configuration formats also.
    70  
    71  ### Server
    72  
    73  The server is the building block for writing a service. Here you can name your service, register request handlers, add middeware, etc. The service 
    74  builds on the above packages to provide a unified interface for serving requests. The built in server is an RPC system. In the future there maybe 
    75  other implementations. The server also allows you to define multiple codecs to serve different encoded messages.
    76  
    77  ### Store
    78  
    79  The store is a simple key-value storage interface used to abstract away lightweight data storage. We're not trying to implement a full blown sql dialect 
    80  or storage, just simply the ability to hold state that would otherwise be lost in stateless services. They store interface will become a building block 
    81  for all forms of storage in the future.
    82  
    83  ### Registry
    84  
    85  The registry provides a service discovery mechanism to resolve names to addresses. It can be backed by consul, etcd, zookeeper, dns, gossip, etc. 
    86  Services should register using the registry on startup and deregister on shutdown. Services can optionally provide an expiry TTL and reregister 
    87  on an interval to ensure liveness and that the service is cleaned up if it dies.
    88  
    89  ### Selector
    90  
    91  The selector is a load balancing abstraction which builds on the registry. It allows services to be "filtered" using filter functions and "selected" 
    92  using a choice of algorithms such as random, roundrobin, leastconn, etc. The selector is leveraged by the Client when making requests. The client 
    93  will use the selector rather than the registry as it provides that built in mechanism of load balancing. 
    94  
    95  ### Transport
    96  
    97  The transport is the interface for synchronous request/response communication between services. It's akin to the golang net package but provides 
    98  a higher level abstraction which allows us to switch out communication mechanisms e.g http, rabbitmq, websockets, NATS. The transport also 
    99  supports bidirectional streaming. This is powerful for client side push to the server.
   100  
   101