為何要從PHP轉(zhuǎn)向Go

本篇文章給大家分享的是有關(guān)為何要從PHP轉(zhuǎn)向Go，小編覺得挺實(shí)用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

在最初的時(shí)候，我們自認(rèn)為應(yīng)該使用自己熟悉的編程語言，因?yàn)槲覀兪且粋€(gè)小團(tuán)隊(duì)，而且已經(jīng)做了兩項(xiàng)冒險(xiǎn)的舉動(dòng)：將我們的大流量游戲平臺(tái)切換到微服務(wù)和完全重建Web應(yīng)用程序。

不過，最終，我們還是決定放棄PHP，轉(zhuǎn)向Go。在這篇文章中，我們將解釋為什么要這樣做。我們還將分享一些微服務(wù)架構(gòu)中有關(guān)數(shù)據(jù)庫(kù)的觀點(diǎn)。

微服務(wù)和PHP：錯(cuò)誤的搭配

我們熟悉的語言是PHP，它驅(qū)動(dòng)著我們現(xiàn)有的應(yīng)用程序，有兩個(gè)模糊的理由支撐著我們使用PHP：

• 我們熟悉PHP和它的怪特性，而且原來的程序運(yùn)行得很好，我們?yōu)槭裁匆艞墸?/p>

• 外面有很多的PHP開發(fā)人員，PHP可以讓我們的團(tuán)隊(duì)更容易地成長(zhǎng)起來。

這些聽起來都很正確，但是當(dāng)我們清楚地認(rèn)識(shí)到PHP真的不是我們這個(gè)案例的正確選擇時(shí)，我們很快就放棄了這些想法。

我們正在向著微服務(wù)架構(gòu)遷移，因?yàn)槲覀兿Ｍ@些大流量的基礎(chǔ)架構(gòu)（每日200萬活躍用戶）具備可擴(kuò)展性。從長(zhǎng)遠(yuǎn)來看，隨著我們向1000萬甚至更多用戶發(fā)展的時(shí)候，我們的基礎(chǔ)設(shè)施也應(yīng)該能相應(yīng)地進(jìn)行擴(kuò)大。

PHP無法滿足這些需求，因?yàn)椋?/p>

PHP的啟動(dòng)成本很高。 PHP一開始是為短生命周期腳本的運(yùn)行而設(shè)計(jì)的，因此持久性并不是其原生特性。這意味著對(duì)于每個(gè)請(qǐng)求、數(shù)據(jù)庫(kù)連接和類都必須實(shí)例化，這增加了不必要的開銷。當(dāng)然，這也是有辦法解決的，例如通過PHP-FPM或Apache來創(chuàng)建連接池，或者綁定C以獲得與Redis的長(zhǎng)連接。但是，由于我們需要追求高性能，所以這些依賴讓我們開始質(zhì)疑PHP對(duì)于這個(gè)系統(tǒng)來說是否是一個(gè)合適的工具。

容器化的PHP是一個(gè)雷區(qū)。 PHP需要借助Nginx和PHP-FPM（或類似的軟件）來進(jìn)行進(jìn)程管理和連接池管理。這意味著對(duì)于部署的每個(gè)微服務(wù)來說，PHP-FPM和Nginx必須同時(shí)運(yùn)行。這既浪費(fèi)了資源，又降低了效率。對(duì)運(yùn)行在服務(wù)器上的PHP實(shí)例進(jìn)行優(yōu)化也是相當(dāng)困難的，因?yàn)槟阈枰瑫r(shí)熟悉PHP、PHP-FPM和Nginx的配置。我們無法想象在彈性Kubernetes環(huán)境上配置多個(gè)PHP棧的痛苦，我們甚至不知道在這同一臺(tái)機(jī)器上還運(yùn)行了其他什么東西。

對(duì)微服務(wù)來說，其復(fù)雜性存在于架構(gòu)中，因?yàn)槟阏谔幚淼氖且粋€(gè)復(fù)雜的交互系統(tǒng)。既然我們已經(jīng)確定采用微服務(wù)架構(gòu)，那么因?yàn)殄e(cuò)誤的選擇了編程語言導(dǎo)致的消耗顯然就不值得。

招聘的要求是什么？我們發(fā)現(xiàn)這個(gè)所謂的要求對(duì)于我們現(xiàn)在這種情況是毫無意義的。像微服務(wù)一樣，我們認(rèn)為開發(fā)人員應(yīng)該是編程語言無關(guān)的。我們寧愿聘請(qǐng)一位聰明的并愿意為了完成工作而學(xué)習(xí)新的編程語言的開發(fā)人員，而不是一位堅(jiān)持己見的專家。因此，從這個(gè)意義上來說，放棄PHP對(duì)我們來說是一種解放。

擁抱Go

我們主要偏向使用Node.js和Golang這兩種語言。在做了一些研究之后，我們最后決定放棄Node，使用Go。

那么為什么要使用Go呢？

性能： Go的二進(jìn)制文件會(huì)生成一個(gè)長(zhǎng)時(shí)間運(yùn)行的進(jìn)程，這意味著每個(gè)請(qǐng)求和數(shù)據(jù)庫(kù)連接的啟動(dòng)成本很低。這使得Go在處理大量的并發(fā)請(qǐng)求時(shí)能保證極快的速度，因?yàn)镚o語言（goroutines模塊）專為網(wǎng)絡(luò)和多核計(jì)算而設(shè)計(jì)。

Go可以編譯出一個(gè)小巧便攜的二進(jìn)制文件。這使得Go非常適合在Docker容器中使用。部署我們的Go容器只需幾秒鐘，因?yàn)樗鼈兊捏w積很小（大多數(shù)是4-5MB），并且由于是靜態(tài)鏈接，因此在容器內(nèi)不需要OS或運(yùn)行時(shí)依賴。例如，當(dāng)使用Node Alpine Linux鏡像時(shí)，我們的前端容器大約為55MB。

