我并不总是了解服务器端开发的具体工作。 我只是认为服务的发展是大牛。 今天我看了以下文章以了解。
我从事服务器端开发已有几天了，所以当您冷静下来时，我可以考虑并记录一些服务器端开发想法。
服务器端开发，尤其是Web开发，基本上就是处理HTTP请求。 根据特定目的，它分为两种类型：Web页面开发和API接口开发。 网页开发也可以被视为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如果一次全部 内存已用完，是否启用交换，如果没有，机器是否会立即崩溃
3您还需要考虑CPU和带宽的使用。 CPU需要时间来执行诸如加密和解密，视频转码等操作。如果此时不使用队列，则每个请求的时间将更长。
文件服务器
通常，文件服务器和Web服务器需要分开。 分隔意味着使用不同的域名进行分割。 当然，Web服务器也可以用作文件服务器，但是由于文件服务器需要上传文件，并且上传文件是非常耗时的任务，也就是说，PHP程序需要保留很长时间， 因此它们需要分开。 一个可以为将来文件服务器的扩展提供便利，而另一个不会导致文件服务影响正常的Web服务。
从文件服务器拆分的原因来看，某些占用资源或在操作过程中频繁调用的接口可以或应该拆分为不同的机器。
Web前端计算机始终需要访问持久性数据，而mysql是最常用的。 实际上，毕竟所有Web服务都是添加，删除，修改和检查数据库。 说到性能，数据库添加，删除，修改和查询操作的性能实际上决定了一切。 因此，对数据库表和索引使用索引对于网站尤为重要。 最有用的mysql技术是：
1覆盖索引。 它是找到一种使查询操作仅检查索引而不检查表的索引创建方法的方法。 建立适当的索引和查询以仅在索引中查找数据可以提高效率。
2 InnoDB表最好使用自动增量键来提高插入操作的效率。
3字符串类型变量的存储格式，使用varchar还是char更好？ 项目表设计从char更改为varchar，数据库大小差异达到70G和20G的大小...
4在构建表时，需要考虑将来的子数据库子表。 如果使用子表，那么子表键是什么？ 您需要反向查询表吗？
5即使考虑到计算机机房中数据库和Web机器的分布，这种设计也更加麻烦...
[h ] mysql表的创建链接与需求有很大关系。 没有明确的要求，表设计必须不正确。
数据库支持可能仍然不足，因此想到的第一件事可能是缓存。 缓存是否使用全局缓存？ 放在网络前端计算机上吗？ 需要什么哈希算法？ 使用什么缓存？ 记忆快取？ Redis？ mysql也有自己的缓存，如何查询才能更好地命中这个缓存？ 数据更新后，缓存中的数据是否脏了？ 如何更新数据？
网页开发
建立网站时，首先要考虑的是用户数量？ 成为SNS网站和成为运营后端网站是完全不同的概念。
首先，在页面压力上，SNS站点的qps可能为数万，并且几乎无需计算即可计算出运行背景压力。 这意味着后端数据库支持是不同的。 SNS网站可能最常调用友谊和个人信息的界面。 该接口是否需要独立处理？ 这些请求中有许多将被重复。 您是否应该考虑使用中间件或缓存来减轻对数据库的直接压力？ 通常可以使用单个表来解决操作数据。 我个人认为，操作中的统计要求最难做到。 首先，统计不能满足任何统计要求。 与产品讨论了这种需求。 其次，统计信息通常需要使用一些访问日志等，这可能涉及许多shell脚本。
API开发
实际上，与Web开发相比，API开发是被动的。 这意味着，由于客户端可能是手机产品，因此可能是PC产品。 通常有发行版和版本。 这意味着API接口无法像Web一样随时更新代码。 它需要考虑不同的版本之间的兼容性问题。 兼容性问题将在很大程度上变成加法，从不减法。 就个人而言，如果您无限制地满足要求，并且版本越来越多，那么代码中还会有越来越多的if ，最后，将不再维护您的代码。 然后其他人将接管您的工作，踩坑，在责骂时重构... API开发最依赖测试。 通常，只有测试人员会对每个版本进行较小的更改，并且这些小的功能也同样宝贵。
然后考虑非功能包：
您可能需要计算API调用时间，以便您了解界面 它如何执行。
您的代码也可能使用其他计算机上的服务，例如curl和其他服务。 在这种情况下，最好考虑错误处理和日志记录。
对于具有货币交易的接口服务，日志处理甚至更为重要。
对于某些内部错误，最好不要将其抛出并直接显示给用户，因此最好使用白名单错误机制。
接口的加密方法通常至少需要签名机制。 考虑到加密方法，大致有几种：对称加密和非对称加密。 加密时需要考虑一些条件，例如移动客户端的功耗。
如果要开发手机界面，则需要考虑交通问题和图像规格。
框架将始终发生变化。 更不用说需求的变化，只是用户数量的变化，20w用户和1000w用户的框架必须不同。 刚开始时，您无法基于20位用户使用1000w用户的数量来设计框架。 因此，一个好的服务器端框架必须随着用户数量的变化而发生几项重大变化。
返回列表