"Translate" Go in Heroku

This is a creation in Article, where the information may have evolved or changed.

Recently I've seen many friends asking a similar question: What can Go do? Does Go have a practical application? Dare not use Go in the actual project ...

Just right, Golang's blog published an article by Heroku's two system engineers about the use of the Go language in their distributed systems.

Do you remember Doozer? Yes, I had a translation before. High-speed data synchronization server--doozer. It seems to be the masterpiece of this group of excellent engineers. They are the pioneers of the Go language application, and indeed deserve our attention to their work, their experience, and their tribute to these excellent engineers!

The original is here: http://blog.golang.org/2011/04/go-at-heroku.html
——————————-translation split line for tribute ——————————-
This week's blog content was written by Heroku, a systems engineering engineer, Keith Rarick and Blake Mizerany. In their own words, they "eat, drink, sleep on a distributed system". Here we discuss some of the experiences they apply to Go.

A huge problem in building a distributed system is the collaboration between physical servers. Each server needs to be aware of the various situations on the system as a whole. These key data include locks, configuration data, and so on, which must be consistent and available even in the event of a data store exception. Therefore, there is a need for a data store with absolutely consistent safeguards. The solution to this problem is Doozer, a new, consistent, high-availability data store written with Go.

The core of Doozer is Paxos, a protocol family that solves the problem of the consistency of unreliable nodes in an unreliable network. The essence of Paxos is to run a fault-tolerant system, which is notoriously difficult to implement. Even if there are examples on the web, they are both complex and difficult to understand, even if they are simplified for instructional purposes. The reputation of existing production systems is even worse.

Fortunately, the Go native concurrency mechanism makes this task much simpler. Paxos is defined on a set of concurrent processes that are not dependent on a message-passing communication. In Doozer, these processes are implemented by Goroutine, and communication is done by the channel. Similarly, as with the garbage collection mechanism that improved malloc and free, we found that Goroutine and channel improved the lock-based concurrency. These tools allow us to avoid complications and keep our minds focused on the core issues. We were quite surprised by the number of lines of code that were so small that we finished what was always considered hard to achieve.

Go's standard pack is another great success on the Doozer. The Go team is quite practical about what goes into the standard package, and we quickly find that the WebSocket package is very practical. When we work on data storage, we need some simple ways to observe and visualize the activity. With the WebSocket package, Keith can add a Web interface to the bike training at home without having to rely on any extra stuff. This really proves how good it is to glue systems and applications with Go.

Our favorite productivity boost comes from the Go Code formatting tool: Gofmt. We never write curly braces, tab or space, or should we argue about Zishing value notation. We all agree with the GOFMT default output.

The simplicity of developing the doozer is quite satisfying. The static connection of Go means that the Doozer is an unordered additional dependency; it only has one file copied to any machine, and then immediately runs and joins the cluster running Doozer.

In the end, Go's simple philosophy of design and our understanding of software engineering are wildly consistent. Just like the Go team, we have a practical perspective on what features can go into Doozer. We repeated deliberation to change what we already have instead of adding a new feature. On this point, Go is quite a match for Doozer.

We have some ideas for using Go in future projects. Doozer is just the beginning for a big system.