一些总结

不得不说，*年的工作经验，其实没写多少代码，只是一直在拓宽自己的技术视野，深度上追求过少。写的没有重点，想到什么就写什么了。

html、css、javascript、jquery、其他(vuejs、angularjs、reactjs)

前段是个体力活，需要记得东西很多，越熟练做页面越快。不需要太多项目逻辑和数学逻辑，适合女生做。比较难搞的是兼容性，有些是webapp苹果和安卓的兼容性更烦人。小公司网站访问量不大，业务逻辑少或者就是纯静态的页面，是靠脸吃饭的，所以前段（小公司可能会把ui设计划到前段）很重要。
与后台交互，一般都是通过后台提供的接口
关于接口（我说说我接触到的）：
    #### 1、不管给前端还是给移动端提供的接口，最好遵守一定约定的格式
        请求接口返回成功时的示例：
                    {
                        'code':0,
                        'msg':'success',
                        data:[
                            {'name':'yii2'},
                            {'name':'laravel'}
                        ]
                    }
        请求接口返回失败时的示例：
                    {
                        'code':1,
                        'msg':'未登录',
                        data:[]
                    }
        解释：
            a.code：代表一种状态码，比如0代表成功，1代表失败，或者再有其他返回的自定义的状态
            b.msg：代表接口返回的信息，尤其失败时，返回的是错误原因
            c.data：代表接口返回的数据，即使没有数据，也要返回该字段并把值置为空（因为这是接口的数据格式，如果前端利用该字段进行逻辑判断，接口返回时没有该字段，就会报错）
    #### 2、接口风格：restful api
        网上搜到的一个示例：
            GET /zoos：列出所有动物园
            POST /zoos：新建一个动物园
            GET /zoos/ID：获取某个指定动物园的信息
            PUT /zoos/ID：更新某个指定动物园的信息（提供该动物园的全部信息）
            PATCH /zoos/ID：更新某个指定动物园的信息（提供该动物园的部分信息）
            DELETE /zoos/ID：删除某个动物园
            GET /zoos/ID/animals：列出某个指定动物园的所有动物
            DELETE /zoos/ID/animals/ID：删除某个指定动物园的指定动物
    #### 3、测试接口：
        接口开发完成后，或者前端使用接口写页面js前，都需要先进行接口测试。现在浏览器上都有很多接口测试工具，比如chrome下的postman（很好用）

php

php开发，现在都在看你用什么框架开发。
laravel（简化版是lumen）
yii2
thinkphp（thinkphp3.2和thinkphp5），
做后台开发最好会在linux上搭建环境，我接触到的公司都是开发自己搭建环境，如果公司有运维，他们也只是给你个纯净的linux环境。如果网站上线后出现bug，通过linux上查看错误日志，能帮助快速找到问题。这期间就需要理解一些linux上php、apache（或者nginx）、mysql的配置信息，如果是自己搭建的环境，这些就相对容易找得到。
当在window下开发完成后，往linux部署项目时常见问题：
    1、文件夹权限问题。比如thinkphp下的runtime文件夹是需要777权限的
    2、文件名字大小写问题。比如thinkphp里require一个类 page.class.php ,而该文件的名字是Page.class.php，那么thinkphp就找不到该文件，就会报错。

mysql

查询时考虑查询效率、数据是否缓存、数据是否有效等细节
一般小公司用不到 读写分离，因为数据量达不到（我遇到的两家公司用户量过万了，就用到了负载均衡、读写分离，去的时候一般都已经搭好了）。
关于读写分离，我觉得和主从复制是离不开的，比如有三台数据库服务器：一台主数据库（名字比如叫master），两台从数据库（名字比如slave1、slave2），写入更新删除数据都是操作在master上，读取数据会从slave1和slave2上读。然后通过配置实现写入、更新、删除数据只是去操作主库master，查询只是去操作两个slave，这个配置就是读写分离配置（属于项目代码里的配置）。主数据库和两个从数据库的数据同步就是是主从复制配置（属于mysql服务器的配置）
比如thinkphp的读写分离配置：
"DB_DEPLOY_TYPE"=>1， //是否启用分布式（）
'DB_RW_SEPARATE'=>true, //是否启用智能读写分离
'DB_TYPE' => 'mysql', //数据库类型
'DB_HOST' => '192.168.2.1,192.168.2.10,192.168.2.11', //服务器地址 192.168.2.1为主库，192.168.2.10和192.168.2.11为从库
'DB_NAME' => 'tp'， //数据库名
'DB_USER' => 'root, root, root', //用户名
'DB_PWD' => 'root , root,root', //密码

    查询时 会从192.168.2.10或者192.168.2.11从库中查询（这个到底选择那个从库进行查询，是在主从复制的配置中的服务器所占比重 体现的）
        $articleObj=M("Article");
        $rows=$articleObj->select();
    写入时 会向192.168.2.1 这个主库中查询
        $articleObj=M("Article");
        $data["title"]="读写分离测试"
        $articleObj->add($data);

负载均衡

一般用于单个服务器难以承受访问压力的时候，利用负载均衡软件把请求分发给多个服务器（这几个服务器里的项目代码其实一模一样）来分摊访问压力。
比如利用haproxy来实现负载均衡：
    现在有两个服务器192.168.1.100、192.168.1.101，两个服务器上都安装了apache（或者nginx），在192.168.1.100上安装haproxy软件（当然也可以单独在一个服务器上安装haproxy做成负载均衡服务器），然后通过配置在haproxy里监听80端口，然后分发给192.168.1.100:8080和192.168.1.101:8080。这时候你再去访问192.168.1.100:80时其实访问的是192.168.1.100:8080或者192.168.1.101:8080，
    为什么使用8080端口？因为我的haproxy和代码服务器在一起，不能在一个服务器上haproxy和apache同时去监听同一个80端口，会冲突。另一个原因是既然做了负载均衡，就是为了让请求直接去访问负载均衡服务来减轻代码服务器的访问压力，所以不让其通过192.168.1.100（其实是192.168.1.100:80）直接访问代码服务器。当然也可以使用其他未被监听的端口，比如192.168.1.100:8001

任务队列

我遇到的项目是利用laravel代码和redis内存服务器实现的。
使用队列的场景：比如当用户在网站上的一篇文章写了条评论，你需要发送一条邮件给文章作者。这时候你可以使用正常的http请求去实现，首先你把用户的评论内容发送到后台，然后把评论写入数据库，最后利用代码发送一个邮件给作者，但是发送邮件时间一般需要几秒，这时候用户在浏览器上需要等待这额外的几秒（如果发送邮件的配置宕掉了，用户就会一直等在这里）。当然也可以利用ajax去实现，但是后台处理有没有成功，你还是需要等待的。如果使用了队列，就可以把发送邮件这个任务推送到队列，然后完成该次http请求，让redis有空闲了再去执行该队列任务发邮件。这里其实是实现了正常http访问不能解决的并行问题，只能等待所有执行完成后才返回成功，体验不好。