Yes, to better support microservices, we migrated from PHP to go

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

At first, we thought sticking to a familiar language was a responsible thing-we were a small team, but we took two risks: switching to microservices and completely rewriting our WEB applications (high-traffic gaming platforms).

But eventually we decided to abandon the PHP hug Go, and I'll explain why and share some ideas about databases in our microservices architecture.

MicroServices and PHP: conceptual mismatch

The language we are familiar with is PHP, which supports our existing applications, and there are two vague arguments that can support us to continue this:

• we are familiar with PHP, which develops quick questions. why give up what's useful to us?

• There are many PHP developers on the market. choosing PHP makes it easier for us to expand our team.

That sounds reasonable, but when we know that PHP is really not our right choice, we quickly give up on these ideas.

We are migrating to a microservices architecture because we want our high-traffic infrastructure infrastructure (2 million days of live users) to scale better. In the long run, as we move towards 10 million (and more) daily users, and change every day and hour (the translator notes: Scaling and shrinking): As the rest of the country is resting or during the day, our infrastructure should be scaled to scale.

The main reasons PHP does not fit us:

1. PHP has a high startup cost

PHP has been designed to (or become) a script that runs short commands, so persistence is not an appropriate feature for the language to support. This means that for each request, both the database connection and the class must be re-instantiated, which increases the unnecessary latency overhead.

Of course, the familiar reader knows that there are solutions, such as connection pooling or C binding through PHP-FPM or Apache, that can support persistent connections with Redis.

However, because of our pursuit of high performance, these dependencies have given us some doubts about choosing PHP as the right tool.

2, containerized PHP is a minefield

PHP requires Nginx and PHP-FPM (or similar tools) to implement functions such as process and connection pool management. This means that for each deployed microservices, PHP-FPM and Nginx must also run together. This wastes resources and reduces the efficiency of expansion.

There are also problems with optimizing the configuration. The optimization of single PHP instances is already very big, because we need to understand and configure the PHP,PHP-FPM and Nginx stack, we can not imagine the end of the flexible Kubernetes environment to configure the pain of multiple PHP stacks, you do not know what services are running on the same machine.

The complexity of the microservices in the architecture: you are dealing with a complex system that consists of simple services and interacts with one another. Since we are committed to this architecture, it is not worth the effort to add more long-term overhead and conceptual errors because of the language.

And what about hiring? We found it to be ineffective for our situation. Like MicroServices, we think developers should be language-independent. Instead of using a language expert who insists on how to do things, we prefer to hire a smart developer to learn a new language to do the job. In this sense, the removal of PHP actually gives us real freedom.

To Go forward

The two main languages we prefer are node. js and Golang. We did some research and decided to turn to Go rather than Node.

Why Go?

performance . Binary to start a long-running daemon, which means that the startup cost for each request and persistent connection is low. Go (including goroutine) is inherently designed for network and multicore environments, making it ultra-fast and efficient in handling large amounts of concurrent requests.

Go can be compiled into a small, portable binary file . This makes it ideal for use in Docker containers. Deploying our Go containers takes only a few seconds because they are small in size (mostly only 4-5mb), and because of the static link, there is no need for OS or runtime dependencies within the container. As a reference, when using the Node Alpine image, our front-end container needs to be about 55MB.

Go is type-strict . This makes internal communication in your code more reliable. It also helps to catch problems during compilation, not during runtime.

Go has a very good tool chain . Although the tool is a problem in many languages, Google decided to solve the problem from the start, providing a number of commonly used tools as part of the language installation package.

Of course we also consider these drawbacks of go:

• Go does not come with a dependency management tool. The official team is working on this, which is likely to be very useful when the official tools are released. Now you can check your vendors, or use tools such as Glide.

• more code. It is the elegant and simple opposite of Go.

However, we choose to accept this: using Go does require some effort, but it produces high-quality code.

That's not to say we use go everywhere. For server-side rendering, we chose Nodebecause it allows us to share logic between the front-end and back-end. We also use Java to solve specific problems because Java has been around for a long time and has a lot of class libraries.

we want to use the most appropriate tool for each scenario , i.e. Go will be our preferred tool for most cases.

Big Gopher (gyga8k)

Evaluate NoSQL

When we started writing our first service with Go, we also thought about the database at the same time. We are accustomed to using MySQL, which used to work well, but it is often a performance bottleneck.

In our traditional technology stack, we've also used a lot of Redis for caching, which is great for performance because it effectively reduces the access pressure on database join queries.

So when we start database sizing in the new technology stack, it's very important to evaluate NoSQL to see if we can completely avoid these join queries.

We evaluated two databases:

MongoDB -We are curious to see if a document database can be used to store large amounts of metadata in the game. Of course the trouble is that we have to use it in Google Cloud, which, according to the community, doesn't scale well. We try to avoid complex DevOps work, so MongoDB is out.

Cassandra -It is a known extensible database and is used by some large high-traffic platforms Netflix and Reddit. The features we like are: It's very fast and supports linear scaling. However, we find management too complex.

If you know exactly how to query your data, Cassandra is a great fit. This may be the case for analytics services with a large amount of data, but in an agile product design development environment, with the development of the product, the user adaptability changes, Cassandra although strong, but for our small team such as difficult to control .

Continue to dance with SQL

We are moving closer to the concept of microservices and are more convinced of the idea of building small, standalone services that perform specific tasks and can be easily upgraded or replaced when needed.

so we still insist on using MySQL as our default database. we have been using MySQL for many years and know how to design high-performance database schemas. Although it does not support native linear scaling, it is now not a big problem: because of the modularity of the MicroServices architecture, application load is distributed across many different microservices of machines. and each micro-server can access its own 32-core database machine and several read-only from the library, this way can continue to go a long way.

We are very happy, and now we are not over-engineered. If you have a service that requires Cassandra or other databases, we can also easily migrate the service.

So why Choose MySQL? Now it's mostly because it's easy to manage on Google Cloud, and we're pragmatic about DevOps.

We also consider trying to Postgres, because it is open source, there is a strong community, and apparently has been running for many years. So, depending on the future Alpha version of Google Cloud, we may also try to Postgres.

The author adds:

Reddit Many netizens pointed out, we have the PHP start cost misunderstanding. Although our views still stand, we have cleared this section for the sake of accuracy.

Thanks also Casper van Wezel for his contribution to this article. Please leave a message, English readers can click to read the original and the original author interaction.

RELATED links:

• https://blog.poki.com/from-monolith-to-microservices-b16bae1d6c9d

• https://blog.poki.com/rebuilding-a-web-platform-for-30m-users-90467b0b8293

• Https://golang.org/doc/faq#creating_a_new_language

• http://www.craigkerstiens.com/2017/04/30/why-postgres-five-years-later/

• https://blog.poki.com/rebuilding-a-web-platform-for-30m-users-90467b0b8293

• https://blog.poki.com/from-monolith-to-microservices-b16bae1d6c9d#.txez7ug8f

Recommended Reading

• How to use go to achieve a similar drop of uber-like network car software (including source code)

• A big contrast between go and Java garbage collection algorithms in the eyes of an expert
  

• How we use Cassandra to store hundreds of millions of online data per day

• Why does MongoDB 3.0 hang up? Wiredtiger implementation: An analysis caused by a LRU cache deep pit
  

This article was first published in the Poki Project blog, by Jesse translation, reproduced please indicate the source, technical original and architectural practice articles, welcome to the public number menu "Contact us" for contributions.