从service center规格限制看软件规格设计的韧性

service center早期的设计存在很多规格限制，给用户使用带来诸多不便。比如service center限制一个微服务的契约个数最大为100，在实际业务系统中，确实很少微服务的契约会超过100，但是偶尔就有几个特殊的微服务超过这个限制。

回到设计这些规格的设计的初衷，增加限制的目的是为了SLA能够在支持的最大容量下保持服务可用性。比如， service center的SLA规格是支持1万实例，那么最大可能有1万微服务，契约数据大小为 100 * 10 * 1000 * N， N为单个契约的大小，如果N的平均值为1000，那么总的数据量接近1G，和ETCD的存储能力在数量级上是匹配的。

上述设计思路逻辑上并没有问题，而且极大的降低了可能的问题风险，但是脱离了业务实际情况。实际情况下，90%的客户的实例数在100以内，那么单个微服务的数据量大小就显得微不足道了， service center完全有能力处理这样的业务场景。

因此，软件规格设计应该具备良好的韧性，既要考虑极端场景的可用性，也要保证支持场景的灵活性。这两方面是相互矛盾的， 因此需要做好权衡。通常是通过放宽小的方面的限制，保证灵活性。比如service center不对契约个数做限制，仅仅限制一个请求的body大小，以及用户能够使用的最大存储空间。通过这样的折中，很好的提升了软件规格的韧性。