[发明专利]一种适用于高并发场景的服务器I/O实现方法

说明书

本发明涉及一种适用于高并发场景的服务器I/O实现方法，包括：S1、服务启动后，开始监听端口接收请求；S2、收到请求信号后，服务器拉取配置，连接数据库，依赖注入容器启动，进行路由注册；S3、服务器根据请求路由对参数进行安全过滤，传入控制层；S4、控制层根据业务逻辑对数据层进行交互，所述数据层包括DDD层；S5、控制层业务逻辑处理完毕后，输出数据。与现有技术相比，本发明满足高并发场景并适应庞杂项目易扩展的服务器I/O，采用Go语言实现，只需要基本代码就可以很简单的实现非阻塞I/O，基于DDD的实现结构层次鲜明、各有其用，在面对大型复杂项目时，只需增加业务模块，对所需要服务进行依赖注入绑定即可。

技术领域

本发明涉及通信技术领域，尤其是涉及一种适用于高并发场景的服务器I/O实现方法。

背景技术

在当今流量为王的互联网时代，各科技公司无时无刻不在为获客而绞尽脑汁、无所不用其极，但当流量真的突然猛增的时候，产品是否能够流畅地满足用户体验，是否能够承受住高负载、高并发的场景，而这些常常是一名合格的服务端开发工程师应该提前想到并予以完美实现的。

众所周知，应用程序的输入/输出(I/O)性能是衡量一个服务系统性能的关键指标。如何对I/O模型进行选型建模，直接决定着系统是否具备高负载、高并发的能力。

应用程序请求操作系统内核为其执行I/O操作，这个过程称为“系统调用”，其实现细节因操作系统而异，但基本概念是相同的。在执行“系统调用”时，将会有一些控制程序的特定指令转移到内核中去。一般来说，这个过程是阻塞的，这意味着程序会一直等待直到内核返回结果，内核在物理设备(磁盘、网卡等)上执行底层I/O操作并回复系统调用。前面了解到，系统调用一般是阻塞的，有些调用是属于非阻塞的，这意味着内核会将请求放入队列或缓冲区内然后立即返回而不等待实际I/O的发生。阻塞和非阻塞调用在调用时花费的时间方面相差的不是一个数量级。调度方式的不同也会导致当很多线程或进程开始出现阻塞的时候出现不同的问题。由于线程共享共同的内存，并且每个进程都有自己的内存空间，所以单个进程往往会占用更多的内存。调度，实际上完成的是一系列事情，并且每个事情都需要在可用的CPU内核上获得一定的执行时间。如果你有8个内核来运行300个线程，那么你必须把时间分片，这样，每个线程才能获得属于它的时间片，每一个内核运行很短的时间，然后切换到下一个线程。这是通过“上下文切换”实现的，可以让CPU从一个线程切换到下一个线程。但是这种“上下文切换”有一定的时间成本，快的时候可能会小于100纳秒，因实现细节、处理器速度/架构、CPU缓存等软硬件的不同，花个1000纳秒或更长的时间也很正常。如果是阻塞调用方式，线程/进程的数量越多，则上下文切换的次数越多，如果存在成千上万个线程，系统将会变得非常慢。而非阻塞调用实质上是告诉内核“只有在这些连接上有新的数据或事件到来时才调用我”，可有效处理大I/O负载并减少上下文切换次数。

下面再谈下几种流行度很高的编程语言在实现I/O性能上的优缺点。

PHP：作为“世界上最好的语言”，该语言在前几年可谓风靡一时，现在也是热度不减。PHP使用的模型非常简单，虽然存在好几种SAPI(服务应用编程接口)方式实现Engine与服务器软件通信，但一般的PHP服务器原理基本上是一样的：用户浏览器发起一个请求，请求进入到服务器中，服务器为每个请求创建一个单独的进程，并通过一些优化手段对这些进程进行重用，从而最大限度地减少原本需要执行的操作。PHP代码开始执行，并阻塞I/O调用，如你在代码中调用的file_get_contents()，在底层实际上是调用了read()系统调用并等待返回结果。

PHP中，每个请求为一个进程，I/O调用是阻塞的，简单而有效。但是重点来了。如果此时有20000个或者更多客户端并发请求，服务器将会瘫痪，而且扩展比较困难，因为内核提供的用于处理大量I/O(epoll等)的工具并没有充分利用起来。更糟糕的是，为每一个请求创建一个单独的进程会占用大量的系统资源，尤其是内存。

Ruby：Ruby的情况与PHP非常相似，不做详细对比。