这么一个场景：一个要承载高并发、具有高性能的后台服务，往往会有多个不同的应用服务。问题来了，你会怎样设计架构呢？
如下图所示，为了共用一个稳定高效的网络处理功能，把所有服务写在一个进程里。
接下来悲剧一幕幕就要上演了，如果各个模块是多人协作开发，网络库的作者得想办法设计个插件机制供各个应用挂载，开发时无论是人员或者代码都耦合非常严重，大大影响协作、开发效率，后期要增减一个应用也得大动手脚。好吧，这还可以忍受，问题是写应用的人技术水准还可能层次不齐，一个短板就可能造成整个服务崩溃。
彼此的依赖太严重，效率低下，责任推诿让各个协作者们苦不堪言，各个应用服务的作者决定在自己的服务里单独提供网络模块。就有了如下图的情况，每个应用服务的提供者自己还要提供网络功能模块
接下来悲剧又一幕幕上演了，要知道高性能网络服务模块需要的技术含量之高不是人人都可以写好的，即使咱都能写好或者统一使用了一个牛X的网络库，你对客户端暴露那么多服务地址不讨人嫌嘛，甚至在我身边还有采用专门写一个集中服务来供客户端获取各应用服务的地址的设计......。
通过对上面两种设计的批判，大家是不是会想，这架构缺陷很明显，肯定采用的人很少吧，但是说实在的我已经遇到多次这种设计了，也许是观点不同吧，我对以上两种设计在上述场景下持否定态度。
那我们应该采用怎样的设计适应这种场景呢？
如下图，这是腾讯和微信的部分后台设计架构图
可以看到都会有个接入服务，然后把不同的请求分发给不同的应用服务。其实这个接入服务就是“网关服务”，这种设计在nginx的负载均衡和反向代理功能中都有体现，另外在网游服务器中也大量采用了这种设计思路，由网关服务器将不同的请求分发到不同的应用服务上，等应用服务器处理完后再通过网关服务器转发给客户。
那这种设计的优点在哪呢？
借用知乎王明雨知友的一个比喻：
把服务器想象成饭店，没有网关服务器的情况，就如同每一个厨师服务一桌顾客，从点菜开始到炒菜到上菜到收银，有n个厨师就只能服务n桌顾客。有了网关服务器的话，网关服务器就成了强大的服务员，把招呼，点菜、上菜和收银的活都做了，厨师只需要专心炒菜就行。这样饭店的效率就大大提高了。
-
这样可以把要承载高并发，高性能任务的网络服务独立出来专门做好，做强（对于http协议的场景，可以直接用nginx做网关服务器）。这样各个应用只需把重点放在对业务逻辑的处理即可。从技术架构和项目协作上都做到了解耦。
-
增强了系统的健壮性，一个应用出现故障并不会对其他应用产生影响。后期运维也好做灰度更迭。
-
有应用集群的情况下，可以通过网关服务器做负载均衡，把请求分发在负载低的服务器上。
服务端架构中的“网关服务器”,布布扣,bubuko.com
服务端架构中的“网关服务器”
原文：http://blog.csdn.net/u012730075/article/details/21110731
