reorder readme to get started first

rooneyvn · Oct 4, 2016 · 3442f76 · 3442f76
1 parent 3d922b8
commit 3442f76
Showing 1 changed file with 55 additions and 54 deletions.
diff --git a/README.md b/README.md
@@ -43,60 +43,6 @@ Join us to discuss, learn and contribute:
 
 By default go-micro only provides a few implementation of each interface at the core but it's completely pluggable. There's already dozens of plugins which are available at [github.com/micro/go-plugins](https://github.com/micro/go-plugins). Contributions are welcome!
 
-## How does it work?
-
-<p align="center">
-  <img src="go-micro.png" />
-</p>
-
-Go Micro is a framework that addresses the fundamental requirements to write microservices. 
-
-Let's dig into the core components.
-
-### Registry
-
-The registry provides a service discovery mechanism to resolve names to addresses. It can be backed by consul, etcd, zookeeper, dns, gossip, etc. 
-Services should register using the registry on startup and deregister on shutdown. Services can optionally provide an expiry TTL and reregister 
-on an interval to ensure liveness and that the service is cleaned up if it dies.
-
-### Selector
-
-The selector is a load balancing abstraction which builds on the registry. It allows services to be "filtered" using filter functions and "selected" 
-using a choice of algorithms such as random, roundrobin, leastconn, etc. The selector is leveraged by the Client when making requests. The client 
-will use the selector rather than the registry as it provides that built in mechanism of load balancing. 
-
-### Transport
-
-The transport is the interface for synchronous request/response communication between services. It's akin to the golang net package but provides 
-a higher level abstraction which allows us to switch out communication mechanisms e.g http, rabbitmq, websockets, NATS. The transport also 
-supports bidirectional streaming. This is powerful for client side push to the server.
-
-### Broker
-
-The broker provides an interface to a message broker for asynchronous pub/sub communication. This is one of the fundamental requirements of an event 
-driven architecture and microservices. By default we use an inbox style point to point HTTP system to minimise the number of dependencies required 
-to get started. However there are many message broker implementations available in go-plugins e.g RabbitMQ, NATS, NSQ, Google Cloud Pub Sub.
-
-### Codec
-
-The codec is used for encoding and decoding messages before transporting them across the wire. This could be json, protobuf, bson, msgpack, etc. 
-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. 
-It separates encoding from the client/server and provides a powerful method for integrating other systems such as gRPC, Vanadium, etc.
-
-### Server
-
-The server is the building block for writing a service. Here you can name your service, register request handlers, add middeware, etc. The service 
-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 
-other implementations. The server also allows you to define multiple codecs to serve different encoded messages.
-
-### Client
-
-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 
-for finding services by name using the registry, load balancing using the selector, making synchronous requests with the transport and asynchronous 
-messaging using the broker. 
-
-
-The  above components are combined at the top-level of micro as a **Service**.
 
 ## Getting Started
 
@@ -276,6 +222,61 @@ go run client.go
 Hello John
 ```
 
+## How does it work?
+
+<p align="center">
+  <img src="go-micro.png" />
+</p>
+
+Go Micro is a framework that addresses the fundamental requirements to write microservices. 
+
+Let's dig into the core components.
+
+### Registry
+
+The registry provides a service discovery mechanism to resolve names to addresses. It can be backed by consul, etcd, zookeeper, dns, gossip, etc. 
+Services should register using the registry on startup and deregister on shutdown. Services can optionally provide an expiry TTL and reregister 
+on an interval to ensure liveness and that the service is cleaned up if it dies.
+
+### Selector
+
+The selector is a load balancing abstraction which builds on the registry. It allows services to be "filtered" using filter functions and "selected" 
+using a choice of algorithms such as random, roundrobin, leastconn, etc. The selector is leveraged by the Client when making requests. The client 
+will use the selector rather than the registry as it provides that built in mechanism of load balancing. 
+
+### Transport
+
+The transport is the interface for synchronous request/response communication between services. It's akin to the golang net package but provides 
+a higher level abstraction which allows us to switch out communication mechanisms e.g http, rabbitmq, websockets, NATS. The transport also 
+supports bidirectional streaming. This is powerful for client side push to the server.
+
+### Broker
+
+The broker provides an interface to a message broker for asynchronous pub/sub communication. This is one of the fundamental requirements of an event 
+driven architecture and microservices. By default we use an inbox style point to point HTTP system to minimise the number of dependencies required 
+to get started. However there are many message broker implementations available in go-plugins e.g RabbitMQ, NATS, NSQ, Google Cloud Pub Sub.
+
+### Codec
+
+The codec is used for encoding and decoding messages before transporting them across the wire. This could be json, protobuf, bson, msgpack, etc. 
+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. 
+It separates encoding from the client/server and provides a powerful method for integrating other systems such as gRPC, Vanadium, etc.
+
+### Server
+
+The server is the building block for writing a service. Here you can name your service, register request handlers, add middeware, etc. The service 
+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 
+other implementations. The server also allows you to define multiple codecs to serve different encoded messages.
+
+### Client
+
+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 
+for finding services by name using the registry, load balancing using the selector, making synchronous requests with the transport and asynchronous 
+messaging using the broker. 
+
+
+The  above components are combined at the top-level of micro as a **Service**.
+
 ## Sponsors
 
 <a href="https://www.sixt.com"><img src="https://micro.mu/sixt_logo.png" width=150px height="auto" /></a>