Java后台服务端分析

先看看结构图:

 

之前没有写过服务器端的代码,项目中有一个单独的服务端,看了代码,觉得写得挺好的,感觉原作者应该是看过一些开源的代码,框架和设计的--至少自己之前没有设计过服务端代码结构。

总结一下主要的设计:

1.服务端肯定需要一个服务器,这里使用的是Java网络的ServerSocket作为基础服务端

2.服务端包括两个方面:(1)为真正的服务端服务的配置类和配置文件

           (2)服务端本身

3.由第2点可以知晓,服务启动的时候,肯定需要预先加载配置,如图所示,会先执行MainServer的init方法,即加载配置,这里使用了一个配置入口类Config,同时为其传入主配置文件

  3.1服务端启动至Config之后,即可加载主配置文件了,由图可以看出,这里的配置文件不止一份,即与框架、业务都相关

  3.2主配置文件里面包含了每一个具体分类的配置文件路径,比如log,server,spring。。。后面就是面向对象的体现,和其他框架类似,各种配置文件分别对应各自context和config(和ServletContext和ServletConfig类型)

  3.3具体的去解析配置文件,将实际的配置set到各自的config中,config一般都是static的,其方法也一般是static的,生命周期很长,便利,但是注意不要多次加载

  3.4init方法执行完毕,服务端就获取到了各自必须的config,可以在后续使用

4.服务端代码启动

  4.1如图,和上述配置文件类型,各自不同的业务对应各自单独的Server,它们都继承了BaseServer,处理共性问题,这个和ActionSupport类似

  4.2启动各自的Server(Server是一个线程,拥有各自的端口),启动的时候,就可以使用第3步中初始化了的config,并且config是按需要插入的,同时,各Server拥有各自的线程池,用于处理本类型的请求;

  4.3每个Server对应一个处理类Handler,在Handler中,已经获取了请求的Socket,和Server类似,Handler也都可以继承自一个父类Handler,处理通性问题,当然也可以个性化实现,这个处理的方法主要就是process类

  4.4至此,请求基本已经读取了,按照面向对象的思想(和http请求类似),应该将请求封装成对象--request,响应Response可在后面封装(?),这里注意,仍旧为了通性,对于请求,也定义了一个通用父类Message,而具体的request则各自扩展

  4.5后续就继续调用具体的Service,由父类接口定义,实现各自子类,不同子类

原文地址:https://www.cnblogs.com/seguzhizi/p/5549036.html