我与Java的相遇，相知，相爱

Posted 2023-04-04 Fish_Vast

❤️ 前言 ❤️

    谨以此篇博文致敬Java，恭喜Java语言诞生至今已有27年的历程。本人是97年出生，Java比我还大了两岁，O(∩_∩)O哈哈，可谓是前人栽树，后人乘凉呀！Java作为一门跨时代的编程语言，普及型不言而喻，涉及到各个行业领域都有它的身影。目前我大多数的同学和前辈们都是选用Java作为他们的第一技术语言，易上手，易操作，稳定性强，也很容易理解。现如今，我也跻身于Java开发这一行业中，27年了，27岁的Java先生/女士，祝您生日快乐呀！

🎵 相遇，青春与懵懂 🎵

    80-90后这代人基本也是到读了大学才正式地接触编程这一概念的，所以想要了解到Java需要从我的大学生涯说起才行呀~刚接触Java这门编程语言，大概是大二到大三期间，因为课程是有学院的排课制定，虽然我作为计算机专业的学生，但是我一开始对编程没有很大的兴趣，很多时候都是为了应付课堂上课以及每个阶段的测试或考试而草草收尾。对于Java，我没有深究，也没有觉得它到底有多大用处？

    单纯滴我，在Java课堂上就是做了几个简易的课程实验，影响较深的就是做了个简易计算器吧，现在想想当时的大学本科真的纯粹在浪费时间在happy呀。记得当时的大佬们都在玩多线程啊，用Java写写小游戏啥的，现在想想当时如果向他们学习的话，后面我能学更多高大上的东西了，因为他们基础打得很牢，后面不管是他们考研也好，还是自己去找工作也罢，他们的前程都是非常的不错的，所以当时应该要多努力才行的。但是人生没有后悔药可以吃，如果当即能看到这篇博文是正在读大学的你而且还是专科生，那么希望小哥哥或者小姐姐能够合理地利用自己的时间来学习Java这门非常nice的语言呀，因为它极有可能作为你以后科研或者工作的技术工具！懵懂滴我，就是这样与Java相遇的，没有太多了解，只是知道Java在我刚来时，它也在！

🍄 相知，研究与毕业 🍄

    又过了一段时间，我的本科生涯来到了大四，毕业季的专科生，难免要做的就是毕业设计，做一个“*****管理系统”，类似的我也就做了这个系统，但是当时我也是依葫芦画瓢，了解要怎么做，同学告诉我这个不难，那个也不难，但是对于Java不太感冒的我而言，这个看起来就很难哦~非常艰难地搞出了一套东西，混过了我的本科生涯。然后全凭运气地考上了研究生，本来我想着研究生也会比较好过吧？可想而知，并不是这样，没日没夜滴创新和看论文成为了我的生活日常，其实这似乎也不是我想要的生活一样，中间有过一段时间同门师兄跟我说用Java做实验是可行，但是由于研究方向受限，我的最终实验工具也并没有借助Java，直到我的研三后半段时期，我真正知道了Java语言相比较其他语言来说还挺有意思的。

    后知后觉的我就花了半年的时间，认认真真地补充我的Java基础。对，没错，很难有人说自己精通Java，一个还没有真正去参加工作的小牛崽子可以说很多都不会的。所以在这段时间补基础也就是非常基础的那种，能说你认识Java了，但是你熟悉它么？你现在爱它么？目前阶段我是做不到的，然后我就抱着稀里糊涂的心态参加了工作了，只能说我的修炼一直没有结束，一直在进行中。

