中秋佳节，记录一下最近的一些感想吧

文档很重要

第一个P0，先说一下现象，有个业务方反馈生产环境搜索服务dubbo接口调用时出现了no provider，问题反馈到我这，我就like排查，从dubbo admin上看服务提供者，发现服务提供者有6个在线上运行正常，我自己也调用了一下发现正常的。而且这个是中台服务，如果出现无服务提供者的话，应该不只是一个业务方受影响。电话沟通，双方近期都没有发布过，很奇怪的问题。

就不说排查问题的过程了，直接说造成这个现象的原因： 有两个机器宕机，运维没有监控。
可是线上明明有6个服务提供者在线呢呀。。。咋回事？？？ 标签路由！
排查问题时发现在1.8版本的api包里，竟然写了个标签路由，而且这个路由做到了对开发者透明，路由规则是由另一个服务写到zk里的。标签路由会根据业务方使用的索引路由到对应的机器，这次事故就是因为对应的机器宕机了，所以一直没有服务提供者。
可能前人在设计标签路由的时候，是考虑了业务隔离，对开发透明，无需配置，方便使用。但是我作为后来者，只能说这么重要的设计，怎么能不写文档呢？！
背了个P0，我也是老老实实的把这块的文档补了补。

业务隔离

第二个P0，是因为消息堆积引起的，不说事故了，说一说消息堆积的事。

按理说我们提供的中台服务，应该要做到业务与业务之间是隔离的，互不影响的，但实际的设计却不是这样的。
概括一下现在的设计：多个业务的数据会写到同一个topic，消费时，也按照topic消费。这个设计就导致了多个业务的数据都混在了一个topic中，如果某个业务的数据较多，就会影响其他的业务。

因为这个设计，导致现在维护成本很高。幸好最近领导给时间，要将这块重构掉了，重构就太棒了！