核心接口隔离，要做哪些事情？

核心接口隔离，要做哪些事情？

大家好，我是架构摆渡人。这是实践经验系列的第五篇文章，这个系列会给大家分享很多在实际工作中有用的经验，如果有收获，还请分享给更多的朋友。

今天跟大家聊聊隔离这个话题，对于高流量的业务场景，以电商业务举例，一定要做好核心接口的隔离，否则真的就是牵一发而动全身。

以前的工作中有遇到过因为一个卖家的后台查询，产生了慢SQL，导致单量直线下跌，用户无法下单了，都是系统异常，超时报错。

要解决好这些问题，隔壁必须要做，虽然成本比较大，但是带来的收益是你想象不到的稳定。具体怎么做，有哪些步骤，各位看官请继续阅读下去。

资源隔离

首先需要做的就是将资源进行隔离，这里的资源指的是数据库，缓存，MQ等程序依赖的资源。就像开头说的慢SQL影响了整个服务，问题就在于数据库没做隔离。像电商这种场景，买家和卖家的库要拆分出两套，这样卖家查询即使产生慢SQL也不会影响买家这边的下单 *** 作，因为数据库是两个不同的实例。

缓存也是一样的问题，如果共用一个实例，当Redis出现问题，比如大Key导致带宽满了，其他的Redis *** 作都会阻塞，这样就影响到了其他业务。

BC端隔离

资源隔离之后，我们的服务也要进行隔离。将买家和卖家的业务独立出两个服务，每个服务连自己的数据库和缓存，互不影响。

这样隔离还有一个好处就是在后续做多活的时候，卖家场景是不需要做多活保障的，而买家场景是必须要做多活。所以在多活的时候只需要将买家的服务进行多活改造和多机房部署即可。

核心代码隔离

核心代码隔离的就细粒度了，前面我们做了BC端隔离，将买家和卖家的业务进行了隔离。但是还有个问题是就算全部是买家的业务，它也是分级别的，比如核心的下单，确认订单，订单详情，订单列表就属于P0级别，其他的就是P1,P2这种级别。

如果一个P2级别的接口出了问题，影响了P0的接口，那就相当于隔离失效了，所以核心代码一定要单独提取出来作为独立的服务，这样才能达到隔离的效果。

还有个好处就是核心接口的访问量都是大于其他接口的，在大促的时候，扩容只需要扩核心接口的服务，其他的不需要扩容，对于成本来说也是控制的比较好。

部署隔离

前面的步骤都完成后，必然会有一个选项就是部署隔离。因为你服务都独立出来了，部署肯定也是独立的，一个服务一个容器或者一台ECS。大家可能有疑惑了，不都是一个程序部署一台服务器么？这个其实在很多小公司为了节约成本，或者说流量不高的场景下，都会一台服务器部署好几个应用，数据库也有可能就是跟应用在一个服务器上。

隔离部署后，这样某个服务出问题，比如CPU 100%，其实不影响其他服务，这就是独立部署的好处。

编码思路隔离

最后一点就是在编码的过程中，我们一定要分清楚哪些是核心，哪些非核心。比如订单列表的接口，需要显示一个其他的什么信息，这个信息是其他服务提供的，正常的逻辑那就是对每个订单进行一次内部RPC调用，组装数据返回给客户端。

如果这个时候依赖的那个RPC不稳定或者说出问题了，直接报错了，那么此时订单列表就显示不出来了。像这种场景，在编码的时候就需要考虑这个外部依赖是否核心逻辑，是否能够降级。

如果非核心，需要进行异常处理，或者增加降级开关，在大促的时候进行关闭。这样即使调用报错了，只是这部分信息不显示而已，订单列表还是可以显示，这也是一种隔离方式，但是是在编码层面提现的隔离。

总结

聊了这么多隔离，不知道大家在工作中有实现过哪些隔离呢？反正我是都经历过这些问题，经历过共用数据库导致的故障依赖问题，后面一步步将应用，资源，核心接口拆分独立出去，稳定性慢慢就上升了。没有故障，哪来少年你的成长。