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

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

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

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

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

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

PHP無法滿足這些需求，因為：

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

容器化的PHP是一個雷區(qū)。 PHP需要借助Nginx和PHP-FPM（或類似的軟件）來進(jìn)行進(jìn)程管理和連接池管理。這意味著對于部署的每個微服務(wù)來說，PHP-FPM和Nginx必須同時運行。這既浪費了資源，又降低了效率。對運行在服務(wù)器上的PHP實例進(jìn)行優(yōu)化也是相當(dāng)困難的，因為你需要同時熟悉PHP、PHP-FPM和Nginx的配置。我們無法想象在彈性Kubernetes環(huán)境上配置多個PHP棧的痛苦，我們甚至不知道在這同一臺機(jī)器上還運行了其他什么東西。獲取更多視頻資源，微信搜索公眾號：【碼農(nóng)編程進(jìn)階筆記】

對微服務(wù)來說，其復(fù)雜性存在于架構(gòu)中，因為你正在處理的是一個復(fù)雜的交互系統(tǒng)。既然我們已經(jīng)確定采用微服務(wù)架構(gòu)，那么因為錯誤的選擇了編程語言導(dǎo)致的消耗顯然就不值得。

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

擁抱Go

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

那么為什么要使用Go呢？

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

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

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

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

我們也考慮到Go有這些缺點：

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

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

然而，我們必須接受這一點：用Go程序確實需要花上一些功夫，但它能提高代碼質(zhì)量，并讓我們能夠時刻知道代碼實際是如何運行的。獲取更多視頻資源，微信搜索公眾號：【碼農(nóng)編程進(jìn)階筆記】

這并不是說所有的代碼我們都用Go來寫。對于服務(wù)器端渲染，我們使用Node，因為它允許我們在前端和后端之間共用代碼邏輯。我們也可以使用Java來解決特定的問題，因為它已經(jīng)存在了很長時間，并且擁有大量的庫。我們希望能使用最合適的工具，對于大多數(shù)情況而言，Go是我們的首選。

探索NoSQL

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

在我們的傳統(tǒng)架構(gòu)中，我們使用了大量的Redis來進(jìn)行緩存，它的性能非常棒，因為它有效地減少了昂貴的連接數(shù)量。所以當(dāng)我們開始在我們的新架構(gòu)中探索數(shù)據(jù)庫時，我們要探索一下NoSQL，來看看是否可以完全避免這些連接。獲取更多視頻資源，微信搜索公眾號：【碼農(nóng)編程進(jìn)階筆記】

我們試用了這兩個數(shù)據(jù)庫：

MongoDB：因為我們非常好奇對于存儲包含大量元數(shù)據(jù)的游戲數(shù)據(jù)而言，文件存儲是否是一個好的解決方案。但是，缺點是：我們必須在Google Cloud上管理它，而且根據(jù)社區(qū)所說，它根本不能很好地進(jìn)行擴(kuò)展。

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

堅守SQL

我們傾向于構(gòu)建小型而又獨立的服務(wù)，這些服務(wù)可以完成指定的工作，并且在需要的時候可以很輕松地進(jìn)行升級或更換。獲取更多視頻資源，微信搜索公眾號：【碼農(nóng)編程進(jìn)階筆記】

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

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

那么為什么選用MySQL？主要是因為它可以在Google Cloud上進(jìn)行管理，而在DevOps方面我們是務(wù)實的。我們想嘗試試用Postgres，因為它是開源的，有一個強(qiáng)大的社區(qū)，并且已經(jīng)改進(jìn)了很多。因此，如果Google Cloud上有了Alpha版本，我們也會研究一下