先看看结构图：
之前没有写过服务器端的代码，项目中有一个单独的服务端，看了代码，觉得写得挺好的，感觉原作者应该是看过一些开源的代码，框架和设计的--至少自己之前没有设计过服务端代码结构。
总结一下主要的设计：
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，由父类接口定义，实现各自子类，不同子类