從事服務端開發已經有一些日子了，靜下來可以想想和記錄些服務端開發的想法了。
服務端開發，特別是Web開發，基本上全是處理HTTP請求的處理。根據具體用途分為兩種：Web頁面開發和API接口開發。Web頁面開發也完全可以看成是API接口開發，只是它的兩個主要部分，頁面和ajax請求，一個是返回html，另外一個可以返回html，也可以返回其他格式的而已。API接口開發是針對有客戶端產品而言的。可能是移動設備，可能是PC應用等。
應用框架
應用框架一般使用的是LNMP或者LAMP，基本的框架就是前端N台Web服務機 + cgi訪問PHP + php訪問mysql。
PHP可以看成是C寫的一個大型的Web框架，它的優勢在於解釋型，即時修改即時更新。所以線上代碼更新維護成本極低，加之其為web開發幾乎是專門定制的一些函數，所以適合用於web開發。相較於java開發web服務，動不動就需要重新編譯的痛苦就很知足了。
web服務器現在nginx是越來越多使用，nginx比較apache的優勢就在於輕便和靜態頁面的高並發性能。一般拿到設備先需要考慮下單機可承受的qps大概多少，方法大致就是先只考慮內存，計算同時能開啟多少個php-cgi，比如一個4G內存的機器，每個php-fpm大概占用20M內存，所以差不多能開啟200個php-cgi進程（一般會留些空余的），每個進程同一個時間只能跑一個php程序，所以假設每個php程序跑0.1s，1s就能處理10個請求，所以單機qps大概會是2000。當然，一般不會開啟到這麼極致的程度，有幾個原因：
1 需要考慮到其他進程使用內存的情況
2 考慮到如果一旦全部內存都使用完了，是否啟用swap，如果沒有的話，那機器是否就立即當機
3 還需要考慮到CPU和帶寬的使用情況。CPU對一些比如加解密，視頻轉碼等操作比較耗時，這個時候如果沒有使用隊列，那麼每個請求的時間就會加長。
文件服務器
一般會要求文件服務器和web服務器分開，分開的意思就是使用不同的域名進行拆分。當然web服務器也是可以當做文件服務器的，但是由於文件服務器需要上傳文件，而上傳文件是一個非常耗時的工作，即php的一個程序需要停留的時間很長，所以需要將它們分開。一則可以為以後擴展文件服務器提供便利，二則不會導致文件服務影響了正常的web服務。
從文件服務器拆分的理由上看，在運營過程中一些比較占用資源或者特別頻繁調用的接口是可以或者應該考慮拆分到不同機器上的。
Web前端機始終要訪問持久化的數據的，mysql的使用是最為頻繁的。其實所有的web服務說到底都是對數據庫進行增刪改查的操作。說到性能，數據庫的增刪改查操作的性能其實就決定了一切。所以對數據庫的建表，索引的使用對一個網站來說尤為重要。覺得最有用的幾個mysql的技巧有：
1 覆蓋索引。就是想辦法讓查詢操作只查索引而不去查表的索引建立方法。建立合適的索引和能只在索引就能找到數據的查詢能提高效率。
2 InnoDB表最好能使用自增鍵，提高插入操作的效率。
3 string類型的變量的存儲格式，是使用varchar還是char比較好，曾經有個項目表設計從char到varchar之後的數據庫大小差別達到70G和20G的大小…
4 建表的時候需要考慮下以後的分庫分表，如果是使用分表，什麼是分表鍵？是否需要反向查詢表？
5 甚至當考慮到數據庫和Web機器的機房分布，這個設計就更麻煩了...
mysql的建表環節和需求有很大關系。沒有明確的需求，表設計一定是不正確的。
數據庫支持有可能還是不足夠的，那麼首先想到的可能就是緩存了。緩存是使用全局緩存？放在web前端機？需要用什麼hash算法？用什麼緩存？memcache？redis？mysql也有自帶緩存，如何查詢才能更好命中這個緩存？當數據更新的時候，緩存中的數據是否是髒數據？如何更新數據？
Web頁面開發
當需要做一個網站的時候，首先要考慮的是用戶量有多少？做一個SNS網站和做一個運營後台網站完全是兩個不同的概念。
首先是在頁面壓力上，SNS網站的qps可能幾千上萬，而運營後台壓力幾乎完全可以不用計算。這個就意味著後端的數據庫支持不同了。SNS網站可能最常調用的會是好友關系和個人信息的接口，這樣的接口是不是需要獨立出來處理？這樣的請求會很多是重復的，是不是考慮使用中間件或者緩存來減輕對數據庫的直接壓力呢？運營數據一般使用單表就可以解決的。個人覺得運營中統計的需求是最難做的。首先統計並不是任意的統計要求都可以滿足，這個需要和產品討論需求。其次，統計一般需要使用些訪問日志之類的，可能涉及到許多shell腳本。
API開發
其實相對於Web開發，API開發是屬於被動的。意思就是，由於客戶端可能是手機產品，可能是PC產品。往往都是有發布和版本的。這個意味著API接口沒法像Web那樣為所欲為隨時更新代碼。它更多需要考慮到各個版本之間的兼容問題。兼容問題在很大程度上會變為加法，永遠不會是減法。個人感覺，如果毫無節制地滿足需求，隨著版本越來越多，你的代碼中會越來越多if else，到最後，你的代碼就根本無法維護了。然後就會是別人來接手你的工作，踩坑，邊罵邊重構….API開發是最需要依賴測試的。往往只有測試人員才對各個版本的小改動，小特性如數家珍。
再考慮到非功能配套：
你可能需要對API調用時間進行統計，這樣你才明白你的接口表現如何。
你的代碼可能還會用到其他機器上的服務，比如curl一個其他服務，這樣的情況，最好考慮下錯誤處理和日志記錄。
對於有金錢交易的接口服務，日志處理更是必不可少。
對於一些內部錯誤，最好不需要直接拋出顯示給用戶，所以需要使用的最好是白名單錯誤機制。
接口的加密方式，一般最少是需要有個簽名機制的，考慮到加密方法，大致有幾種：對稱加密和非對稱加密。加密的時候就需要考慮到一些情況了，比如手機客戶端的用電量等。
如果是給手機開發接口，需要考慮流量問題，圖片的規格問題。
框架永遠是會變的，不說需求的變化，單就用戶量的變化，20w用戶和1000w用戶的框架一定是不一樣的。剛開始的時候你不可能根據1000w的用戶量來設計框架來給20w人用。所以一個好的服務端框架一定是隨著用戶量變化會進行幾次大的變化的。
…
後記
這篇是想到哪寫到哪，寫到這裡發現寫不下去了…總之，web服務開發的技巧和小東西還是很多的。有的坑是需要自己踩過才知道痛的。可愛的是，我還在繼續踩坑中…
補充下，接口重構幾乎是每個服務端開發人員必須經歷過的。相較於開發一個新系統，接口重構的難度可以說是翻翻，當然這裡的難度也可以理解為難受程度…也會是很鍛煉人的一個活。對於重構來說，測試尤為重要，如何有個很好的測試集來保證你的重構的正確性是個難度。
