从事服务端开发已经有一些日子了，静下来可以想想和记录些服务端开发的想法了。
服务端开发，特别是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服务开发的技巧和小东西还是很多的。有的坑是需要自己踩过才知道痛的。可爱的是，我还在继续踩坑中…
补充下，接口重构几乎是每个服务端开发人员必须经历过的。相较于开发一个新系统，接口重构的难度可以说是翻翻，当然这里的难度也可以理解为难受程度…也会是很锻炼人的一个活。对于重构来说，测试尤为重要，如何有个很好的测试集来保证你的重构的正确性是个难度。