Go was born into a world where multiple processors are the norm and the ability of an application to scale across those processors is critical. Go meets this challenge by including language-level support for concurrency. However, the landscape continues to evolve and languages are now being challenged to connect multiple applications in a distributed ecosystem. This course takes you through the implementation of such a system using as much core Go as possible. While some libraries are used to access message queues, etc., the distributed nature of the resulting suite of applications will be composed of as much core Go as possible with little or no support from other third-party libraries.
Michael Van Sickle is an application architect in Akron, Ohio.
He is a mechanical engineer by training and a software engineer by choice.
He is passionate about learning new programming languages and user
Course Overview Hi everyone. My name is Michael Van Sickle, and welcome to my course: Building Distributed Applications with Go. I'm a software architect at Sterling Jewelers. I started out as a mechanical engineer, but have been programming throughout my entire career. A few years ago, I changed over to software development as my full-time occupation. Right around that same time, I learned about the Go language and fell in love with its simplicity and power. One of Go's great strengths, is its built-in support for concurrent programming, which makes it much simpler to take full advantage of today's multi-core processors. In this course, we're going to learn how to build a distributed application with Go. We're going to take a code-heavy approach without the support of any more third-party libraries than we can help. Some of the major topics that we will cover include: an introduction to what distributed programming is; an introduction to RabbitMQ, including how to install and monitor it; how to publish and subscribe to messages in a variety of different messaging patterns; how to use WebSockets to provide real time updates to a web-based client. By the end of this course, you'll know how to use Rabbit and integrate it into a Go application. Along the way, you'll also gain a perspective on one way to build a distributed application. There are, of course, many other approaches to solving this problem, but this course will give you a starting point to build upon. Before beginning the course, you should be familiar with the Go language itself and the basics of Web Application Development with Go. This is an advanced level course, so I'm not going to take the time to break syntax down for you. I hope you'll join me on this journey to learn Go with the Building Distributed Applications with Go course at Pluralsight.
Introduction Hello. My name is Michael Van Sickle. Welcome to this course, where we're going to be using Go to build a distributed application. What do I mean by distributed? Well, Wikipedia defines a distributed system as one as which its components communicate over a network via message-passing. We'll certainly be doing our fair share of that, but I'm going to go a bit further. Many distributed applications are made up of ecosystems of smaller applications that coordinate with each other to deliver the desired functionality. By making the application out of smaller ones, it's more easily scaled. That's what I want to build with you over the next few hours. A distributed application made up of multiple, smaller applications working together. Let me stop there for a bit, since I'm getting ahead of myself. Before we dive in and start building, we have some things to go over first. First, I want to let you know who I think you are, and what you know. This is an advanced level course, and, while you don't need to know how to write your own Go compiler, there are some assumptions that I'm going to be making about what you know. Next, we'll get into the course layout. That part's going to feel an awful lot like an application design review, because that's what it is. Each step of building this application is going to introduce new challenges for us to solve. Finally, I'd like to give an overview of the development environment that I'm going to be using. If you're in my target audience, then you probably already have a stack that you're comfortable with. Just in case, I'll show you what I'm working with.
Introduction to RabbitMQ Hello, welcome back to this course, where we're learning about creating distributed applications with Go. In the last module, we talked about the basic architecture of the application that we're going to be building. As you'll recall, I mentioned that we'll be using RabbitMQ as a message broker to decouple the sensors that are going to be generating messages from the coordinators that are going to consume that data. In this module, we're going to spend some time with RabbitMQ in order to make sure that we're all in the same page with what it is and how it works. First, I want to take a moment to make sure that we're all in the same page when I use the term message broker, and how that is different from a simple message queue provider. Next, I'll go through the installation and usage of Rabbit itself. I'll be the first to admit that I'm not an expert in this area, so we won't be going too deep here. I'm just going to show you enough to get things running with the default configuration. Even at this high level though, there are several things that are going to be useful to know about. Finally, I'm going to wrap up by exercising Rabbit and at the same time, introducing the basic steps of integrating it into a Go application. We'll learn how to publish and consume messages and, while we're at it, get an idea about the bandwidth that our basic set up is going to have. Okay, let's get started by talking about message brokers.
Publishing Messages to a Message Queue Hello, welcome back. In the last module, we talked about RabbitMQ and saw how to create a simple Go application that could both publish messages to an exchange and subscribe to messages that came through a queue. Now it's time to start applying that knowledge to our demo application. In this module, we're going to be creating the sensor applications that will feed temperature and pressure information about our power plant into the system. This is going to break down into two basic steps. First, I'm going to implement the sensor itself. In a real-world application, this would involve integrating with the sensor's API to get the data that it's publishing. In our demo, things are going to be a bit different. I'm going to create a small application that can generate realistic data to feed into the system. Next, we'll go through the steps to publish those readings to a queue. Well, to be more precise, we'll publish to an exchange, and that exchange will forward the readings onto a queue. Additionally, when I design this application, I chose to have each sensor use its own routing key so we have to start to rough out a method to advertise when a new data provider becomes active. Now let's see how we're going to build these mock sensors out.
Using Messages to Generate Events Hello, and welcome back. I hope that you're ready for more code because I've got a lot of that for you in this module. In the last one, we built out the sensors and got them to broadcast their messages into a message broker powered by RabbitMQ. Let's go over what I have in store for you this time. First up, we're going to build the coordinators that are going to receive messages from the queues that the sensors are publishing to. This is going to take a bit of work on our part since the queues are being dynamically created and so we're going to have to set up a receiver every time one is created. After that, I want to build an EventAggregator that will translate the disparate data streams that are coming from the message broker into a set of events that downstream consumers can use. While this isn't a mandatory part of distributed application development, I really like how the event pattern allows the data sources and consumers to be decoupled from each other in a highly concurrent system like we're working with. Finally, we're going to have to address a bit of an issue that has crept up on us. In the current implementation, the sensors broadcast their presence when they start up, but there's no way to discover sensors that were active before the coordinators were started. We'll address that issue at the end of this module. Now let's get started by making a small change to our sensors that will make it easier to set up multiple coordinators.