⭐️ 相爱，博客与工作 ⭐️

    2021年6月，我如期研究生毕业参加了现在的工作。就我个人而言，自己有鱼入大海的感觉，也有可能是在校园待的时间太久了，或者是疫情等原因导致我很久没有走到外面的世界呼吸着“新鲜的空气”。本人的状态就是：工作激情>校园激情。我的工作是基于Java的，我的博客起源也是基于Java来撰写的，或许这就是Java这门语言带给我极大的动力和鼓励。

    求学阶段，我是很少有具体的实习开发经验的，来到企业也算是从零起步，这个阶段真的用心付出在企业级开发的各个阶段，中间真的很感谢我的同门师兄，我的同学，我的师傅，手把手教学和指导，让我成长得相当之快，也感谢我们部门的各位同事给予我的各种鼓励和信任。后台开发要学的东西偏多，但是一旦上手过后，应付平常业务工作就得心应手了。Java贯穿了我整个学习过程，中间有花了数月的时间，这个阶段是自学与项目开发平行的，这个阶段是痛并快乐的阶段，因为大部分都是一脸懵逼开始到最终的豁然开朗。这种感觉真的很想谈恋爱的感觉，两者之间会彼此恩爱，也会彼此争吵。如果争吵了，那就证明自己的能力还不够，还需要更加的努力；如果恩爱相伴，那就保持住这种劲头，继续加油，继续学习下去哦。

    与Java“相爱”的过程，我通过CSDN博客平台用“爱的笔记”记录着这些美好记忆，感谢有这么好的平台让我在工作之余能继续保持学习的动力，记录与Java语言相关的学习痕迹。未来的日子里，我将继续保持激情，让"爱"延续下去，让"爱"永恒😝

白皮书：OpenStack与容器的相遇相知（上）

导

读

本文由OpenStack基金会官方发布，来自基金会、用户、厂商的16位专家作者联合撰写，原文请访问：https://www.openstack.org/containers/whitepaper

想象一下，你的任务是从头开始构建整个私有云基础设施。预算有限 ，团队不大，被要求创造一个奇迹。

几年前，你可以构建一个在虚拟机中运行应用程序的基础设施，其中一些裸机用于传统应用程序。随着基础设施的发展，虚拟机（VM）实现了更高水平的效率和敏捷性，但单靠虚拟机并不能完全满足敏捷应用部署的需求。它们继续作为运行许多应用程序的基础，但越来越多的开发人员关注容器的发展趋势，以更好地开发和部署应用程序——因为容器提供了更高级别的敏捷性和效率。

像Docker和Kubernetes这样的容器技术正在成为构建容器化应用程序的主要标准。它们帮助企业摆脱了限制开发敏捷性的复杂性。容器、容器基础设施和容器部署技术已经被证明是非常强大的抽象，可以应用于许多不同的用例。通过使用Kubernetes等技术，企业可以交付一个仅使用容器交付应用程序的云。

但是领先的私有云不仅仅是容器，容器并不适合所有的工作负载和用例。现在，大多数私有云基础设施都需要包含用于管理基础设施的裸机、用于传统应用程序的虚拟机以及用于较新应用程序的容器。支持、管理和协调这三种方法的能力是运营效率的关键。

OpenStack目前是构建私有云的最佳选择，它能够管理网络、存储和计算基础设施，支持来自一个控制平面的虚拟机、裸机和容器。虽然Kubernetes可以说是最受欢迎的容器编排器，并且已经改变了应用程序交付的方式，但它取决于可靠的云基础设施的可用性，而OpenStack为托管应用程序提供了最全面的开源基础设施。OpenStack的多租户云基础设施非常适合Kubernetes，拥有多个集成点、部署解决方案以及跨多个云联合的能力。

在本文中，我们将探讨容器如何在OpenStack中工作，查看各种用例，并提供让容器成为易于采用和使用的技术的OpenStack等开源项目的概述。

OpenStack中容器的总体视图

容器和OpenStack的交汇有三个主要场景。

第一个场景称为基础设施容器，允许运维者使用容器来改善云基础设施的部署、管理和运维。在这种情况下，容器设置在裸机基础设施上，并允许对主机资源进行特权访问。这种访问使它们能够直接利用计算、网络和存储资源，容器运行时通常不为用户所见。这些容器隔离了每个应用程序所依赖的复杂的依赖关系集，同时允许基础设施应用程序直接管理和操作底层系统资源。当要升级服务时，可以在不改变依赖关系的情况下处理升级。

