API設計原則

?

對于云計算系統(tǒng)，系統(tǒng)API實際上處于系統(tǒng)設計的統(tǒng)領地位，正如本文前面所說，K8s集
群系統(tǒng)每支持一項新功能，引入一項新技術，一定會新引入對應的API對象，支持對該
功能的管理操作，理解掌握的API，就好比抓住了K8s系統(tǒng)的牛鼻子。K8s系統(tǒng)API的設
計有以下幾條原則：

?

?

1.
　　所有API應該是聲明式的。

　　正如前文所說，聲明式的操作，相對于命令式操作，對于重復操作的效果是穩(wěn)定的，這對于容易出現(xiàn)數(shù)據(jù)丟失或重復的分布式環(huán)境來說是很重要的。
　　另外，聲明式操作更容易被用戶使用，可以使系統(tǒng)向用戶隱藏實現(xiàn)的細節(jié)，隱藏實現(xiàn)的細節(jié)的同時，也就保留了系統(tǒng)未來持續(xù)優(yōu)化的可能性。
　　此外，聲明式的API，同時隱含了所有的API對象都是名詞性質(zhì)的，例如Service、Volume這些API都是名詞，這些名詞描述了用戶所期望得到的一個目標分布式對象

?

2.
　　API對象是彼此互補而且可組合的。

　　這里面實際是鼓勵API對象盡量實現(xiàn)面向?qū)ο笤O計時的要求，即“高內(nèi)聚，松耦合”，對業(yè)務相關的概念有一個合適的分解，提高分解出來的對象的可重用性。
　　事實上，K8s這種分布式系統(tǒng)管理平臺，也是一種業(yè)務系統(tǒng)，只不過它的業(yè)務就是調(diào)度和管理容器服務。

3.
　　高層API以操作意圖為基礎設計。

　　

　　如何能夠設計好API，跟如何能用面向?qū)ο蟮姆椒ㄔO計好應用系統(tǒng)有相通的地方，高層設計一定是從業(yè)務出發(fā)，而不是過早的從技術實現(xiàn)出發(fā)。

　　因此，針對K8s的高層API設計，一定是以K8s的業(yè)務為基礎出發(fā)，也就是以系統(tǒng)調(diào)度管理容器的操作意圖為基礎設計。

4.
　　低層API根據(jù)高層API的控制需要設計。

?

　　設計實現(xiàn)低層API的目的，是為了被高層API使用，考慮減少冗余、提高重用性的目的，低層API的設計也要以需求為基礎，要盡量抵抗受技術實現(xiàn)影響的誘惑。

5.
　　盡量避免簡單封裝，不要有在外部API無法顯式知道的內(nèi)部隱藏的機制。

?

　　簡單的封裝，實際沒有提供新的功能，反而增加了對所封裝API的依賴性。
　　內(nèi)部隱藏的機制也是非常不利于系統(tǒng)維護的設計方式，例如PetSet和ReplicaSet，本來就是兩種Pod集合，
　　那么K8s就用不同API對象來定義它們，而不會說只用同一個設計理念
　　ReplicaSet，內(nèi)部通過特殊的算法再來區(qū)分這個ReplicaSet是有狀態(tài)的還是無狀態(tài)。

6.
　　API操作復雜度與對象數(shù)量成正比。

?

　　這一條主要是從系統(tǒng)性能角度考慮，要保證整個系統(tǒng)隨著系統(tǒng)規(guī)模的擴大，性能不會迅速變慢到無法使用，那么最低的限定就是
　 ? API的操作復雜度不能超過O(N)，N是對象的數(shù)量，否則系統(tǒng)就不具備水平伸縮性了

7.
　　API對象狀態(tài)不能依賴于網(wǎng)絡連接狀態(tài)。

?

　　由于眾所周知，在分布式環(huán)境下，網(wǎng)絡連接斷開是經(jīng)常發(fā)生的事情，
　　因此要保證API對象狀態(tài)能應對網(wǎng)絡的不穩(wěn)定，API對象的狀態(tài)就不能依賴于網(wǎng)絡連接狀態(tài)。

8.
　　盡量避免讓操作機制依賴于全局狀態(tài)，因為在分布式系統(tǒng)中要保證全局狀態(tài)的同步是非常困難的。

　　

轉(zhuǎn)載于:https://www.cnblogs.com/atliwen/p/7249401.html

總結(jié)

以上是生活随笔為你收集整理的API设计原则（觉得太合适，转发做记录）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。