Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

Why switch from PHP to Go

2025-01-17 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Internet Technology >

Share

Shulou(Shulou.com)06/02 Report--

What I want to share with you in this article is about why I want to switch from PHP to Go. The editor thinks it is very practical, so I share it with you. I hope you can get something after reading this article.

At first, we thought we should use the programming language we were familiar with, because we were a small team and had made two risky moves: switching our high-traffic gaming platform to micro-services and completely rebuilding Web applications.

In the end, however, we decided to give up PHP and switch to Go. In this article, we will explain why this is done. We will also share some views on databases in the micro-service architecture.

Microservice and PHP: the wrong match

The language we are familiar with is PHP, which drives our existing applications, and there are two vague reasons to use PHP:

We are familiar with PHP and its strange features, and the original program runs well, why should we give up?

There are a lot of PHP developers out there, and PHP can make it easier for our team to grow.

All this sounds correct, but when we clearly realized that PHP was really not the right choice for our case, we quickly gave up these ideas.

We are moving towards a micro-services architecture because we want these high-traffic infrastructure (2 million daily active users) to be scalable. In the long run, as we grow to 10 million or more users, our infrastructure should be able to expand accordingly.

PHP cannot meet these needs because:

The startup cost of PHP is very high. PHP was originally designed to run short-lifecycle scripts, so persistence is not its native feature. This means that every request, database connection, and class must be instantiated, which adds unnecessary overhead. Of course, there are ways to solve this, such as creating a connection pool through PHP-FPM or Apache, or binding C to get a long connection to Redis. However, because we need to pursue high performance, these dependencies make us begin to question whether PHP is an appropriate tool for this system.

Containerized PHP is a minefield. PHP requires the help of Nginx and PHP-FPM (or similar software) for process management and connection pool management. This means that for each microservice deployed, PHP-FPM and Nginx must run at the same time. This not only wastes resources, but also reduces efficiency. Optimizing PHP instances running on the server is also quite difficult because you need to be familiar with the configuration of PHP, PHP-FPM, and Nginx at the same time. We can't imagine the pain of configuring multiple PHP stacks on a resilient Kubernetes environment, and we don't even know what else is running on the same machine.

For microservices, the complexity lies in the architecture, because you are dealing with a complex interactive system. Now that we have decided to adopt a micro-service architecture, it is clear that the consumption caused by the wrong choice of programming language is not worth it.

What are the recruitment requirements? We find that this so-called request is meaningless to our present situation. Like microservices, we believe that developers should be programming language independent. We would rather hire a smart developer who is willing to learn a new programming language in order to get the job done, rather than an expert who insists on his own opinions. Therefore, in this sense, it is liberating for us to give up PHP.

Hug Go

We mainly prefer to use Node.js and Golang. After doing some research, we finally decided to give up Node and use Go.

So why use Go?

Performance: Go binaries generate a long-running process, which means that the startup cost of each request and database connection is low. This makes Go extremely fast when processing a large number of concurrent requests, because the Go language (goroutines module) is designed for network and multi-core computing.

Go can compile a small and portable binary file. This makes Go very suitable for use in Docker containers. It takes only a few seconds to deploy our Go containers because they are small (mostly 4-5MB) and because they are static links, there is no need for OS or runtime dependencies within the container. For example, when using Node Alpine Linux mirroring, our front-end container is approximately 55MB.

Go is of strict type. This makes internal communication in the code more reliable and helps catch exceptions during construction rather than during run time.

Go's tool chain is very large. Although tools are a concern for many programming languages, Google has solved this problem from the beginning, providing a large number of commonly used tools as part of language installation.

We also take into account the shortcomings of Go:

Go does not come with a dependency manager. But Google is working on this feature. Now, you can ask your supplier, or take a look at the Glide tool.

Too much formulaic code. This is the other side of Go's elegance and simplicity.

However, we must accept that using a Go program does take some effort, but it improves the quality of the code and allows us to keep track of how the code actually works.

This is not to say that all the code is written in Go. For server-side rendering, we use Node because it allows us to share code logic between the front end and the back end. We can also use Java to solve specific problems because it has been around for a long time and has a large number of libraries. We want to be able to use the most appropriate tool, and in most cases, Go is our first choice.

Explore NoSQL

When we started writing our first service in the go language, we also began to consider the choice of the database. We are used to the MySQL that used to serve us, but it often becomes a performance bottleneck.

In our traditional architecture, we use a lot of Redis for caching, and its performance is great because it effectively reduces the number of expensive connections. So when we start to explore the database in our new architecture, we need to explore NoSQL to see if these connections can be completely avoided.

We tried these two databases:

MongoDB: because we are very curious about whether file storage is a good solution for storing game data that contains a lot of metadata. However, the downside is that we have to manage it on Google Cloud, and according to the community, it doesn't scale well at all.

Cassandra: because it is a well-known extensible database and is used by high-traffic platforms Netflix and Reddit. Its advantage is that it is very fast and can expand linearly. However, we found that its content management was too complex. If you know how to query data, then Cassandra is fine. It is suitable for analysis services that contain a lot of data, but in an agile product design environment, products change frequently, and Cassandra is a powerful beast, which is too bulky for most cases.

Stick to SQL

We tend to build small, stand-alone services that can do the specified work and can be easily upgraded or replaced when needed.

That's why we decided to stick with MySQL as our default database. We have been using MySQL for many years and know how to design high-performance database scenarios. Although it cannot scale linearly, thanks to the modularity of the microservice architecture, the application load can be distributed across different microservices on different machines, and each microservice can access its own 32-core database machine and a different database read replica (Read Replicas).

To our delight, we haven't overdesigned it yet. If there is a service that does need Cassandra or other databases, then nothing can stop us from migrating the service.

So why MySQL? Mainly because it can be managed on Google Cloud, while we are pragmatic in terms of DevOps. We want to try Postgres because it is open source, has a strong community, and has improved a lot. Therefore, if the Alpha version is available on Google Cloud, we will also study it.

This is why we need to shift from PHP to Go. The editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Internet Technology

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report