新版本的OpenStack已经接受了这种基础设施容器模型，现在通常使用编排工具和容器化服务的组合来管理OpenStack部署的整个生命周期。基础设施容器使运维者能够使用容器编排技术来解决许多问题，特别是快速迭代/升级现有软件（包括OpenStack）。在容器中运行OpenStack有助于解决时间要求较高的挑战，包括为服务添加新组件，快速升级软件版本以及跨机器和数据中心快速滚动更新。这种方法将容器的敏捷性带入了OpenStack的部署和升级。

第二个场景是关于在云基础设施上托管容器化的应用程序框架。这可以包括Docker Swarm和Kubernetes等容器编排引擎（COE），或者更轻量级的容器专用服务和无服务器应用程序编程接口（API）。无论是在裸机还是虚拟机上，OpenStack社区都致力于确保可以在安全的、租户隔离的云主机上交付容器化应用程序。驱动程序促进了这种场景，这些驱动程序允许像Kubernetes这样的项目直接利用OpenStack API进行存储、负载均衡和身份识别。它还包括用于按需提供托管Kubernetes集群和应用程序容器的API。借助这些功能，开发团队可以编写新的容器化应用程序，并在OpenStack云中快速提供Kubernetes集群。这是一个完整的应用程序生命周期解决方案，提供开发、测试和调试代码所需的资源，并通过强大的自动化功能将应用程序部署到生产环境中。

在最后一个场景中，我们考虑了独立OpenStack和COE部署之间的交互，在本文特指Kubernetes集群。跨OpenStack和Kubernetes集群的API的一致性和互操作性是此场景成功的关键。例如，Kubernetes可以直接连接到OpenStack Cinder托管卷，使用OpenStack Keystone作为授权和身份验证后端，或者作为网络覆盖连接到OpenStack Neutron。反过来，OpenStack云可能与Neutron驱动共享相同的网络覆盖。第三种场景不太关注云服务的托管方式（无论是Kubernetes还是OpenStack），而是更多地关注独立的服务如何交互。

OpenStack容器集成点

在容器上部署OpenStack基础设施

正如介绍中指出的那样，随着容器的崛起，OpenStack的部署和管理发生了显著变化，因为容器带来了管理基础设施代码的新方法。以前的管理策略需要创建和维护重量级的“黄金”机器镜像，或者使用脆弱的状态维护配置管理系统。每种方法都有其复杂性和限制。进一步增加难度的是管理一系列服务，这些服务都需要各自的依赖关系，而这些依赖关系在每个发布中都会变化。如果没有某种形式的应用程序隔离，解决依赖关系变得很困难。

基础设施容器使新的OpenStack部署项目能够在两者之间取得平衡，同时很好地解决了依赖性问题。使用轻量级、独立、自包含且通常为无状态的应用程序容器，云运维者在部署复杂的控制平面时可获得极大的灵活性。结合容器运行时和编排引擎，基础设施容器使得快速部署、维护和升级复杂且高度可用的基础设施成为可能。

在构建OpenStack集群时，选择部署技术要考虑多个维度。运维者可以为其基本容器选择Linux Containers（LXC）或Docker，使用预先构建的或定制的应用程序容器，并选择用于编排的传统配置管理系统或像Kubernetes这样的更现代的方法。表1总结了现有的OpenStack部署项目及其基础技术。

在这些部署系统之下，是为OpenStack代码和支持服务构建一组容器的不同方法。OpenStack Ansible（OSA）和Kolla项目提供了自己的项目托管构建系统，而LOCI则侧重于构建项目应用程序容器，不考虑特定的编排系统。在高层面上，它们之间的差异是：

——OSA的独特之处在于它依赖于较低层次的LXC容器，并且具有用于创建LXC应用程序容器的自定义构建系统。

