设计与开发应用服务器--相关技术

最新推荐文章于 2022-08-11 10:59:07 发布

「已注销」

最新推荐文章于 2022-08-11 10:59:07 发布

阅读量130

点赞数

分类专栏：服务器\架构文章标签： java 网络 javascript ViewUI

本文链接：https://blog.csdn.net/meiyeky/article/details/84508801

版权

服务器\架构专栏收录该内容

7 篇文章 0 订阅

订阅专栏

服务器的设计与开发涉及到诸多技术和问题，归纳一下大致可以分为以下几种：

服务器启动和接收数据过程
多线程策略
NIO
长连接
同步与异步
配置化支持
责任链模式
集群与负载均衡
数据包设计
服务端连接协议
客户端连接技术

服务器启动和数据请求过程

各种服务器所提供的功能和实现机制都不尽相同，但在启动和数据请求这块都长得差不多，遵循固定的一些流程和模式，启动过程一般按一下流程：

1）以main方法的形式提供由外部脚本触发的入口

2）载入配置文件，解析并构建上下文

3）初始化各个组件和资源

4）注册和启动监控和管理组件

5）启动连接监听

数据请求过程一般按一下流程：

1）侦听Socket

2）包装Connection

3）解析并包装数据

4）请求处理

5）向client发送处理结果

多线程策略

多线程的策略一般可以采取两种方式，一种是每一个线程负责监听、处理和返回结果所有事情，另外一种是把监听、接收、处理分开，各自都有独立的线程去处理。第一种策略比较简单，适用于处理不复杂的场景，图示如下：

第二种方式把一个较长的请求处理过程分割开，区分对待，这样能提高系统的吞吐量，比较适用与较为复杂的请求处理场景，图示如下：

apache perfork在此基础上还有个main进程对这些work子进程进行管理，会根据请求的繁忙程度来调整work进程的数目，这也是可以借鉴的。

NIO

NIO的特性非常适用于网络服务器的接收数据这块，因为不是每时每刻都有数据请求，因此没必要搞一堆Accept线程在那里监听等待，以Tomcat6的NIO接收数据为例：

Amoeba也是采用NIO来接收数据流：

长连接

长连接顾名思义就是客户端与服务端保持连接，而不是每次请求都新建连接并在请求完后关闭连接，好处有以下几点：

减少新建和销毁线程所带来的代价
减少线程上下文切换带来的代价
适用与服务端需要监控客户端状态的场景，不需要通过客户端定时轮询来完成
建立了服务器主动向客户端推的通道

同步与异步

一般的情况下服务器端处理客户端请求都是同步的，客户端请求提交后会在一定的超时时间里等待服务器的response，这比较适用于短时间里能处理完的请求，但如果一些请求，比如文件上传，在规定的超时时间里没法处理完，这样异步的处理就比较合适了，所谓异步就是客户端的请求提交后就可以结束这次请求，不用等待response返回，在服务端处理完后主动把结果通知给客户端。Tomcat6推出的Comet技术即就是异步处理的典型，通过Comet技术，客户端所需要的response信息不再需要主动的去索取，而是在服务器端以event的形式推至客户端。更多Comet的信息可见Tomcat官方文档

配置化支持

服务器的各种参数，比如线程池大小、连接协议等等，需要暴露出来可以配置，因此需要有配置管理机制。一般说来配置文件多以xml或properties形式提供。对于properties比较简单，只是很难体现层次化结构，解析起来比较简单，通过Properties类就能很方便地进行解析。而xml体现的信息更友好、更清晰，解析xml的方法比较多，一般用以下几种：

SAX
DOM
JDOM、DOM4j、Digester等

前面两种比较原生态，SAX和DOM的区别就不再累述，JDOM、DOM4j和Digester都是基于前两种以上的开源框架，可以更加方便地调用。个人感觉如果xml不够复杂，不必使用太多的框架，原生态的东西就够用了。

