后台服务部署拆分原则 后台服务优化原则

之前的《后台服务优化原则》中提到后台service的一些拆分原则，也就是单个服务内对外接口拆分的一些原则。其实，在服务部署时，也会有一些不同的部署策略，来实现另一种意义上的拆分。最重要的作用在于「防火隔离」。

按请求来源渠道拆分

不同的请求来源，请求量必然不太一致。不同来源的请求被分发到各自的一组机器上，起到相互隔离的作用，服务出现问题时，只影响特定来源请求；某个来源渠道请求量上涨或者有问题时，所影响的范围也被限制。

按不同地区来拆分

思路同按请求来源渠道拆分。

按不同号段来拆分

微信的部署是按每千万的用户划分到一个set来承载。每个set是一套完整的服务（包括接入服务、逻辑服务、存储等），大概2、3百台机器（2012年的数据），不仅利于「防火隔离」，更利于扩容。

按不同运营商来拆分

按照不同的运营商来拆分部署时，不仅起到「防火隔离」的作用，也减少由于跨网络请求导致速度慢的情况，在天朝，都知道各运营商互联互通始终是个很现实的问题。
http://www.adrop.me/archives/service-deployment-principles/
目前在做一个Android应用分发的业务，涉及N多部门之间的利益纠葛和势力分配。后台服务在刚开始迭代非常快，很多业务逻辑集中在某个后台service中。

每个后台服务都是一个c++进程，提供rpc接口给调用方。所有请求都会通过网络接收后，在队列中被分发到多个业务处理线程中被统一处理，业务线程通常设置为8或16（cpu核数*1~2）。业务线程会统一处理每个接口的请求，而每个接口实现的复杂度、处理时间、调用量都会不同，并且在接口中如果需要调用其他rpc服务还会涉及网络调用会阻塞线程处理（如果不阻塞向后端的调用需要异步处理），这样每个请求在线程中被处理的时间都不尽相同，为了使线程处理更有高效，考虑如下拆分原则：

一、轻重分离

所谓轻重是指服务所提供对外rpc接口的实现逻辑轻重，分别把业务逻辑比较重的接口和比较轻的接口，拆分开来，逻辑轻的多数接口组成一个服务，逻辑重的少数接口组成一个服务。

二、快慢分离

服务的接口耗时有快有慢，可以把耗时大的接口单独拆分到新服务中，异步实现避免阻塞，不影响其他耗时非常短的接口。

三、多少分离

每个接口的调用量不同，可以把被调用次数比较少或者比较多的接口单独拆分，放在新服务中。

四、读写分离

读写分离其实以上几种拆分方式的综合，一般情况下，读写操作的耗时、调用量都会有不少差别，可以把读的接口和写的接口，拆分到不同的服务，让单个服务的处理更顺畅。

分久必合，合久必分。后台服务随着业务发展，根据需要势必会不停合并或拆分，可能是因为处理瓶颈，可能是优化内部实现，可能是使调用方更合理。拆分时需要按照上述原则来拆分，反之，有些接口需要合并时以上原则同样适用。