——Kolla构建系统生成Docker容器（每个服务都有一个容器），还有支持初始化和管理OpenStack部署的容器。Kolla容器具有高度可配置性，可选择基本操作系统、源或软件包安装，以及用于进一步定制的模板引擎。

——构建OpenStack应用程序容器的最终选择是LOCI。LOCI也构建Docker容器，为每个项目提供一个容器。LOCI专注于快速生产紧凑和安全的容器，并期望它们被部署系统用为基础。

裸机基础设施——OpenStack和解决Bootstrap问题

每个云的基础中，都有一个承载基础设施服务的裸机服务器数据中心。即使是“无服务器计算”，也在数据中心硬件上的云上运行软件。如何引导硬件基础设施的问题是OpenStack软件有独特资格来解决的一个关键问题，它可以提供类似于云的裸机管理质量。

OpenStack Ironic提供裸机即服务。作为独立服务，它可以发现裸机节点，在管理数据库中对其进行编目，并管理整个服务器生命周期（包括注册、提供、维护和退役）。当用作OpenStack Nova的驱动程序并结合全套OpenStack服务时，它可以提供强大的类似云的服务来管理整个裸机基础设施。

这引出了一个问题：一个bootstrap OpenStack服务如何管理裸机基础设施？一个典型的解决方案是使用与前面章节中所述相同的基于容器的安装工具来创建种子安装。这个通常被称为“undercloud”的种子可以用来完全自动化裸机集群的管理，就好像它是一个虚拟化的云。

这带来了机会，不仅可以在裸机云上运行OpenStack虚拟化，而且还可以运行裸机Kubernetes安装（可以通过OpenStack服务充分利用身份、存储、网络和其他可用的云API）。

在OpenStack上交付基于容器的应用程序

基础设施容器和裸机基础设施都很重要，但是当大多数人想到容器时，他们想到的是应用程序容器。容器提供的隔离、封装和易维护性使其成为交付应用程序的理想解决方案。但是，容器仍然需要一个主机平台来为它们提供服务，无论是裸机、公有云还是私有云。

Kubernetes是一个交付应用程序的平台，可以与云API一起使用，从而实现关键基础设施的自动交付（如永久存储、负载均衡器、网络和动态分配计算节点）。OpenStack提供云基础设施，无论是作为本地私有云还是通过任何可用的公有或托管OpenStack云。

OpenStack是Kubernetes的首批上游云提供商之一，其活跃的开发团队维护着“Kubernetes / Cloud Provider OpenStack”插件。这个插件允许Kubernetes利用Cinder块存储、Neutron和Octavia Load Balancers，以及使用Nova直接管理计算资源。使用非常简单，只需将驱动程序部署到Kubernetes安装中，设置一个标志来加载驱动程序，并提供本地用户云凭证。

在OpenStack上安装Kubernetes和其他应用程序框架有许多解决方案。提供容器框架的最简单方法之一是使用Magnum——这是一个OpenStack项目，它提供了一个简单的API来部署完全受管理的、有多个应用程序平台（包括Kubernetes）选择的集群。这是一个依赖于OpenStack API和云提供商插件的Kubernetes部署系统的例子。例如，现在它被用在CERN的OpenStack现场云以及合作伙伴云上管理超过200个独立和联合的Kubernetes安装。如果你在首选OpenStack云中没有可用的Magnum API，你可以使用任何其他Kubernetes安装工具（例如kubeadm、Kubernetes Anywhere、Cross-Cloud或Kubespray）在OpenStack上安装和管理Kubernetes集群。因为每个用户都使用标准的Kubernetes，所以很容易启用云提供商接口来利用存储和负载均衡。

