我并不總是了解服務(wù)器端開發(fā)的具體工作。 我只是認(rèn)為服務(wù)的發(fā)展是大牛。 今天我看了以下文章以了解。

我從事服務(wù)器端開發(fā)已有幾天了，所以當(dāng)您冷靜下來時(shí)，我可以考慮并記錄一些服務(wù)器端開發(fā)想法。

服務(wù)器端開發(fā)，尤其是Web開發(fā)，基本上就是處理HTTP請求。 根據(jù)特定目的，它分為兩種類型：Web頁面開發(fā)和API接口開發(fā)。 網(wǎng)頁開發(fā)也可以被視為API接口開發(fā)，但是它的兩個(gè)主要部分，即頁面和ajax請求，一個(gè)是返回html，另一個(gè)是可以返回html或其他格式。   API接口開發(fā)適用于具有客戶端的產(chǎn)品。 可能是移動設(shè)備，可能是PC應(yīng)用程序，等等。

應(yīng)用程序框架

該應(yīng)用程序框架通常使用LNMP 或LAMP。 基本框架是前端N Web服務(wù)器+ cgi訪問PHP + php訪問mysql。

PHP可以看作是用C編寫的大型Web框架。它的優(yōu)點(diǎn)在于其解釋，可以立即對其進(jìn)行修改和更新。 因此，在線代碼更新和維護(hù)的成本非常低。 另外，一些功能幾乎是為Web開發(fā)專門定制的，因此它適合于Web開發(fā)。 與用Java開發(fā)Web服務(wù)相比，重新編譯的痛苦是非常滿意的。

現(xiàn)在越來越多地使用Web服務(wù)器nginx。  Nginx相對于Apache的優(yōu)勢在于其可移植性和靜態(tài)頁面的高并發(fā)性能。 通常，獲得設(shè)備時(shí)，您需要考慮一臺機(jī)器可以支持多少qps。 該方法大致上是只考慮內(nèi)存，然后計(jì)算一次可以打開多少個(gè)php-cgi。 例如，一臺具有4G內(nèi)存的計(jì)算機(jī)，每個(gè)php-fpm占用大約20M內(nèi)存，因此可以啟動近200個(gè)php-cgi進(jìn)程（通常是一些備用），每個(gè)進(jìn)程只能同時(shí)運(yùn)行一個(gè)php程序，因此假設(shè) 每個(gè)php程序運(yùn)行時(shí)間為0.1s，1s可以處理10個(gè)請求，因此單臺計(jì)算機(jī)的qps可能為2000。當(dāng)然，通常不會打開它達(dá)到極高程度的原因有幾個(gè)：

1需要考慮其他進(jìn)程的內(nèi)存使用情況

2如果一次全部 內(nèi)存已用完，是否啟用交換，如果沒有，機(jī)器是否會立即崩潰

3您還需要考慮CPU和帶寬的使用。  CPU需要時(shí)間來執(zhí)行諸如加密和解密，視頻轉(zhuǎn)碼等操作。如果此時(shí)不使用隊(duì)列，則每個(gè)請求的時(shí)間將更長。

文件服務(wù)器

通常，文件服務(wù)器和Web服務(wù)器需要分開。 分隔意味著使用不同的域名進(jìn)行分割。 當(dāng)然，Web服務(wù)器也可以用作文件服務(wù)器，但是由于文件服務(wù)器需要上傳文件，并且上傳文件是非常耗時(shí)的任務(wù)，也就是說，PHP程序需要保留很長時(shí)間， 因此它們需要分開。 一個(gè)可以為將來文件服務(wù)器的擴(kuò)展提供便利，而另一個(gè)不會導(dǎo)致文件服務(wù)影響正常的Web服務(wù)。

從文件服務(wù)器拆分的原因來看，某些占用資源或在操作過程中頻繁調(diào)用的接口可以或應(yīng)該拆分為不同的機(jī)器。

Web前端計(jì)算機(jī)始終需要訪問持久性數(shù)據(jù)，而mysql是最常用的。 實(shí)際上，畢竟所有Web服務(wù)都是添加，刪除，修改和檢查數(shù)據(jù)庫。 說到性能，數(shù)據(jù)庫添加，刪除，修改和查詢操作的性能實(shí)際上決定了一切。 因此，對數(shù)據(jù)庫表和索引使用索引對于網(wǎng)站尤為重要。 最有用的mysql技術(shù)是：

1覆蓋索引。 它是找到一種使查詢操作僅檢查索引而不檢查表的索引創(chuàng)建方法的方法。 建立適當(dāng)?shù)乃饕筒樵円詢H在索引中查找數(shù)據(jù)可以提高效率。

2 InnoDB表最好使用自動增量鍵來提高插入操作的效率。

