服务端架构中的“网关服务器”
这么一个场景：一个要承载高并发、具有高性能的后台服务，往往会有多个不同的应用服务。问题来了，你会怎样设计架构呢？ 如下图所示，为了共用一个稳定高效的网络处理功能，把所有服务写在一个进程里。 接下来悲剧一幕幕就要上演了，如果各个模块是多人协作开发，网络库的作者得想办法设计个插件机制供各个应用挂载，开发时无论是人员或者代码都耦合非常严重，大大影响协作、开发效率，后期要增减一个应用也得大动手脚。好吧，这还可以忍受，问题是写应用的人技术水准还可能层次不齐，一个短板就可能造成整个服务崩溃。 彼此的依赖太严重，效率低下，责任推诿让各个协作者们苦不堪言，各个应用服务的作者决定在自己的服务里单独提供网络模块。就有了如下图的情况，每个应用服务的提供者自己还要提供网络功能模块 接下来悲剧又一幕幕上演了，要知道高性能网络服务模块需要的技术含量之高不是人人都可以写好的，即使咱都能写好或者统一使用了一个牛X的网络库，你对客户端暴露那么多服务地址不讨人嫌嘛，甚至在我身边还有采用专门写一个集中服务来供客户端获取各应用服务的地址的设计......。 通过对上面两种设计的批判，大家是不是会想，这架构缺陷很明显，肯定采用...
