一文一点 | 系统架构中的那些分分合合

这是【一文一点】的第12篇学习文章，不拘泥于篇幅字数，用一篇文章说清一个知识点。

讲到分的时候，就不能不提到读写分离，也就是我们说的写主读从，一般这样的场景都是读多写少，那么读多，就需要更多的从，来分摊读的压力。

可是，从的数据是从主上面复制过来的，如果从的数量增多，难免给主带来压力，毕竟主还承担了写的请求，这个时候就需要一个额外的从来负责把数据复制到其它的从上面。

也就变成了下面这样的主-从-从结构了。

在回到我们说的主从上面来，主从结构的数据，主要是通过复制，那么，有的同学就会问到了如果复制存在延迟怎么办。

的确，下面这位同学在极客时间上面的课程中就问到了这样的问题。

其实，我理解这里问问题的同学是想问，读从的时候，数据延迟了，业务上怎么解决。当然作者的答复也没有错，复制延迟是“天生”的本就没有解。

一般的主从架构，是一台主，多台从，适合读多写少的业务场景，大量的读操作请求都落在了从服务器上面。

那么如果是写也多的业务场景呢，一般意义上的主从架构就不适合了，这个时候需要引入分散式集群的概念，就是多台主同时负责读写。

这种情况下就需要将请求合理的落到不同的服务器上面，也就是需要结合分配算法的使用，比如区分不同用户的请求落到不同的服务器上面。

在分散式集群的指导下，实际上是一种“分”的概念，将数据分散到不同的存储服务器上面，这样集群的方式提高了系统整体写和读的性能。

但同时我们也会面临“合”的问题，比如上面如果按照用户区分来写入各个服务器之后，当我们需要按照订单维度来查询的时候，就需要重新将它们整合在一起，当然合的方式，我们可以使用数据异构的方式，来重新存储一份数据供这种场景使用。

说到“分”，还有一层含义的解读，跟我们说的“拆”异曲同工，也就是拆服务，最后是我们说的微服务，从一个大的单体，被拆成好几个独立的系统服务，这也是一个分的过程。

同样这些服务有各自独立的数据库，在业务上也会面临“合”的问题。

这里的“合“又分为两种。

一种”合“是上面跟我们上面讲的查询是一致的，也就是需要把散落在各个系统服务上的数据做一个整合查询，比如订单服务对应的订单数据，商品服务对应的商品数据，需要做一个关联查询。

这种情况下的解决方式跟分散式集群环境下的处理方式基本一致，常用的做法就是数据异构一份新的存储数据。

另外一种”合“是当我们面临前台服务的时候，需要整体输出一份数据给到用户，这个时候各个微服务系统的上面往往会有一个API GATEWAY层。

此时，就需要一个API组合的功能要开发，那么这个API组合功能理论上来讲有三个地方可以做，一个是前台自己，一个是API GATEWAY层，一个是某个主微服务系统来做。

一般是不能让前台服务做的，因为人家是用户端，如果它要来做，就会进行多次REQUEST调用，最好的方式是通过一次REQUEST请求返回。

对于简单的API组合可以放到API GATEWAY来去做，这里一定要注意，这里的简单就是不涉及API返回字段的二次业务计算的。

多简单的呢，就是类似下面这张图所展现的，这三个API是并行调用，由网关来统一组合返回给前端。

那涉及到二次业务计算怎么个理解呢，比如一个订单API返回的字段中有订单金额，那么还需要对这个金额进行再计算，这种肯定不能放进API GATEWAY。

凡是涉及到字段属性需要再进行业务计算的统统都要放到某个微服务上面去做，或者是有专门的BFF层来去做。

那么，到这里，你可能都能想到了，分是解决问题的一个好方法，没错，当我们试着去解决一个问题的时候都是先对任务来分解。

你会发现就连我们的TCP/IP都是分层的。

其实有时候在业务上面我们做分的动作，就是来分离变化。

变化是伴随着程序员长久的话题，按照粗粒度来分，一个业务功能对应的代码段，有更新速度的变，有更新原因的变。

分层是匹配了更新速度的变，比如网关层和业务领域层，其中权限、流控这样的变更速度跟业务增长的变更速度是不同的。

而我们常说的微服务是匹配了更新原因的变，比如订单服务对应业务和商品服务对应的业务的变更原因也肯定是不同的。

本文完。

本周我在国家会议中心会有一次分享，还会对这块做更深入的阐述，有缘的朋友现场见。