從事服務(wù)端開發(fā)已經(jīng)有一些日子了，靜下來可以想想和記錄些服務(wù)端開發(fā)的想法了。

服務(wù)端開發(fā)，特別是Web開發(fā)，基本上全是處理HTTP請求的處理。根據(jù)具體用途分為兩種：Web頁面開發(fā)和API接口開發(fā)。Web頁面開發(fā)也完全可以看成是API接口開發(fā)，只是它的兩個主要部分，頁面和ajax請求，一個是返回html，另外一個可以返回html，也可以返回其他格式的而已。API接口開發(fā)是針對有客戶端產(chǎn)品而言的。可能是移動設(shè)備，可能是PC應(yīng)用等。

應(yīng)用框架

應(yīng)用框架一般使用的是LNMP或者LAMP，基本的框架就是前端N臺Web服務(wù)機(jī) + cgi訪問PHP + php訪問mysql。

PHP可以看成是C寫的一個大型的Web框架，它的優(yōu)勢在于解釋型，即時修改即時更新。所以線上代碼更新維護(hù)成本極低，加之其為web開發(fā)幾乎是專門定制的一些函數(shù)，所以適合用于web開發(fā)。相較于java開發(fā)web服務(wù)，動不動就需要重新編譯的痛苦就很知足了。

web服務(wù)器現(xiàn)在nginx是越來越多使用，nginx比較apache的優(yōu)勢就在于輕便和靜態(tài)頁面的高并發(fā)性能。一般拿到設(shè)備先需要考慮下單機(jī)可承受的qps大概多少，方法大致就是先只考慮內(nèi)存，計算同時能開啟多少個php-cgi，比如一個4G內(nèi)存的機(jī)器，每個php-fpm大概占用20M內(nèi)存，所以差不多能開啟200個php-cgi進(jìn)程（一般會留些空余的），每個進(jìn)程同一個時間只能跑一個php程序，所以假設(shè)每個php程序跑0.1s，1s就能處理10個請求，所以單機(jī)qps大概會是2000。當(dāng)然，一般不會開啟到這么極致的程度，有幾個原因：

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

2 考慮到如果一旦全部內(nèi)存都使用完了，是否啟用swap，如果沒有的話，那機(jī)器是否就立即當(dāng)機(jī)

3 還需要考慮到CPU和帶寬的使用情況。CPU對一些比如加解密，視頻轉(zhuǎn)碼等操作比較耗時，這個時候如果沒有使用隊列，那么每個請求的時間就會加長。

文件服務(wù)器

一般會要求文件服務(wù)器和web服務(wù)器分開，分開的意思就是使用不同的域名進(jìn)行拆分。當(dāng)然web服務(wù)器也是可以當(dāng)做文件服務(wù)器的，但是由于文件服務(wù)器需要上傳文件，而上傳文件是一個非常耗時的工作，即php的一個程序需要停留的時間很長，所以需要將它們分開。一則可以為以后擴(kuò)展文件服務(wù)器提供便利，二則不會導(dǎo)致文件服務(wù)影響了正常的web服務(wù)。

從文件服務(wù)器拆分的理由上看，在運營過程中一些比較占用資源或者特別頻繁調(diào)用的接口是可以或者應(yīng)該考慮拆分到不同機(jī)器上的。

Web前端機(jī)始終要訪問持久化的數(shù)據(jù)的，mysql的使用是最為頻繁的。其實所有的web服務(wù)說到底都是對數(shù)據(jù)庫進(jìn)行增刪改查的操作。說到性能，數(shù)據(jù)庫的增刪改查操作的性能其實就決定了一切。所以對數(shù)據(jù)庫的建表，索引的使用對一個網(wǎng)站來說尤為重要。覺得最有用的幾個mysql的技巧有：

1 覆蓋索引。就是想辦法讓查詢操作只查索引而不去查表的索引建立方法。建立合適的索引和能只在索引就能找到數(shù)據(jù)的查詢能提高效率。

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

3 string類型的變量的存儲格式，是使用varchar還是char比較好，曾經(jīng)有個項目表設(shè)計從char到varchar之后的數(shù)據(jù)庫大小差別達(dá)到70G和20G的大小…

4 建表的時候需要考慮下以后的分庫分表，如果是使用分表，什么是分表鍵？是否需要反向查詢表？

5 甚至當(dāng)考慮到數(shù)據(jù)庫和Web機(jī)器的機(jī)房分布，這個設(shè)計就更麻煩了...

mysql的建表環(huán)節(jié)和需求有很大關(guān)系。沒有明確的需求，表設(shè)計一定是不正確的。