解析完配置文件后，一般可以用更加有语义化的java bean来存储这些配置信息，这样可以更加方便其他模块的调用

责任链模式

责任链模式在服务器设计开发中比较常用，责任链模式的类图如下所示：

责任链模式使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。Tomcat主要的架构pipeline-valve就是基于责任链模式。

通过责任链模式可以比较方便扩展对每次请求的处理，并且能很清新地明确各种处理之间的顺序和依赖关系

集群与负载均衡

为了保持集群实现简单，并更容易地实现横向扩展，尽量做到服务器之间无状态性，若需要状态可以参考Darkstar用集中式的Data service来抽象，保持逻辑处理的服务器是独立和平等的。在负载均衡这块可以采用硬负载（如F5）或软负载（LVS），这些都是比较成熟的方案，但如果负载均衡仍然是系统的瓶颈，可以采用客户端负载均衡的做法，客户端做路由的机理如下图所示：

1）当服务端ready后，会和配置中心建立连接，把自身状态信息发送到配置中心

2）当客户端ready后，会和配置中心建立连接，把所需要服务的相关信息和路由策略同步到本地

3）服务端有变动时，比如有机器宕机或迁移，配置中心会感知，并把改动立刻同步到客户端

4）客户端依据本地的路由信息直接与服务端通信

这种机制的最大优点就是客户端与服务端直接通信，消除了loadBalance单点，但也具有明显的缺点，也就是很难做到按照服务器空闲情况进行很智能的均衡负载，并且服务端的变动也很难立刻同步到客户端。

一般有以下实现措施：

1）客户端、服务端和配置中心彼此之间保持长连接，保障通信的即时性

2）路由策略以业务为维度，如按方法、接口或者参数来路由。或者就是简单的随机和轮询

3）通过配置中心做一些监控的工作，保障服务端的可用性

4）在客户端做容错，比如连接不上服务端（服务端状态同步延迟）时，做重试处理

数据包设计

Tomcat是基于HTTP的服务器，因此它接收和发送的数据都是基于HTTP协议的。如果自己设计的服务器不是基于HTTP，比如是原始的socket，那么就需要设计一套数据协议，例如：

数据协议的设计关键在于简单方便并容易扩展，数据协议就是客户端和服务器端交流的手段，功能越复杂数据协议就越复杂，数据包就会越来越大，因此在设计上需要有所权衡

服务端连接协议

当客户端多样化后就会有多种连接协议共存的需求，比如activeMQ和tomcat就支持多种connector，以activeMQ为例就支持openwire、ssl、stomp、xmpp等不同协议。支持多种协议无非就是在连接模块多开启几个端口的监听和相应协议的解析，做得更好的话最好是插件的模式，实现可插拔，这样就不会因为多种协议搞得整个系统实现过于复杂和混乱

客户端连接技术

客户端连接方案可以有多种选择，如果支持http协议，可以使用jdk提供的HttpClient工具，也可以直接使用网页。如果是socket，使用java net里TCP或UDP相关的类即可。这里需要提一下，最近看到很多人采用flash作为客户端来和服务端通信，并取得很不错的效果，flash提供了这么一些工具和API来支持网络连接和数据传送：

Flash Socket API：通过这类API，使ActionScript代码可以建立套接字连接并读取和写入原始的二进制数据，其没有指定接收或发送的数据格式。
External Interface API：通过这类API，可以实现javascript与actionscript之间的通信，当然这里还有安全沙箱的存在。
Shared Object API：通过这类API，可以实现在本地或服务器上面存储数据。当数据保存在本地的时候，其默认的可以存储的数据是每个域名100K，其与cookie还是有很大的不同点的。
LocalConnection API：通过这类API，可以实现swf文件之间的通信，这种通信是可以跨浏览器的。

以上API的具体使用可以参考一下Flash的文档，这里想说一下flash做为客户端的好处：