3字符串類型變量的存儲格式，使用varchar還是char更好？ 項(xiàng)目表設(shè)計(jì)從char更改為varchar，數(shù)據(jù)庫大小差異達(dá)到70G和20G的大小...

4在構(gòu)建表時(shí)，需要考慮將來的子數(shù)據(jù)庫子表。 如果使用子表，那么子表鍵是什么？ 您需要反向查詢表嗎？

5即使考慮到計(jì)算機(jī)機(jī)房中數(shù)據(jù)庫和Web機(jī)器的分布，這種設(shè)計(jì)也更加麻煩...

[h  ] mysql表的創(chuàng)建鏈接與需求有很大關(guān)系。 沒有明確的要求，表設(shè)計(jì)必須不正確。

數(shù)據(jù)庫支持可能仍然不足，因此想到的第一件事可能是緩存。 緩存是否使用全局緩存？ 放在網(wǎng)絡(luò)前端計(jì)算機(jī)上嗎？ 需要什么哈希算法？ 使用什么緩存？ 記憶快取？  Redis？  mysql也有自己的緩存，如何查詢才能更好地命中這個(gè)緩存？ 數(shù)據(jù)更新后，緩存中的數(shù)據(jù)是否臟了？ 如何更新數(shù)據(jù)？

網(wǎng)頁開發(fā)

建立網(wǎng)站時(shí)，首先要考慮的是用戶數(shù)量？ 成為SNS網(wǎng)站和成為運(yùn)營后端網(wǎng)站是完全不同的概念。

首先，在頁面壓力上，SNS站點(diǎn)的qps可能為數(shù)萬，并且?guī)缀鯚o需計(jì)算即可計(jì)算出運(yùn)行背景壓力。 這意味著后端數(shù)據(jù)庫支持是不同的。   SNS網(wǎng)站可能最常調(diào)用友誼和個(gè)人信息的界面。 該接口是否需要獨(dú)立處理？ 這些請求中有許多將被重復(fù)。 您是否應(yīng)該考慮使用中間件或緩存來減輕對數(shù)據(jù)庫的直接壓力？ 通?？梢允褂脝蝹€(gè)表來解決操作數(shù)據(jù)。 我個(gè)人認(rèn)為，操作中的統(tǒng)計(jì)要求最難做到。 首先，統(tǒng)計(jì)不能滿足任何統(tǒng)計(jì)要求。 與產(chǎn)品討論了這種需求。 其次，統(tǒng)計(jì)信息通常需要使用一些訪問日志等，這可能涉及許多shell腳本。

API開發(fā)

實(shí)際上，與Web開發(fā)相比，API開發(fā)是被動的。 這意味著，由于客戶端可能是手機(jī)產(chǎn)品，因此可能是PC產(chǎn)品。 通常有發(fā)行版和版本。 這意味著API接口無法像Web一樣隨時(shí)更新代碼。 它需要考慮不同的版本之間的兼容性問題。 兼容性問題將在很大程度上變成加法，從不減法。 就個(gè)人而言，如果您無限制地滿足要求，并且版本越來越多，那么代碼中還會有越來越多的if ，最后，將不再維護(hù)您的代碼。 然后其他人將接管您的工作，踩坑，在責(zé)罵時(shí)重構(gòu)... API開發(fā)最依賴測試。 通常，只有測試人員會對每個(gè)版本進(jìn)行較小的更改，并且這些小的功能也同樣寶貴。

然后考慮非功能包：

您可能需要計(jì)算API調(diào)用時(shí)間，以便您了解界面 它如何執(zhí)行。

您的代碼也可能使用其他計(jì)算機(jī)上的服務(wù)，例如curl和其他服務(wù)。 在這種情況下，最好考慮錯誤處理和日志記錄。

對于具有貨幣交易的接口服務(wù)，日志處理甚至更為重要。

對于某些內(nèi)部錯誤，最好不要將其拋出并直接顯示給用戶，因此最好使用白名單錯誤機(jī)制。

接口的加密方法通常至少需要簽名機(jī)制。 考慮到加密方法，大致有幾種：對稱加密和非對稱加密。 加密時(shí)需要考慮一些條件，例如移動客戶端的功耗。

如果要開發(fā)手機(jī)界面，則需要考慮交通問題和圖像規(guī)格。

框架將始終發(fā)生變化。 更不用說需求的變化，只是用戶數(shù)量的變化，20w用戶和1000w用戶的框架必須不同。 剛開始時(shí)，您無法基于20位用戶使用1000w用戶的數(shù)量來設(shè)計(jì)框架。 因此，一個(gè)好的服務(wù)器端框架必須隨著用戶數(shù)量的變化而發(fā)生幾項(xiàng)重大變化。