技术杂谈

背景

常看一些技术文章时，有些好的描述和句子想着记录下来。因为比较杂，不是特定的分类，所以都记录到这篇博客吧

内容

1.k8s的所有API都是声明式的，也就是面向接口。面向接口，隐藏了实现细节，保留了系统未来持续优化的可能性。（摘抄k8s文档）
分解：架构设计中可扩展性，最容易首先想到的就是面向接口设计。虽然面向接口会使代码显的有些冗余，但却为后期扩展提供了优化的空间。而接口的抽象程度也是非常的关键，抽象过高，调用复杂；抽象不够通用，后期扩展空间也会较小，所以如何抽象一个接口，需要在不断实践过程中学习、把握。

2.API对象是彼此互补而且可组合的（摘抄k8s文档）
分解：因为上面句子是摘抄k8s文档英文版的，所以看起来不够直白。白话来说，就是“高内聚，松耦合”。相信这句话，技术人熟的不能再熟了，理解起来很简单，但真正能做到就很难了。这里，不详细去说如何做到，讲下工作中碰到的经历吧。
（1）粗糙型。看过很多实习生或新入职的同学，为了实现功能而去写代码，可扩展性和可维护性不在他们考虑的范畴。这时候去看他们的代码就像一件粗糙勉强可用的日用品。
（2）工艺品。这个词我没有把它当作褒义词，如果工艺品能够落地，我觉得那确实完美。但如果仅仅只能用于展示，那说白了，没啥用。对应设计，就是设计过度了。这类程序猿少见，一个项目为了所谓“高内聚，低耦合”，硬生生将抽离分成了几十个模块，反而增加了项目理解的难度。我认为设计一定要多反思，最合理的不一定是最合适的。
（3）恰到好处。看过有些同学写的代码，游离上诉两种情况之间，能够满足一定周期的可扩展性和可维护性，适时重构。

3.前几天leader交给我一个调研任务，我把该任务分给了A同学，约有2年工作经验。leader交给我的时候只有一句话，我把这句话适当的分解了下交给了A同学。过了两天，A同学找到我说，想的范围太广，难度太大，不知道怎么做，并问了很多杂乱的问题。然后我就帮他梳理了几个模块、步骤，他大致明白了后再去调研。
包括自己刚入职的时候，接到一个任务，总是迫不及待的开始去做了，总是被师父批评，考虑好了再做。同理，A同学就像当初的自己，接到任务，各种苦思冥想，不先去审视、分解任务，最后既浪费了时间，也无劳而获。我觉得用“磨刀不误砍柴工”总结最为合适。

4.高层API以操作意图为基础设计，低层API根据高层API的控制需要设计。（摘抄k8s文档）
分解：前半句说的是从业务考虑设计接口，后半句说的是依据高层设计低层。在之前自己编程中，低层API往往是更多面向技术设计，这块后面自己需要深思哈。

5.API操作复杂度与对象数量成正比。这一条主要是从系统性能角度考虑，要保证整个系统随着系统规模的扩大，性能不会迅速变慢到无法使用，那么最低的限定就是API的操作复杂度不能超过O(N)，N是对象的数量，否则系统就不具备水平伸缩性了。（摘抄k8s文档）
分解：这个有意思，以后尝试用这个来衡量API操作复杂度，看合不合适。

6.API对象状态不能依赖于网络连接状态。由于众所周知，在分布式环境下，网络连接断开是经常发生的事情，因此要保证API对象状态能应对网络的不稳定，API对象的状态就不能依赖于网络连接状态。（摘抄k8s文档）

7.尽量避免让操作机制依赖于全局状态，因为在分布式系统中要保证全局状态的同步是非常困难的。（摘抄k8s文档）

8.控制机制设计原则（摘抄k8s文档）

• 控制逻辑应该只依赖于当前状态。这是为了保证分布式系统的稳定可靠，对于经常出现局部错误的分布式系统，如果控制逻辑只依赖当前状态，那么就非常容易将一个暂时出现故障的系统恢复到正常状态，因为你只要将该系统重置到某个稳定状态，就可以自信的知道系统的所有控制逻辑会开始按照正常方式运行。
• 假设任何错误的可能，并做容错处理。在一个分布式系统中出现局部和临时错误是大概率事件。错误可能来自于物理系统故障，外部系统故障也可能来自于系统自身的代码错误，依靠自己实现的代码不会出错来保证系统稳定其实也是难以实现的，因此要设计对任何可能错误的容错处理。
• 尽量避免复杂状态机，控制逻辑不要依赖无法监控的内部状态。因为分布式系统各个子系统都是不能严格通过程序内部保持同步的，所以如果两个子系统的控制逻辑如果互相有影响，那么子系统就一定要能互相访问到影响控制逻辑的状态，否则，就等同于系统里存在不确定的控制逻辑。
• 假设任何操作都可能被任何操作对象拒绝，甚至被错误解析。由于分布式系统的复杂性以及各子系统的相对独立性，不同子系统经常来自不同的开发团队，所以不能奢望任何操作被另一个子系统以正确的方式处理，要保证出现错误的时候，操作级别的错误不会影响到系统稳定性。
• 每个模块都可以在出错后自动恢复。由于分布式系统中无法保证系统各个模块是始终连接的，因此每个模块要有自我修复的能力，保证不会因为连接不到其他模块而自我崩溃。
• 每个模块都可以在必要时优雅地降级服务。所谓优雅地降级服务，是对系统鲁棒性的要求，即要求在设计实现模块时划分清楚基本功能和高级功能，保证基本功能不会依赖高级功能，这样同时就保证了不会因为高级功能出现故障而导致整个模块崩溃。根据这种理念实现的系统，也更容易快速地增加新的高级功能，以为不必担心引入高级功能影响原有的基本功能。