目录(?)[+]

公司系统做了一年多，慢慢也有点规模了。从最初只有一个APP + 一个server的模式，到现在有多个子系统，多个客户端。这个过程中，积累了一些想法，本文简单总结一下

系统拆分的好处

基本上，比较小的系统，单进程集中部署就可以了。集中部署不代表一定不好，在系统规模很小的时候，或许是最适合的，因为调用关系简单，开发也比较容易。但是系统慢慢变大了以后，我认为拆分系统，分布式部署就变得更为合理了。

拆分系统至少有这些我体会到的好处：

1、停掉系统的一个部分，只会影响相关业务，不会造成整体业务中断。特别是一个新的模块上线，尚未稳定的时候，可能会有错误挂掉，或者主动重启维护等，如果是集中部署，就会造成整个系统都不可用。但是分布式部署的情况下，只会中断小范围的业务。当然，就算是集中部署，利用集群，分批重启，也可以实现同样的目的

2、对压力大的节点，可以单独部署集群。比如我们的系统，数据同步模块的负载是最高的，那么就可以针对这个子系统单独部署集群，其他负载低的模块，可以部署在一起，或者单独部署，都比较灵活。当然，要实现水平伸缩，对系统设计本身也有要求，比如至少要实现无状态服务等

3、代码分离，便于权限控制。一般来说，集中部署的代码也是在一起的，如果希望负责子系统A的小组，不需要接触到子系统B的代码，那么分成2个代码库就非常容易实现。相反，如果代码都是在一起的，控制就比较困难。因为不能只开放一部分代码给开发人员，这样不利于在本地搭建开发环境

4、按责任田制度，小团队维护特定模块。跟上面一点比较类似，每个小团队的责任边界比较清晰

按业务垂直拆分系统

拆分系统也要根据实际情况，有不同的选择。我们早期的时候是根据业务，垂直拆分子系统，比如划分成微站，数据同步，连锁等。这样做的好处是，每个子系统都是可以独立跑起来的，比如说把微站子系统运行起来，微站的页面就都能访问了，数据也是该系统自己负责读写的。但是缺点也很明显，就是冗余的代码比较多。比如连锁和微站，2个子系统都需要查询企业信息，那么就各自都写了这部分代码，其实接口几乎是一模一样的，存在很大的复用空间。重复行为基本上都是不好的，这个应该说是开发人员的共识

网状结构

后来做了一点调整，基本上子系统还是按照业务拆分的。但是每个子系统都对外提供服务，比如基础数据查询模块，提供了查询企业信息的接口。连锁和微站子系统，自己就不重复查了，而是以HTTP方式，调用基础数据查询模块的这个接口。这种方式的优缺点和上一种方案大致相反。消除了重复代码，但是模块之间存在依赖关系。如果基础数据查询模块不跑起来，那微站模块虽然能跑起来，但是相关的数据就没有了

而且这样调用关系会比较复杂一点，因为本地调用都变成了HTTP接口调用，意味着业务模块，需要知道去哪里调用所需的服务，可能需要配置很多IP地址（如果依赖很多外部服务的话）。并且这个IP地址是经常需要变化的，不同的开发人员，本地的开发环境地址都不一样；开发环境和生产环境的地址也不一样；生产环境的集群配置变化了，也可能造成地址的变化。系统的复杂性变得比较高

星型结构

再后来为了解决这个调用的问题，TOPO演进为星型结构，有一个中心节点。业务模块把所有的内部请求都发到这个中心节点上，由中心节点负责转发到服务提供者上。这样对于业务模块来说，就不需要知道服务提供方的实际地址，只要把所有请求都发到中心节点上就可以了。映射的工作由中心节点来完成，需要类似这样的映射：

service1       192.168.1.110:8080/svc1

service2       192.168.1.110:8080/svc2

service3       192.168.1.111:8080/svc3

……

这个工作，在服务的数量和复杂度不是太高的时候，只需要一个简单的路由就可以了，不需要专门的服务治理方案。比如我们早期采用的就是nginx，把nginx当做内部的服务中心来使用，借助server_name，proxy_pass，up_stream等特性，已经足以满足需求。但是当服务的数量和复杂度达到一个量级，就需要有专门的方案，来处理服务的注册、发布、寻址、负载均衡、队列、失败重试等需求了