Go是類型嚴(yán)格的。這讓代碼中的內(nèi)部通信更為可靠，也有助于在構(gòu)建期間捕獲異常，而不是在運(yùn)行期間。

Go的工具鏈的規(guī)模很大。雖然工具是很多編程語言關(guān)注的問題，但Google從一開始就解決了這個(gè)問題，他提供了大量常用的工具作為語言安裝時(shí)的一部分。

我們也考慮到Go有這些缺點(diǎn)：

• Go不附帶依賴管理器。不過Google正在努力實(shí)現(xiàn)這個(gè)功能?，F(xiàn)在，你可以問一下你的供應(yīng)商，或者看一下Glide這個(gè)工具。

• 太多的公式化代碼。這是Go優(yōu)雅和簡(jiǎn)單的另一面。

然而，我們必須接受這一點(diǎn)：用Go程序確實(shí)需要花上一些功夫，但它能提高代碼質(zhì)量，并讓我們能夠時(shí)刻知道代碼實(shí)際是如何運(yùn)行的。

這并不是說所有的代碼我們都用Go來寫。對(duì)于服務(wù)器端渲染，我們使用Node，因?yàn)樗试S我們?cè)谇岸撕秃蠖酥g共用代碼邏輯。我們也可以使用Java來解決特定的問題，因?yàn)樗呀?jīng)存在了很長(zhǎng)時(shí)間，并且擁有大量的庫(kù)。我們希望能使用最合適的工具，對(duì)于大多數(shù)情況而言，Go是我們的首選。

探索NoSQL

當(dāng)我們開始使用Go語言來編寫我們的第一個(gè)服務(wù)時(shí)，我們也開始考慮數(shù)據(jù)庫(kù)的選擇。我們習(xí)慣了過去為我們服務(wù)的MySQL，但它經(jīng)常會(huì)成為性能的瓶頸。

在我們的傳統(tǒng)架構(gòu)中，我們使用了大量的Redis來進(jìn)行緩存，它的性能非常棒，因?yàn)樗行У販p少了昂貴的連接數(shù)量。所以當(dāng)我們開始在我們的新架構(gòu)中探索數(shù)據(jù)庫(kù)時(shí)，我們要探索一下NoSQL，來看看是否可以完全避免這些連接。

我們?cè)囉昧诉@兩個(gè)數(shù)據(jù)庫(kù)：

MongoDB：因?yàn)槲覀兎浅：闷鎸?duì)于存儲(chǔ)包含大量元數(shù)據(jù)的游戲數(shù)據(jù)而言，文件存儲(chǔ)是否是一個(gè)好的解決方案。但是，缺點(diǎn)是：我們必須在Google Cloud上管理它，而且根據(jù)社區(qū)所說，它根本不能很好地進(jìn)行擴(kuò)展。

Cassandra：因?yàn)樗且粋€(gè)大家熟知的可以擴(kuò)展的數(shù)據(jù)庫(kù)，并被大流量平臺(tái)Netflix和Reddit所使用。它的優(yōu)點(diǎn)是：速度非?？欤芫€性擴(kuò)展。不過，我們發(fā)現(xiàn)它的內(nèi)容管理太復(fù)雜了。如果你知道該如何查詢數(shù)據(jù)，那么Cassandra是挺好的。它適用于包含大量數(shù)據(jù)的分析服務(wù)，但是在敏捷產(chǎn)品設(shè)計(jì)環(huán)境中，產(chǎn)品變化頻繁，Cassandra就是一個(gè)強(qiáng)大的野獸，對(duì)于大多數(shù)情況而言它太笨重了。

堅(jiān)守SQL

我們傾向于構(gòu)建小型而又獨(dú)立的服務(wù)，這些服務(wù)可以完成指定的工作，并且在需要的時(shí)候可以很輕松地進(jìn)行升級(jí)或更換。

這就是為什么我們決定堅(jiān)持使用MySQL作為我們的默認(rèn)數(shù)據(jù)庫(kù)的原因。我們已經(jīng)使用MySQL很多年了，知道如何設(shè)計(jì)高性能的數(shù)據(jù)庫(kù)方案。雖然它不能線性擴(kuò)展，但現(xiàn)在還好，得益于微服務(wù)架構(gòu)的模塊化特性，應(yīng)用程序負(fù)載可以分布在不同機(jī)器的不同微服務(wù)上，并且每個(gè)微服務(wù)都可以訪問自己的32核數(shù)據(jù)庫(kù)機(jī)器和不同的數(shù)據(jù)庫(kù)讀副本（Read Replicas）。

讓我們高興的是，至今我們還沒有過度設(shè)計(jì)。如果有某個(gè)服務(wù)確實(shí)需要Cassandra或其他數(shù)據(jù)庫(kù)的話，那么沒有什么可以阻止我們遷移這個(gè)服務(wù)。

那么為什么選用MySQL？主要是因?yàn)樗梢栽贕oogle Cloud上進(jìn)行管理，而在DevOps方面我們是務(wù)實(shí)的。我們想嘗試試用Postgres，因?yàn)樗情_源的，有一個(gè)強(qiáng)大的社區(qū)，并且已經(jīng)改進(jìn)了很多。因此，如果Google Cloud上有了Alpha版本，我們也會(huì)研究一下。

以上就是為何要從PHP轉(zhuǎn)向Go，小編相信有部分知識(shí)點(diǎn)可能是我們?nèi)粘９ぷ鲿?huì)見到或用到的。希望你能通過這篇文章學(xué)到更多知識(shí)。更多詳情敬請(qǐng)關(guān)注億速云行業(yè)資訊頻道。