本文共 4861 字，大约阅读时间需要 16 分钟。
python 构建抽象类
就像在软件工程中一样，抽象和元数据是系统工程中体系结构的未来。 在许多语言中，都有抽象和元数据。 但是，系统工程从来没有采用这种观点。 对于任何标准抽象，人们总是认为系统太独特了。 既然我们已经标准化了较低层的抽象，我们就可以构建新的系统层抽象了。
在讨论 ，从健康的怀疑态度开始很重要。 安德鲁·科尼格 Andrew Koenig） ：“抽象是选择性的无知。” 当乔尔·斯波尔斯基 Joel Spolsky 描述所有抽象如何泄漏其抽象内容时，他 “泄漏抽象法” 。
知道您在抽象某个系统时会选择忽略它。 这并不意味着每个人都不了解底层系统，但这意味着您对系统的了解会更少。 例如，Amazon Web Services和Google Cloud Platform允许您抽象出物理服务器甚至虚拟服务器。 您对底层物理主机或相关网络一无所知； 但是，这种抽象可能会泄漏。 的Amazon 是抽象泄漏潜在故障的一个示例。 这意味着您仍然需要熟悉基础知识以及抽象的工作方式。 另外，您公司中的团队应该对内部运行的抽象有一个完整的了解； 这不能可靠地外包。
今天的数据中心是一团糟。 在每个环境中，一个应用程序可能具有不同的操作系统和中间件版本。 开发环境将具有最新版本，因为此处的更改更容易接受。 生产将是最旧的版本，因为担心会发生变化。 并且每个应用程序将具有与系统中任何其他应用程序不同的组合。 结果，由于这些不一致导致的故障频繁发生，将变更视为故障的根源，并进一步限制了变更。
现代数据中心基于抽象。 物理层的主要抽象是平台。 该平台允许使用API和更高级别的对象与计算，存储和网络进行交互。 应用程序现在看到的计算资源以不可变的Docker映像的形式运行，它们在基础虚拟或物理主机上作为容器运行。 该应用程序与经过测试的操作系统和中间件打包在一起，并且将相同的映像部署到每个环境中。 现在，应用程序会在部署时从环境自动获取其特定于环境的变量，而不是将其打包到应用程序中或通过手动交互提供。
该模型可以在整个环境中实现更大的一致性和可重复性，并且可以提高敏捷性，因为更改不再被视为所有问题的根源。 现在，它可以通过更快的恢复来解决问题。 现在，我们没有为稳定性进行优化，也没有获得快速变化或稳定性，而是为变化进行了优化，并获得了快速变化和稳定性。
如果您不了解Docker的工作方式，这可能会导致很多泄漏的抽象问题。 例如，如果您在一层中复制一堆文件并在下一层中对其进行 ，则所有文件将在映像中存在两次。 这会很快加起来并在系统中引起很多问题。
Docker还 ，例如 cgroups和命名空间 。 从最基本的角度来看，cgroup决定一个进程可以消耗多少资源，而名称空间则可以确定谁可以消耗它们。
多年来，Docker中还添加了其他抽象，包括网络，卷，机密和服务。 他们还添加了标签以允许分配元数据。 在这些现代的，抽象的，分布式系统中，元数据非常重要。 我们不再能够仅根据机器的名称，位置或地址来讨论它们。 现在，我们基于位置，类型，功能，特征等多个属性来描述和引用它们。这将导致更灵活的抽象。
充分利用了这种灵活抽象的新模型。 它最初是在Docker之上构建的，但是现在它已经抽象出了计算单元，因此甚至虚拟机也可以用作实例容器（尽管这是 ）。 Kubernetes是Google基于内部集群管理系统创建的一个开源项目。
Kubernetes具有与Docker类似的抽象，例如卷，服务和秘密。 但是，Kubernetes也有一个称为的抽象。 容器是一组容器，应在同一位置并共享存储和网络。 它是Kubernetes中最小的可部署单元，而容器是Docker中最小的可部署单元。
Kubernetes还利用了一个插件系统，该插件系统除了提供计算功能外，还为网络和存储提供了抽象。 然后，网络系统使用来描述基于元数据的连接。 Kubernetes中的每个对象都可以附加标签。 这些标签不仅用于描述对象，还用于从未清洗的物料中选择该对象以及所有具有匹配标签的对象。 网络策略使用这些标签将策略应用于具有匹配标签的对象。
通过添加更多抽象，包括和 ，进一步扩展了此功能。 BuildConfig用于描述应如何构建应用程序，以包括用于构建应用程序的映像，用于运行应用程序的映像，应将映像存储在何处以及何时应开始构建。 ImageStreams是图像注册表的抽象。 ImageStreams可以引用存储在OpenShift集成注册表，Docker Hub或公司内部注册表中的图像。 所有这些参考资料和相关数据都是从最终用户那里抽象出来的，从应用程序开发人员的角度来看，这极大地简化了图像管理。
到目前为止，所描述的所有内容都具有自定义配置文档，这些文档具有完成它们所需的非常特殊的知识。 对于我们的工程 ，这是一个挑战，因为我们试图将这些技术引入具有成千上万开发人员的金融和医疗服务企业。 我们必须教每个开发人员多种不同的格式，如果我们更改格式，就必须对所有人进行重新培训。 我们还面临着挑战，那就是我们的容器编排器之外仍然会有工作量。 因此，我们围绕高阶对象创建了自己的抽象。 我们创建了一个系统，使开发人员或管理员可以描述应用程序的诞生与死亡。
有两种类型的文档可以提供此功能。 我们使用namespace.yaml将资源分配给一组对象。 该文件必须由具有适当支出权限的个人批准，才能涵盖所请求资源的估计成本。 批准这些资源后，该名称空间内的任何应用程序或其他对象都可以利用这些资源，直到它们被完全消耗为止。
apiVersion : v1 kind : Namespace name : a-namespace spec : environments : - name : dev clientFacing : false resources : cpu : 2 memory : 4Gi storage : 10Gi - name : test resources : cpu : 6 memory : 12Gi storage : 20Gi
文档的第二级描述特定对象。 有多种类型，例如应用程序，数据库和文档。 一切都有一条管道。 这些文档描述了特定对象所需的资源，该对象与其他命名对象的关系，该应用程序将在其中运行的环境，应构建和测试该应用程序的方式以及应如何部署和运行它。 然后，该文档将转换为与特定技术相关的多个文档，例如Jenkins的Jenkinsfile和Kubernetes的Deployment。 然后引用这些以确保维持每个环境的预期状态。
apiVersion : v1 kind : Application name : application-name metadata : labels : tier : frontend spec : build : type : maven runImageBase : tomcat7 environmentTemplate : replicas : 1 resources : min.memory : 256Mi max.memory : 2Gi environmentVariables : - name : SHARED_ENV value : 'shared value' - name : ANOTHER_ENV value : 'another value' ports : - name : https port : 443 volumes : - name : shared-data emptyDir : { } mountPath : /var/lib/pipeline_data connections : - name : authn environments : - name : dev environmentVariables : - name : ENVIRONMENT_SPECIFIC value : 'dev value' 这种抽象使我们的开发人员可以专注于创造业务价值，而中央团队可以利用单个文档界面将应用程序从GitLab迁移到生产环境。 现在，我们的工具可以根据需要进行更改，而无需开发人员进行任何更改。 中央团队有责任通过这些文档维护合同，以使开发人员的经验不会随着工具的改变而改变。 由于该系统对我们来说运行良好，因此我们希望在不久的将来将其开源。
要深入探讨该主题，请参加10月23日至24日在北卡罗来纳州罗利市举行的All Things Open上Daniel的演讲，《 。
翻译自:
python 构建抽象类
转载地址：http://kgszd.baihongyu.com/