另一个OpenStack项目Zun提供了一个轻量级的容器服务API，用于管理单个容器，而无需管理服务器或集群。OpenStack托管的Kubernetes集群具有弹性，因为它可以直接通过Nova API向集群添加或删除云资源来动态调整大小。另外，Kubernetes可以作为OpenStack Zun的容器后端，将pod基础设施的管理转交给Zun。它提供了一个更轻量级和多租户容器服务API，用于运行容器而无需直接创建服务器。与Neutron和Cinder的直接集成被用于为单个容器提供网络和卷。

最后，Qinling项目提供了“Function as a Service”，旨在提供一个支持无服务器功能的平台，类似于Lambda、Azure Functions或Google Cloud Functions。它进一步抽象了容器的管理，允许用户通过事件驱动的、无需服务器的计算体验来加速开发（这种体验可按需伸缩）。Qinling支持不同的容器编排后端（如Kubernetes和Docker swarm）、各种流行的功能包存储后端（如本地存储和OpenStack Swift）。

Kata Containers——通过虚拟化保证应用安全

Kata Containers是一个新的开源项目。它是一个轻量级虚拟机的新颖实现，可无缝集成到容器生态系统中。Kata Containers与容器一样轻而快，并与容器管理层（包括Docker和Kubernetes等常用编排工具）集成，同时还提供了虚拟机的安全优势。Kata Containers符合开放容器倡议（OCI）标准——OpenStack基金会是其中的一个活跃成员。Kata Containers由OpenStack基金会托管，但它是OpenStack项目之外的独立项目，拥有自己的治理和社区。

转向容器带来了独特挑战，即在多租户环境中保护用户工作负载（有可信任和不可信任的工作负载）。Kata Containers使用硬件支持的隔离作为每个容器或pod中容器集合的边界。这种方法解决了传统容器架构中共享内核的安全问题。

Kata Containers非常适合基于事件的按需部署（如持续集成/持续交付）和更长时间运行的Web服务器应用程序。Kata还简化了从传统虚拟化环境向容器的过渡，因为它支持传统访客内核和设备通过功能。Kata Containers提供增强的安全性、可扩展性和更高的资源利用率，同时带来堆栈的整体简化。

并行的OpenStack和Kubernetes集成

选择开源平台的一个主要优势在于，跨平台标准部署的接口的稳定性。OpenStack基金会和CNCF都在为OpenStack云和Kubernetes集群维护互操作标准，确保库、应用程序和驱动程序可以在所有平台上运行，而不用管它们在哪里部署。这为并行集成创造了机会，允许OpenStack和Kubernetes利用彼此的资源。

Kubernetes社区中的OpenStack特别兴趣小组（SIG-OpenStack）维护Cloud Provider OpenStack插件。除了在OpenStack上运行Kubernetes的云提供商接口外，它还保留了几个驱动程序，允许Kubernetes利用单个OpenStack服务。这些驱动程序包括：

——两个独立的Cinder驱动程序。Flex Volume驱动程序使用基于exec的模型与驱动程序进行交互，为容器编排系统使用标准接口的Container Storage Interface（CSI）驱动程序将任意存储系统暴露给其容器工作负载。通过支持70多种存储驱动程序，这些驱动程序可以通过一个Cinder API与大量经过测试的专有和开源存储设备连接。

——基于webhook的Keystone认证和授权接口。每个模式、认证和授权，都可以彼此独立配置。虽然这项工作还在进行中，但该接口支持软多租户（使用OpenStack Keystone支持Kubernetes RBAC）。

OpenStack和Kubernetes都支持由多种驱动程序支持的高度动态网络模型。由于有这些标准网络接口，可以轻松构建具有强大网络集成的独立OpenStack和Kubernetes集群。在OpenStack中，Kuryr项目生成了一个Common Network Interface（CNI）驱动程序，可将Neutron网络提供给Docker和Kubernetes。另一方面，像Calico这样的项目提供Neutron驱动程序，通过标准的Neutron API提供对Kubernetes网络覆盖的直接访问。

内容覆盖主流开源领域

投稿邮箱

[e-mail]