API设计原则(觉得太合适,转发做记录)
API设计原则
对于云计算系统,系统API实际上处于系统设计的统领地位,正如本文前面所说,K8s集
群系统每支持一项新功能,引入一项新技术,一定会新引入对应的API对象,支持对该
功能的管理操作,理解掌握的API,就好比抓住了K8s系统的牛鼻子。K8s系统API的设
计有以下几条原则:
1.
所有API应该是声明式的。
正如前文所说,声明式的操作,相对于命令式操作,对于重复操作的效果是稳定的,这对于容易出现数据丢失或重复的分布式环境来说是很重要的。
另外,声明式操作更容易被用户使用,可以使系统向用户隐藏实现的细节,隐藏实现的细节的同时,也就保留了系统未来持续优化的可能性。
此外,声明式的API,同时隐含了所有的API对象都是名词性质的,例如Service、Volume这些API都是名词,这些名词描述了用户所期望得到的一个目标分布式对象
2.
API对象是彼此互补而且可组合的。
这里面实际是鼓励API对象尽量实现面向对象设计时的要求,即“高内聚,松耦合”,对业务相关的概念有一个合适的分解,提高分解出来的对象的可重用性。
事实上,K8s这种分布式系统管理平台,也是一种业务系统,只不过它的业务就是调度和管理容器服务。
3.
高层API以操作意图为基础设计。
如何能够设计好API,跟如何能用面向对象的方法设计好应用系统有相通的地方,高层设计一定是从业务出发,而不是过早的从技术实现出发。
因此,针对K8s的高层API设计,一定是以K8s的业务为基础出发,也就是以系统调度管理容器的操作意图为基础设计。
4.
低层API根据高层API的控制需要设计。
设计实现低层API的目的,是为了被高层API使用,考虑减少冗余、提高重用性的目的,低层API的设计也要以需求为基础,要尽量抵抗受技术实现影响的诱惑。
5.
尽量避免简单封装,不要有在外部API无法显式知道的内部隐藏的机制。
简单的封装,实际没有提供新的功能,反而增加了对所封装API的依赖性。
内部隐藏的机制也是非常不利于系统维护的设计方式,例如PetSet和ReplicaSet,本来就是两种Pod集合,
那么K8s就用不同API对象来定义它们,而不会说只用同一个设计理念
ReplicaSet,内部通过特殊的算法再来区分这个ReplicaSet是有状态的还是无状态。
6.
API操作复杂度与对象数量成正比。
这一条主要是从系统性能角度考虑,要保证整个系统随着系统规模的扩大,性能不会迅速变慢到无法使用,那么最低的限定就是
API的操作复杂度不能超过O(N),N是对象的数量,否则系统就不具备水平伸缩性了
7.
API对象状态不能依赖于网络连接状态。
由于众所周知,在分布式环境下,网络连接断开是经常发生的事情,
因此要保证API对象状态能应对网络的不稳定,API对象的状态就不能依赖于网络连接状态。
8.
尽量避免让操作机制依赖于全局状态,因为在分布式系统中要保证全局状态的同步是非常困难的。