Building Microservices with Go

Nic Jackson

• Éditeur: Packt Publishing
• Année: 2017
• ISBN:
  9781786469793
• Édition: 1
• Sujet: Computer Science
• Sous-sujet: Programming in Java

Your one-stop guide to the common patterns and practices, showing you how to apply these using the Go programming languageAbout This Book• This short, concise, and practical guide is packed with real-world examples of building microservices with Go• It is easy to read and will benefit smaller teams who want to extend the functionality of their existing systems• Using this practical approach will save your money in terms of maintaining a monolithic architecture and demonstrate capabilities in ease of useWho This Book Is ForYou should have a working knowledge of programming in Go, including writing and compiling basic applications. However, no knowledge of RESTful architecture, microservices, or web services is expected. If you are looking to apply techniques to your own projects, taking your first steps into microservice architecture, this book is for you.What You Will Learn• Plan a microservice architecture and design a microservice• Write a microservice with a RESTful API and a database• Understand the common idioms and common patterns in microservices architecture• Leverage tools and automation that helps microservices become horizontally scalable• Get a grounding in containerization with Docker and Docker-Compose, which will greatly accelerate your development lifecycle• Manage and secure Microservices at scale with monitoring, logging, service discovery, and automation• Test microservices and integrate API tests in GoIn DetailMicroservice architecture is sweeping the world as the de facto pattern to build web-based applications. Golang is a language particularly well suited to building them. Its strong community, encouragement of idiomatic style, and statically-linked binary artifacts make integrating it with other technologies and managing microservices at scale consistent and intuitive. This book will teach you the common patterns and practices, showing you how to apply these using the Go programming language.It will teach you the fundamental concepts of architectural design and RESTful communication, and show you patterns that provide manageable code that is supportable in development and at scale in production. We will provide you with examples on how to put these concepts and patterns into practice with Go.Whether you are planning a new application or working in an existing monolith, this book will explain and illustrate with practical examples how teams of all sizes can start solving problems with microservices. It will help you understand Docker and Docker-Compose and how it can be used to isolate microservice dependencies and build environments. We finish off by showing you various techniques to monitor, test, and secure your microservices.By the end, you will know the benefits of system resilience of a microservice and the advantages of Go stack.Style and approachThe step-by-step tutorial focuses on building microservices. Each chapter expands upon the previous one, teaching you the main skills and techniques required to be a successful microservice practitioner.

Designing a Great API

Regardless of whether you are experienced in building APIs and microservices and looking for the techniques on how you can apply them with Go or you are completely new to the world of microservices, it is worth spending the time to read this chapter.

Writing an API contract feels part art, part science and, when you discuss your design with other engineers, you will most certainly agree to disagree, not to the level of tabs versus spaces, but there is certainly something personal about API contracts.

In this chapter, we will look at the two most popular options, which are RESTful and RPC. We will examine the semantics of each approach, which will equip you with the knowledge to argue your case when the inevitable discussion (read argument) occurs. Choosing between REST or RPC may be entirely down to your current environment. If you currently have services running that implement a RESTful approach, then I suggest you stick with it, likewise if you now use RPC. One thing I would suggest is that you read the entire chapter to understand the semantics, pros, and cons of each approach.

RESTful APIs

The term REST was suggested by Roy Fielding in his Ph.D. dissertation in the year 2000. It stands for Representational State Transfer and is described as:

"REST emphasizes scalability of component interactions, generality of interfaces, independent deployment of components, and intermediary components to reduce interaction latency, enforce security and encapsulate legacy systems."

Having an API that conforms to the REST principles is what makes it RESTful.

URIs

One of the main components in the HTTP protocol is a URI. URI stands for Uniform Resource Identifiers and is the method by which you will access the API. You may be asking what the difference between a URI and a URL (Uniform Resource Locator) is? When I started to write this chapter, I wondered about this myself and did what any self-respecting developer would do, which is to head over to Stack Overflow. Unfortunately, my confusion only grew as there were lots of detailed answers, none of which I found particularly enlightening. Time to head over to the inner circle of hell also known as W3C standards to look up the RFC for the official answer.

In short, there is no difference, a URL is a URI that identifies a resource by its network location, and it is acceptable to interchange the terms when describing a resource entirely.

The clarification document published back in 2001 (http://www.w3.org/TR/uri-clarification) goes on to explain that in the early to mid-90s there was an assumption that an identifier is cast into one or two classes. An identifier might specify the location of a resource (URL) or its name (Uniform Resource Name URN) independent of location. A URI could either be a URL or a URN. Using this example, http:// would be a URL scheme and isbn: a URN scheme. However, this changed over time and the importance of the additional level of hierarchy lessened. The view changed that an individual scheme does not need to be cast into one of a discrete set of types.

The conventional approach is that http: is a URI scheme and urn: is also a URI scheme. URNs take the form urn:isbn:n-nn-nnnnnn-n, isbn: is a URN namespace identifier, not a URN scheme or a URI scheme.

Following this view, the term URL does not refer to a formal partition of URI space rather, URL is an informal concept; a URL is a type of URI that identifies a resource via its network location.

For the rest of this book, we will use the term URI and when we do we will be talking about a method to access a resource that is running on a remote server.

URI format

RFC 3986, which was published in 2005 https://www.ietf.org/rfc/rfc3986.txt, defines the format that makes valid URIs:

 URI = scheme "://" authority "/" path [ "?" query] ["#" fragment"] 
URI = http://myserver.com/mypath?query=1#document 

We are will use the path element in order to locate an endpoint that is running on our server. In a REST endpoint, this can contain parameters as well as a document location. The query string is equally important, as you will use this to pass parameters such as page number or ordering to control the data that is returned.

Some general rules for URI formatting:

• A forward slash / is used to indicate a hierarchical relationship between resources
• A trailing forward slash / should not be included in URIs
• Hyphens - should be used to improve readability
• Underscores _ should not be used in URIs
• Lowercase letters are preferred as case sensitivity is a differentiator in the path part of a URI

The concept behind many of the rules is that a URI should be easy to read and to construct. It should also be consistent in the way that it is built so you should follow the same taxonomy for all the endpoints in your API.

URI path design for REST services

Paths are broken into documents, collections, stores, and controllers.

Collections

A collection is a directory of resources typically broken by parameters to access an individual document. For example:

 GET /cats -> All cats in the collection 
GET /cats/1 -> Single document for a cat 1 

When defining a collection, we should always use a plural noun such as cats or people for the collection name.

Documents

A document is a resource pointing to a single object, similar to a row in a database. It has the ability to have child resources that may be both sub-documents or collections. For example:

 GET /cats/1 -> Single document for cat 1 
GET /cats/1/kittens -> All kittens belonging to cat 1 
GET /cats/1/kittens/1 -> Kitten 1 for cat 1 

Controller

A controller resource is like a procedure, this is typically used when a resource cannot be mapped to standard CRUD (create, retrieve, update, and delete) functions.

The names for controllers appear as the last segment in a URI path with no child resources. If the controller requires parameters, these would typically be included in the query string:

 POST /cats/1/feed -> Feed cat 1 
POST /cats/1/feed?food=fish ->Feed cat 1 a fish 

When defining a controller name we should always use a verb. A verb is a word that indicates an action or a state of being, such as feed or send.

Store

A store is a client-managed resource repository, it allows the client to add, retrieve, and delete resources. Unlike a collection, a store will never generate a new URI it will use the one specified by the client. Take a look at the following ex...