數(shù)據(jù)庫支持有可能還是不足夠的，那么首先想到的可能就是緩存了。緩存是使用全局緩存？放在web前端機(jī)？需要用什么hash算法？用什么緩存？memcache？redis？mysql也有自帶緩存，如何查詢才能更好命中這個緩存？當(dāng)數(shù)據(jù)更新的時候，緩存中的數(shù)據(jù)是否是臟數(shù)據(jù)？如何更新數(shù)據(jù)？

Web頁面開發(fā)

當(dāng)需要做一個網(wǎng)站的時候，首先要考慮的是用戶量有多少？做一個SNS網(wǎng)站和做一個運營后臺網(wǎng)站完全是兩個不同的概念。

首先是在頁面壓力上，SNS網(wǎng)站的qps可能幾千上萬，而運營后臺壓力幾乎完全可以不用計算。這個就意味著后端的數(shù)據(jù)庫支持不同了。SNS網(wǎng)站可能最常調(diào)用的會是好友關(guān)系和個人信息的接口，這樣的接口是不是需要獨立出來處理？這樣的請求會很多是重復(fù)的，是不是考慮使用中間件或者緩存來減輕對數(shù)據(jù)庫的直接壓力呢？運營數(shù)據(jù)一般使用單表就可以解決的。個人覺得運營中統(tǒng)計的需求是最難做的。首先統(tǒng)計并不是任意的統(tǒng)計要求都可以滿足，這個需要和產(chǎn)品討論需求。其次，統(tǒng)計一般需要使用些訪問日志之類的，可能涉及到許多shell腳本。

API開發(fā)

其實相對于Web開發(fā)，API開發(fā)是屬于被動的。意思就是，由于客戶端可能是手機(jī)產(chǎn)品，可能是PC產(chǎn)品。往往都是有發(fā)布和版本的。這個意味著API接口沒法像Web那樣為所欲為隨時更新代碼。它更多需要考慮到各個版本之間的兼容問題。兼容問題在很大程度上會變?yōu)榧臃?，永遠(yuǎn)不會是減法。個人感覺，如果毫無節(jié)制地滿足需求，隨著版本越來越多，你的代碼中會越來越多if else，到最后，你的代碼就根本無法維護(hù)了。然后就會是別人來接手你的工作，踩坑，邊罵邊重構(gòu)….API開發(fā)是最需要依賴測試的。往往只有測試人員才對各個版本的小改動，小特性如數(shù)家珍。

再考慮到非功能配套：

你可能需要對API調(diào)用時間進(jìn)行統(tǒng)計，這樣你才明白你的接口表現(xiàn)如何。

你的代碼可能還會用到其他機(jī)器上的服務(wù)，比如curl一個其他服務(wù)，這樣的情況，最好考慮下錯誤處理和日志記錄。

對于有金錢交易的接口服務(wù)，日志處理更是必不可少。

對于一些內(nèi)部錯誤，最好不需要直接拋出顯示給用戶，所以需要使用的最好是白名單錯誤機(jī)制。

接口的加密方式，一般最少是需要有個簽名機(jī)制的，考慮到加密方法，大致有幾種：對稱加密和非對稱加密。加密的時候就需要考慮到一些情況了，比如手機(jī)客戶端的用電量等。

如果是給手機(jī)開發(fā)接口，需要考慮流量問題，圖片的規(guī)格問題。

框架永遠(yuǎn)是會變的，不說需求的變化，單就用戶量的變化，20w用戶和1000w用戶的框架一定是不一樣的。剛開始的時候你不可能根據(jù)1000w的用戶量來設(shè)計框架來給20w人用。所以一個好的服務(wù)端框架一定是隨著用戶量變化會進(jìn)行幾次大的變化的。

…

后記

這篇是想到哪寫到哪，寫到這里發(fā)現(xiàn)寫不下去了…總之，web服務(wù)開發(fā)的技巧和小東西還是很多的。有的坑是需要自己踩過才知道痛的。可愛的是，我還在繼續(xù)踩坑中…

補充下，接口重構(gòu)幾乎是每個服務(wù)端開發(fā)人員必須經(jīng)歷過的。相較于開發(fā)一個新系統(tǒng)，接口重構(gòu)的難度可以說是翻翻，當(dāng)然這里的難度也可以理解為難受程度…也會是很鍛煉人的一個活。對于重構(gòu)來說，測試尤為重要，如何有個很好的測試集來保證你的重構(gòu)的正確性是個難度。

原文鏈接：http://www.cnblogs.com/yjf512/archive/2013/03/22/2974842.html