zoukankan      html  css  js  c++  java
  • 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.
      尽量避免让操作机制依赖于全局状态,因为在分布式系统中要保证全局状态的同步是非常困难的。


      

  • 相关阅读:
    android 75 新闻列表页面
    android 74 下载文本
    android 73 下载图片
    android 72 确定取消对话框,单选对话框,多选对话框
    android 71 ArrayAdapter和SimpleAdapter
    android 70 使用ListView把数据显示至屏幕
    maven如何将本地jar安装到本地仓库
    Centos6.7搭建ISCSI存储服务器
    解决maven打包编译出现File encoding has not been set问题
    MySQL 解决 emoji表情 的方法,使用utf8mb4 字符集(4字节 UTF-8 Unicode 编码)
  • 原文地址:https://www.cnblogs.com/atliwen/p/7249401.html
Copyright © 2011-2022 走看看