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

創(chuàng)新互聯(lián)自2013年創(chuàng)立以來(lái)，是專(zhuān)業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項(xiàng)目成都做網(wǎng)站、網(wǎng)站建設(shè)網(wǎng)站策劃，項(xiàng)目實(shí)施與項(xiàng)目整合能力。我們以讓每一個(gè)夢(mèng)想脫穎而出為使命，1280元洛寧做網(wǎng)站,已為上家服務(wù),為洛寧各地企業(yè)和個(gè)人服務(wù),聯(lián)系電話:18980820575

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

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

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

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

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

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

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

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

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

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

容器化的PHP是一個(gè)雷區(qū)。 PHP需要借助Nginx和PHP-FPM（或類(lèi)似的軟件）來(lái)進(jìn)行進(jìn)程管理和連接池管理。這意味著對(duì)于部署的每個(gè)微服務(wù)來(lái)說(shuō)，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的配置。我們無(wú)法想象在彈性Kubernetes環(huán)境上配置多個(gè)PHP棧的痛苦，我們甚至不知道在這同一臺(tái)機(jī)器上還運(yùn)行了其他什么東西。

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

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

擁抱Go

我們主要偏向使用Node.js和Golang這兩種語(yǔ)言。在做了一些研究之后，我們最后決定放棄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語(yǔ)言（goroutines模塊）專(zhuān)為網(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í)依賴(lài)。例如，當(dāng)使用Node Alpine Linux鏡像時(shí)，我們的前端容器大約為55MB。

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

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

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

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

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

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

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

探索NOSQL

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

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

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

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

Cassandra：因?yàn)樗且粋€(gè)大家熟知的可以擴(kuò)展的數(shù)據(jù)庫(kù)，并被大流量平臺(tái)Netflix和Reddit所使用。它的優(yōu)點(diǎn)是：速度非?？?，能線性擴(kuò)展。不過(guò)，我們發(fā)現(xiàn)它的內(nèi)容管理太復(fù)雜了。如果你知道該如何查詢(xún)數(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ù)都可以訪問(wèn)自己的32核數(shù)據(jù)庫(kù)機(jī)器和不同的數(shù)據(jù)庫(kù)讀副本（Read Replicas）。

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

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

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