底层逻辑尤其要保证单一，一个能力只提供一种方法。想要更多，通过上层组合、上层封装来实现。千万不要把所有需求都放到底层原子能力上。
核心：底层单一，上层组合
底层逻辑尤其要保证单一，一个能力只提供一种方法。
想要更多，那么通过上层组合、上层封装来实现。
千万不要把所有需求都放到底层原子能力上，虽然有些看起来好改，实际就是埋大坑。
符合设计原则、编程哲学是很重要和长久的。
来一个需求找一个好改的方式，这个评估维度是片面和短视的。
一个例子：网卡带宽
这个带宽控制是从精细化到模糊化管理。
- 从 iaas 的角度，这个管理方式是合理的，能适配多样化产品形态；
- 从产品的角度，需设计好统一的、标准化的控制方法。
nic 是网卡维度的控制； instance_extra 是云主机维度的控制； server.yaml 是全局控制。
看起来合理，实际没有人捋清楚，看代码看很久。每次梳理了就忘。
合理的方式应该是：
- 底层保持单一，容易理解；
- 云主机调整和全局的调整可以通过 api 来实现。
这样比较明确，以后也可以实现大会上说的"功能使用频率统计"。
批量、整体，这类操作，千万不要隐藏在配置或者底层的逻辑中，一定要以功能、api 的方式提供。
这样明确、可量化统计、可观测、可追溯。
小结
- 底层逻辑尤其要保证单一，一个能力只提供一种方法；
- 想要更多，通过上层组合、上层封装来实现；
- 千万不要把所有需求都放到底层原子能力上，那是埋大坑；
- 批量、整体操作，一定要以功能、api 的方式提供；
- 这样明确、可量化统计、可观测、可追溯。