Keep It Simple.Stupid.

一、数据库部分

1.建议数据库查询较为频繁的几个模块，重新设计表结构，之前的结构较为不合理，将来数据量上到一定程度之后很容易出现卡顿。 建议还是采用关系型数据库MYSQL。由于现在数据增长量比较大，为了应对以后大量数据，需要对数据库做重新设计跟优化。特别是模板、用户、用户请柬、订单这四个模块，需要重新设计优化，以应对以后大量数据的查询。

2.建立数据库集群，以及数据库读写分离。新增，更新，删除操作使用主数据库。读取数据使用从数据库。通过数据库集群同步数据。后期扛不住的话从数据库可以根据业务量跟需求进行水平扩展一台到多台。集群的好处还有就是一台崩了其它依旧能够正常运行，用户不会察觉到错误。

3.全面使用Redis或Memcached做前端输出缓存，以缓解数据库查询压力。模板，文章，用数据均可以使用缓存。喜帖吧目前线上模块均未使用缓存，到处需要进行数据库的查询，这样数据库压力非常大，特别是在用户创建请柬的时候，一有锁表操作，其它用户的查询就会卡住，导致非常不友好的体验。所以缓存的建立非常有必要，急需解决。必要的时候也可以设计成一台或多台分布式缓存服务器，以应对大量查询。

这是喜帖吧数据库需要做的，每一条都要做。现在数据量还不是太多，只有一二十万，但是按目前的增速，数据量破百万是很快的。而且马上要上App，把app跟web都算前端的话，数据都是由可靠的后端提供，准确和稳定性是及其重要的，这就相当于一棵树的根一样，一定要扎实。

 

二、后端语言跟框架的选择和规范

考虑到之前使用PHP作为后端语言和Laravel框架，现在后端还是继续使用PHP和Laravel框架。但是后端开发规范需要明确制定，包括很多注释规范，命名规范，代码规范，返回数据规范等等。

1.注释规范

注释包括文件注释，方法注释，条件注释。以前的喜帖吧均未写注释，这样的缺点就是出问题不方便查找是哪里有问题。特别是员工离职之后，新员工要接手跟维护旧代码的成本提高了很多。所以注释必须写。

文件注释写在最上面，写清楚这个文件的作用，作者，时间：

方法注释，什么作用，需要的参数，返回值的类型等等：

条件注释，什么情况下执行该条件：

2.代码规范

建议使用PHP严格模式

方法参数跟返回值都使用强类型，php8很快就要出来了，新版php支持jit，性能会有大幅度的提升。采用严格模式的话，代码可读性更高。当php jit出来以后，移植的成本更低。在不同模式下或多或少减少类型检查，减少内存占用，提升一定性能。

关于命名规范：变量，方法名使用小驼峰命名，类名大驼峰。用详细的英文单词表达变量名称，不要用拼音，更不要用简写。

 

三、前端接口规范（开发app非常重要）

App端跟web前端最好使用一套Api接口，PHP提供标准接口，统一返回Json数据。

建议使用Laravel+dingo+jwt开发API接口, Laravel 5.5 的API Resource处理返回结果，参考使用方式：

Laravel+dingo+jwt：https://blog.csdn.net/qq_28666081/article/details/52188549

API Resource：https://www.colabug.com/2588329.html

请求规范：

遵循Restful接口请求规范

RESTful用法：

http://127.0.0.1/user/1 GET  根据用户id查询用户数据

http://127.0.0.1/user  POST 新增用户

http://127.0.0.1/user  PUT 修改用户信息

http://127.0.0.1/user  DELETE 删除用户信息

不要使用过多冗余的请求参数

响应规范：

 

状态值，信息，数据，hash值每个接口都要按标准返回。

四、资源类文件的存储

由于该项目资源文件是比较多的，图片，音乐，包括以后可能会有视频。这些大量的资源文件的读取都往本地的话，同样会对服务器造成一定的压力，使用量大的话压力更大。所以这一类资源文件，建议使用OSS对象存储，存储在本地的同时，在OSS同时存一份。读取的时候走OSS,可以缓解服务器压力。阿里云目前有这个服务，使用简单，建议使用。