过度设计的问题

这是学习笔记的第2069篇文章

前几天碰到了一个严重的硬件问题导致服务受到影响，我在总结思考的时候，脑袋里冒出了一个观点:过度设计。

问题的背景是这样的，有一套数据仓库的集群，使用了Greenplum技术，里面有不少的segment节点，在最开始设计的时候，因为服务器资源有限，所以在每个服务器上部署了大量的segment节点，假设有200个segment,如果是10台服务器，那么每台服务器上面就有20个segment,通过这种MPP的设计，可以把计算资源（这里是pg）优势整合起来，同时充分利用硬件资源。

在下午的时候发现Greenplum集群的一个服务器磁盘报警了，而工程师在检查的时候发现另外一个插槽的硬盘也有潜在隐患，这是一个RAID5的存储配置，如果第2块磁盘出现损坏，是要丢失数据的。当然GP本身是有一层容灾机制的，可以让Segment的Primary节点漂移到Mirror上面，从技术上来说是可行的，但是现在的资源使用已经远远不是早期的状态，业务压力和需求增加都是近10倍的增长，所以在这种情况下，如果节点漂移之后，某一个服务器的资源负载会有显著的提升，而在批量计算的过程中一旦因为资源的过度使用而导致集群节点再次出现问题，那么这种问题就是连锁式的，排除这种极端情况，一个服务器上部署了过多的节点，要恢复起来本身也是一件痛苦的事情。所以在有限的时间内要尽可能恢复业务，这是一个紧急而重要的事情。

所以我们讨论再三，还是决定稳妥为重，即先把统计业务停了下来，然后等待工程师更换硬盘，整个磁盘数据重构的过程持续了近12个小时，也着实让我们捏了把汗。因为技术上可行，但是在实际操作过程中我们没法打包票，而且一旦出现问题，这么大的集群是完全没法做备份的。

我想了下我们工作中存在很多的过度设计问题，如果细数一下这个过程，可以从功能，性能，可用性这个阶段来说，而归根结底是基于成本，即最小的成本获得最高的收益，这个收益绝非是简单的性能。

早期的业务为了满足功能而做一些妥协或者是定制化的设计实现，主要是面向业务视角，而满足了业务需求之后，发现很多潜在的问题暴露出来，于是会集中精力去灭火，是典型的先污染后治理的思路，而性能设计的过程中成本意识会更多向资源成本方面倾斜，而过度倾斜就会是上面的这种情况，这种情况下是基于性能的视角来设计的，但是没有充分考虑数据的可用性和可恢复性，所以第三层的设计应该是基于故障的设计方案，我们在设计之初就应该明确服务器是不可靠的，资源是不能完全可靠的，我们需要在多个层面进行可用性的设计完善。

常见的过度设计有

1.集群规模过大，但是使用率不高

2.单机多实例设计过度，导致业务难以恢复

3.数据分片过度