逐步实现TCP服务端Step05:分布协作

迄今为止讨论的都是使用单个服务程序对外提供服务的情况。虽然netio和s是两个进程,但它俩其实是分管了一个服务程序的通信和业务逻辑两个部分,这里把它们视为一体。

假设s在处理业务的时候需要访问数据库,等从数据库提出数据后,又要进行复杂的数学运算。此种情况,只有单个线程的s势必会在某些环节因耗时过多,而影响到其他客户的服务受理。

若继续坚持单线程的路线,就必须对s进行拆分。就像当初从s中拆分出netio一样。假设用于访问数据库的进程叫做dbsvr,用于计算的服务叫做calsvr,这二者拆分自s,是专门服务于s的服务程序。正因如此,它俩不需要具备对外通信的功能,也就是说他们不需要netio组件的协助。

接下来的问题就是s如何与之通信。我们拆分出诸如dbsvr和calsvr之类的服务,其目的并非是做业务上隔离,关键是出于性能考虑。我们肯定是希望被拆出来的那些服务能够部署在其它机器上,这样就不用与s竞争资源。这样的话,s与之通信的方式就不能局限于本地,应该让服务之间建立TCP连接,基于网络通信。

现实当中,s会与多个服务建立TCP连接,而其它服务程序也会有与另外的服务“交流”的需求。这样,每个服务程序就需要负责管理多个连接:
这种方式,不但增加了各服务程序管理连接的成本。更重要的是这种错综复杂的关系网,让整个后台系统变的难易维护和扩展。

如果将后端服务看成一个系统,那其中各服务程序的启动和关闭,就是“登陆”和“登出”,或者说是“上线”和“离线”。后端系统应提供统一的入口,让服务完成上下线的操作,想象一下家用路由器,所有要上线的设备都由此接入,接入的设备均可互通。

我们要在后端系统中设置这样一个机构,它叫做Proxy,是所有服务程序接入后端系统的唯一入口。每个服务程序启动后都要先与之建立TCP连接,并通过身份验证。

后面讨论Proxy的具体实现。


<==  index  ==>