精华内容
下载资源
问答
  • 云原生发展趋势-2022
    2021-11-28 23:10:12

    云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。相较于早年的云原生技术生态主要集中在容器、微服务、 DevOps 等技术领域,现如今的技术生态已扩展至底层技术、编排及管理技术、安全技术、人工智能技术、数据库技术以及场景化应用等众多分支,初步形成了支撑应用云原生化构建的全生命周期技术链。

    云原生Everywhere

    基于DevOps,微服务,容器编排,服务网格等技术和设计思想构建云原生应用,已逐渐得到了业界的认可和接受,并在各行各业进行了大量的实践和应用。除了构建用户应用以外,云原生的设计思想也广泛用在PaaS和IaaS的产品设计里面。
    在PaaS服务领域,大量的组件和框架也正在基于云原生的设计思想进行演进,例如云原生的数据仓库Snowflake,基于AWS以及Azure公有云提供data-warehouse-as-a-service服务;例如云原生的Apache Pulsar消息队列,采取了存算分离的设计架构,支持多租户,其架构设计能够充分利用分布式的、能够弹性伸缩的云端资源。
    在IaaS服务领域,同样云原生产品也不断涌现。例如,KubeVirt基于Kubernetes集群,将容器技术与KVM技术进行结合,创建基于容器的虚机;例如云原生存储的发展也非常迅速,通过容器向外提供存储服务,包括Longhorn,OpenEBS等项目用于提供块存储服务,Minio用于提供对象存储等。
    在网络功能层面,CNF (Cloud-native Network Function)的概念已经提出,作为VNF(Virtualized Network Functions)在容器领域的专用术语,提出了基于容器技术实现虚拟网络功能的思路,包括但不限于路由器,交换机,VPN,防火墙等。
    在未来几年,基于云原生设计思想的各种产品和应用将会继续层出不穷,将会覆盖到云计算的各个方面和所有领域,提升基础设施以及业务应用的敏捷开发部署,弹性伸缩,自动恢复等能力。

    多云/混合云

    云原生通过容器技术,定义了标准的镜像格式,统一了应用的打包标准,提供了一致的运行环境。云原生通过Kubernetes容器编排技术,定义了各种标准对象,以及自定义对象的扩展机制,并通过声明式API的终态机制管理Kubernetes各种对象构建用户应用。Kubernetes对资源层和应用层进行了解耦,形成了分布式系统下应用统一发布的事实标准,解决了多云/混合云环境下厂商锁定,应用难以迁移的问题,极大的促进了多云/混合云的发展和部署。
    多云/混合云的环境下,通常会部署多个Kubernetes集群。通过集群联邦技术,可以跨集群管理应用程序,在满足容灾、隔离等要求下提升资源的使用效率,并提供类似于单个集群环境的用户操作体验。kubefed v2提供了跨集群同步资源,以及基于DNS服务器和负载均衡的跨集群发现功能;该项目在2021年6月份发布了0.8版本,已实现集群联邦的主要功能,当前也在一些小规模生产环境下得到部署和应用,后续有望应用到更多的多云以及混合云多集群管理场景。支持多集群管理的另外一个方案是Virtual-Kubelet,顾名思义就是实现一个虚拟 kubelet,并提供操作 pod 的接口供用户来实现达到和真实 kubelet 有相同行为的目的。

    边缘计算

    随着物联网,人工智能,5G等技术的快速发展,智能终端设备数量呈迅速增长趋势,业界对边缘计算的重要性和必要性也达成一致,未来几年,将是边缘计算走向成熟和规模部署的重要时间与机遇窗口。在边缘计算领域,基于Kubernetes 等云原生技术,有助于实现大规模异构设备接入、镜像管理、应用分发、应用升级、应用运维等边缘业务生命周期管理,有利于支持云边以及边边的统一协同与调度,支持云端统管,边端自治的分级业务模型。
    在容器编排技术方面,Kubernetes的轻量级版本不断涌向和走向生成环境,例如K3s,Microk8s, K0s以及OpenShift都针对边缘计算场景不断优化资源需求,降低环境依赖,支持更广泛和灵活的异构部署能力。
    在容器集群管理方面,集中控制平面的技术和产品也日渐成熟,包括Anthos,Rancher,KubeOne等,方便对大量分散的边缘集群以及边缘应用进行统一管理,向上呈现出一个统一的管理和控制平面。
    另外,提供边缘计算整体解决方案的开源技术也不断发展和成熟,例如KubeEdge,OpenYurt等,将容器化应用编排功能扩展到边缘的节点和设备,并为云和边缘之间的网络,应用部署和元数据同步提供基础架构支持。

    可编程Linux内核

    Linux内核是云原生的事实标准操作系统,由于Extended Berkeley Packet Filter(eBPF)的引入,它的使用方式开始发生根本性的转变。虽然最初的目标是用于高级内核监控,但这个原始BPF的内存映射扩展可以在内核空间中运行任何沙盒程序,而无需更改内核源代码或加载模块。
    随着支持eBPF功能的内核版本的普及,正在出现并将会出现更多的基于eBPF功能的产品与方案。例如,Cilium通过eBPF为使用Kube-Proxy进行流量路由提供一种更快的替代方案;Falco使用eBPF进行容器安全检查等。

    容器运行时安全

    容器技术作为云原生的核心技术之一,提供了应用封装能力,使得“一次打包,到处运行”成为现实,极大的提高了应用的交付和部署能力。容器技术采用共享宿主机内核方式运行,利用内核特性实现对不同用户的命名空间进行隔离,使用 CGroups进行硬件资源分配与限制。实现原理决定了容器的隔离性和封闭性,还是低于拥有独立GuestOS的虚拟机。由于操作系统内核漏洞,容器组件设计缺陷,以及不当的配置等,都可能导致容器发生逃逸,从而获取宿主机权限。
    目前有Firecracker,Kata,gVisor等项目致力于解决上述安全隐患,打造安全容器。其中Firecracker,Kata的解决方法是让容器运行到一个特定的轻量级虚拟机中,优化内存大小,减少外设类型,提供单独内核增强容器隔离;而gVisor则通过拦截容器中应用的系统调用,模拟了一个操作系统内核。可以预见,未来几年基于这几种技术的安全容器将会得到广泛应用。

    云原生持续交付模型

    GitOps是一种实现持续交付的模型,它的核心思想是将应用系统的声明性基础架构和应用程序存放在Git的版本控制库中。通过GitOps,当使用Git提交基础架构代码更改时,自动化的交付流水线会将这些更改应用到应用程序的实际基础架构上。GitOps还会使用工具将整个应用程序的实际生产状态与基础架构源代码进行比较,然后它会告诉集群哪些基础架构源代码与实际环境不匹配。从实用的角度来看, GitOps提升了开发者体验和云原生开发效率,随着Argo、GitLab、Flux等项目的不断成熟,GitOps在云原生持续交付领域会扮演更重要的角色。

    智能运维

    AIOps,即 Artificial Intelligence for IT Operations,智能运维,将人工智能应用于运维领域,基于已有的运维数据(日志、监控信息、应用信息等),通过机器学习的方式来进一步解决自动化运维没办法解决的问题。AIOps采用分析和机器学习技术分析从多种IT运营工具和设备收集的大数据,自动实时确定并应对问题,从而实现IT运营的自动化和增强。
    云原生技术的发展,以及云原生应用的普及,也促进智能运维的发展,使得智能运维概念具备了落地的可能。一方面,Kubernetes使得应用具备了弹性扩缩容,故障自愈等能力。另一方面,通过部署云原生的人工智能应用,对集群和应用的性能数据,故障率,异常事件进行训练和建模,也极大的提升了运维的智能化水平。

    更多相关内容
  • 云原生技术发展简史 首先从第一个问题进行分享,那就是“为什么要开设云原生技术公开课?”云原生、CNCF 都是目前非常热门的关键词,但是这些技术并不是非常新鲜的内容。 2004 年— 2007 年,Google 已在内部大规模...

    云原生技术发展简史

    首先从第一个问题进行分享,那就是“为什么要开设云原生技术公开课?”云原生、CNCF 都是目前非常热门的关键词,但是这些技术并不是非常新鲜的内容。

    • 2004 年— 2007 年,Google 已在内部大规模地使用像 Cgroups 这样的容器技术;
    • 2008 年,Google 将 Cgroups 合并进入了 Linux 内核主干;
    • 2013 年,Docker 项目正式发布。
    • 2014 年,Kubernetes 项目也正式发布。这样的原因也非常容易理解,因为有了容器和 Docker 之后,就需要有一种方式去帮助大家方便、快速、优雅地管理这些容器,这就是 Kubernetes 项目的初衷。在 Google 和 Redhat 发布了 Kubernetes 之后,这个项目的发展速度非常之快。
    • 2015 年,由Google、Redhat 以及微软等大型云计算厂商以及一些开源公司共同牵头成立了 CNCF 云原生基金会。CNCF 成立之初,就有 22 个创始会员,而且 Kubernetes 也成为了 CNCF 托管的第一个开源项目。在这之后,CNCF 的发展速度非常迅猛;
    • 2017 年,CNCF 达到 170 个成员和 14 个基金项目;
    • 2018 年,CNCF 成立三周年有了 195 个成员,19 个基金会项目和 11 个孵化项目,如此之快的发展速度在整个云计算领域都是非常罕见的。

    云原生技术生态现状

    因此,如今我们所讨论的云原生技术生态是一个庞大的技术集合。CNCF 有一张云原生全景图(https://github.com/cncf/landscape),在这个全景图里已经有 200 多个项目和产品了,这些项目和产品也都是和 CNCF 的观点所契合的。所以如果以这张全景图作为背景,加以思考就会发现,我们今天所讨论的云原生其实主要谈论了以下几点:

    1. 云原生基金会 —— CNCF;
    2. 云原生技术社区,比如像 CNCF 目前正式托管的 20 多个项目共同构成了现代云计算生态的基石,其中像 Kubernetes 这样的项目已经成为了世界第四活跃的开源项目;
    3. 除了前面两点之外,现在全球各大公有云厂商都已经支持了 Kubernetes。此外,还有 100 多家技术创业公司也在持续地进行投入。现在阿里巴巴也在谈全面上云,而且上云就要上云原生,这也是各大技术公司拥抱云原生的一个例子。

    我们正处于时代的关键节点

    2019 年正是云原生时代的关键节点,为什么这么说?我们这里就为大家简单梳理一下。

    从 2013 年 Docker 项目发布开始说起,Docker 项目的发布使得全操作系统语义的沙盒技术唾手可得,使得用户能够更好地、更完整地打包自己的应用,使得开发者可以轻而易举的获得了一个应用的最小可运行单位,而不需要依赖任何 PaaS 能力。这对经典 PaaS 产业其实是一个“降维打击”。

    2014 年的时候,Kubernetes 项目发布,其意义在于 Google 将内部的 Borg/Omega 系统思想借助开源社区实现了“重生”,并且提出了“容器设计模式”的思想。而 Google 之所以选择间接开源 Kubernetes 而不是直接开源 Borg 项目,其实背后的原因也比较容易理解:Borg/Omega 这样的系统太复杂了,是没办法提供给 Google 之外的人使用,但是 Borg/Omega 这样的设计思想却可以借助 Kubernetes 让大家接触到,这也是开源 Kubernetes 的重要背景。

    这样到了 2015 年到 2016 年,就到了容器编排“三国争霸”的时代,当时 Docker、Swarm、Mesos、Kubernetes 都在容器编排领域展开角逐,他们竞争的原因其实也比较容易理解, 那就是 Docker 或者容器本身的价值虽然大,但是如果想要让其产生商业价值或者说对云的价值,那么就一定需要在编排上面占据一个有利的位置。

    Swarm 和 Mesos 的特点,那就是各自只在生态和技术方面比较强,其中,Swarm 更偏向于生态,而 Mesos 技术更强一些。相比之下, Kubernetes 则兼具了两者优势,最终在 2017 年“三国争霸”的局面中得以胜出,成为了当时直到现在的容器编排标准。这一过程的代表性事件就是 Docker 公司宣布在核心产品中内置了 Kubernetes 服务,并且 Swarm 项目逐渐停止维护。

    到了 2018 年的时候,云原生技术理念开始逐渐萌芽,这是因为此时 Kubernetes 以及容器都成为了云厂商的既定标准,以“云”为核心的软件研发思想逐步形成。

    而到了 2019 年,情况似乎又将发生一些变化。

    2019 年——云原生技术普及元年

    为什么说 2019 年很可能是一个关键节点呢?我们认为 2019 年是云原生技术的普及元年。

    首先大家可以看到,在 2019 年,阿里巴巴宣布要全面上云,而且“上云就要上云原生”。我们还可以看到,以“云”为核心的软件研发思想,正逐步成为所有开发者的默认选项。像 Kubernetes 等云原生技术正在成为技术人员的必修课,大量的工作岗位正在涌现出来。

    这种背景下,“会 Kubernetes”已经远远不够了,“懂 Kubernetes”、“会云原生架构”的重要性正日益凸显出来。 从 2019 年开始,云原生技术将会大规模普及,这也是为什么大家都要在这个时间点上学习和投资云原生技术的重要原因。

    学习大纲

    第一期云原生的教学大纲,主要以应用容器和 Kubernetes 为核心,在后面几期将会陆续上线 Service Mesh、Serverless 等相关课程。

    在第一期,我们首先将课程分为两部分——基础知识部分和进阶知识部分,总共有 17 个知识点。

    课程预备知识

    大家可能存在这样的疑惑,就是想要学习云原生基础知识之前需要哪些预备知识呢?其实大致需要三部分预备知识:

    1. Linux 操作系统知识:主要是一些通识性的基础,最好具有一定的在 Linux 下开发的经验;
    2. 计算机和程序设计的基础:这一点到入门工程师或者高年级本科生水平就足够了;
    3. 容器的使用基础:希望大家具有容器的简单使用经验,比如 docker run 以及 docker build 等,最好有一定 Docker 化应用开发的经验。当然,我们在课程中也会讲解相关的基础知识。

    三、什么是“云原生”?云原生该怎么落地?

    在介绍完课程之后,我们再来详细的聊一聊“云原生”:什么是“云原生”?云原生该怎么落地?这两个问题也是整个课程的核心内容。

    云原生的定义

    很多人都会问“到底什么是云原生?”

    实际上,云原生是一条最佳路径或者最佳实践。更详细的说,云原生为用户指定了一条低心智负担的、敏捷的、能够以可扩展、可复制的方式最大化地利用云的能力、发挥云的价值的最佳路径。

    因此,云原生其实是一套指导进行软件架构设计的思想。按照这样的思想而设计出来的软件:首先,天然就“生在云上,长在云上”;其次,能够最大化地发挥云的能力,使得我们开发的软件和“云”能够天然地集成在一起,发挥出“云”的最大价值。

    所以,云原生的最大价值和愿景,就是认为未来的软件,会从诞生起就生长在云上,并且遵循一种新的软件开发、发布和运维模式,从而使得软件能够最大化地发挥云的能力。说到了这里,大家可以思考一下为什么容器技术具有革命性?

    其实,容器技术和集装箱技术的革命性非常类似,即:容器技术使得应用具有了一种“自包含”的定义方式。所以,这样的应用才能以敏捷的、以可扩展可复制的方式发布在云上,发挥出云的能力。这也就是容器技术对云发挥出的革命性影响所在,所以说,容器技术正是云原生技术的核心底盘。

    云原生的技术范畴

    云原生的技术范畴包括了以下几个方面:

    第一部分是云应用定义与开发流程。这包括应用定义与镜像制作、配置 CI/CD、消息和 Streaming 以及数据库等。
    第二部分是云应用的编排与管理流程。这也是 Kubernetes 比较关注的一部分,包括了应用编排与调度、服务发现治理、远程调用、API 网关以及 Service Mesh。
    第三部分是监控与可观测性。这部分所强调的是云上应用如何进行监控、日志收集、Tracing 以及在云上如何实现破坏性测试,也就是混沌工程的概念。
    第四部分就是云原生的底层技术,比如容器运行时、云原生存储技术、云原生网络技术等。
    第五部分是云原生工具集,在前面的这些核心技术点之上,还有很多配套的生态或者周边的工具需要使用,比如流程自动化与配置管理、容器镜像仓库、云原生安全技术以及云端密码管理等。
    最后则是 Serverless。Serverless 是一种 PaaS 的特殊形态,它定义了一种更为“极端抽象”的应用编写方式,包含了 FaaS 和 BaaS 这样的概念。而无论是 FaaS 还是 BaaS,其最为典型的特点就是按实际使用计费(Pay as you go),因此 Serverless 计费也是重要的知识和概念。

    云原生思想的两个理论

    在了解完云原生的技术范畴之后你就会发现,其所包含的技术内容还是很多的,但是这些内容的技术本质却是类似的。云原生技术的本质是两个理论基础。

    第一个理论基础是:不可变基础设施。这一点目前是通过容器镜像来实现的,其含义就是应用的基础设施应该是不可变的,是一个自包含、自描述可以完全在不同环境中迁移的东西;
    第二个理论基础就是:云应用编排理论。当前的实现方式就是 Google 所提出来的“容器设计模式”,这也是本系列课程中的 Kubernetes 部分所需主要讲解的内容。

    基础设施向云演进的过程

    首先为大家介绍一下“不可变基础设施”的概念。其实,应用所依赖的基础设施也在经历一个向云演进的过程,举例而言,对于传统的应用基础设施而言,其实往往是可变的。

    大家可能经常会干这样一件事情,比如需要发布或者更新一个软件,那么流程大致是这样的,先通过 SSH 连到服务器,然后手动升级或者降级软件包,逐个调整服务器上的配置文件,并且将新代码直接都部署到现有服务器上。因此,这套基础设施会不断地被调整和修改。

    但是在云上,对“云”友好的应用基础设施是不可变的。

    这种场景下的上述更新过程会这么做:一旦应用部署完成之后,那么这套应用基础设施就不会再修改了。如果需要更新,那么需要现更改公共镜像来构建新服务直接替换旧服务。而我们之所以能够实现直接替换,就是因为容器提供了自包含的环境(包含应用运行所需的所有依赖)。所以对于应用而言,完全不需要关心容器发生了什么变化,只需要把容器镜像本身修改掉就可以了。因此,对于云友好的基础设施是随时可以替换和更换的,这就是因为容器具有敏捷和一致性的能力,也就是云时代的应用基础设施。

    所以,总结而言,云时代的基础设施就像是可以替代的“牲口”,可以随时替换;而传统的基础设施则是独一无二的“宠物”,需要细心呵护,这就体现出了云时代不可变基础设施的优点。

    基础设施向云演进的意义

    所以,像这样的基础设施向“不可变”演进的过程,为我们提供了两个非常重要的优点。

    1. 基础设施的一致性和可靠性。同样一个镜像,无论是在美国打开,在中国打开,还是在印度打开都是一样的。并且其中的 OS 环境对于应用而言都是一致的。而对于应用而言,它就不需要关心容器跑在哪里,这就是基础设施一致性非常重要的一个特征。
    2. 这样的镜像本身就是自包含的,其包含了应用运行所需要的所有依赖,因此也可以漂移到云上的任何一个位置。

    此外,云原生的基础设施还提供了简单、可预测的部署和运维能力。由于现在有了镜像,应用还是自描述的,通过镜像运行起来的整个容器其实可以像 Kubernetes 的 Operator 技术一样将其做成自运维的,所以整个应用本身都是自包含的行为,使得其能够迁移到云上任何一个位置。这也使得整个流程的自动化变得非常容易。

    应用本身也可以更好地扩容,从 1 个实例变成 100 个实例,进而变成 1 万个实例,这个过程对于容器化后的应用没有任何特殊的。最后,我们这时也能够通过不可变的基础设施来地快速周围的管控系统和支撑组件。因为,这些组件本身也是容器化的,是符合不可变基础设施这样一套理论的组件。

    以上就是不可变基础设施为用户带来的最大的优点。

    云原生关键技术点

    当我们回过头来看云原生关键技术点或者说它所依赖的技术理论的时候,可以看到主要有这样的四个方向:

    1. 如何构建自包含、可定制的应用镜像;
    2. 能不能实现应用快速部署与隔离能力;
    3. 应用基础设施创建和销毁的自动化管理;
    4. 可复制的管控系统和支撑组件。

    这四个云原生关键技术点是落地实现云原生技术的四个主要途径,而这四个技术点也是本门课程的 17 个技术点所主要讲述的核心知识。

    本节总结

    “云原生”具备着重要的意义,它是云时代技术人自我提升的必备路径;
    “云原生”定义了一条云时代应用从开发到交付的最佳路径;
    “云原生”应用生在云上,长在云上,希望能够将云的能力发挥到极致。

    总结点评:

    “未来的软件一定是生长于云上的”这是云原生理念的最核心假设。而所谓“云原生”,实际上就是在定义一条能够让应用最大程度利用云的能力、发挥云的价值的最佳路径。在这条路径上,脱离了“应用”这个载体,“云原生”就无从谈起;容器技术,则是将这个理念落地、将软件交付的革命持续进行下去的重要手段之一。

    而后面讲解的 Kubernetes 项目,则是整个“云原生”理念落地的核心与关键所在。它正在迅速成为连通“云”与“应用”的高速公路,以标准、高效的方式将“应用”快速交付到世界上任何一个位置。如今”云原生应用交付“,已经成为了 2019 年云计算市场上最热门的技术关键词之一。希望学习课程的同学们能够学以致用,持续关注以 K8s 为基础进行“云原生应用管理与交付”的技术趋势。

    注:本系列的文章都是摘录并整理自阿里云云原生课程。

    展开全文
  • FreeWheel核心业务开发团队在打造云原生微服务架构的过程中,搭建新服务的需求在日趋增多。 为了应对这一挑战,我们研发了基于AWS的低代码开发平台。本文就从低代码和开发平台的基本概念讲起,带你体验低代码开发...

    近几年来,低代码和开发平台成为了技术圈子的热点话题。

    很多企业也开始尝试使用低代码来快速地搭建应用,从而减少开发成本和运维成本。FreeWheel核心业务开发团队在打造云原生微服务架构的过程中,搭建新服务的需求在日趋增多。

    为了应对这一挑战,我们研发了基于AWS的低代码开发平台。本文就从低代码和开发平台的基本概念讲起,带你体验低代码开发实践之路。

    1

    什么是低代码和开发平台
    低代码(Low-code)是一种全新的开发范式,开发人员仅仅需要少量的代码甚至是0代码就可以快速地完成服务的搭建。

    低代码开发平台(Low-Code Development Platform, LCDP)是基于低代码和可视化界面的开发平台。咨询公司Forrester Research在2014年6月首次给出了它的定义:

    低代码开发平台旨在通过很少的代码降低服务在全生命周期的开发成本,从而实现业务的快速交付。

    从定义不难看出,低代码开发平台是一种提效降本的重要手段。为此,低代码开发平台应当具备以下3种能力。

    1. 可视化界面

    可以把低代码开发平台理解成一种IDE。

    用户可以从它的组件库里以可视化甚至是拖拽的方式,像搭积木一样完成服务的创建。

    另外,和传统的IDE如Visual Studio的MFC所支持的可视化能力相比,低代码开发平台应当有能力支持端到端的可视化编程。

    1. 规模化生产

    用户往往需要搭建不同类型的服务,甚至是不同语言的服务,这就需要平台具备规模化生产的能力。可以通过提供服务模板功能来做到这一点。不同的模板对应不同的业务场景下的最佳实践,用户搭建服务时选择合适的模板即可。

    1. 全生命周期管理

    低代码开发平台支持软件的全生命周期的管理。

    通过平台,我们不仅可以轻松地设计并开发服务,也能够一键部署服务,还能够满足服务的运维的需求。

    平台对服务生命周期的管理也会带来聚合效应,使得平台成为服务的百科全书。

    2

    低代码开发平台的优势
    事实上,低代码开发的诞生可以追溯到2000年代初期,典型代表如Visual Studio的MFC等工具。但与这些早期工具不同的是,低代码不等于零代码,而是要少写代码,比如通过少写重复代码来提高生产力,通过少写基础代码来屏蔽底层技术细节等。

    那么,低代码开发平台可以给企业带来什么呢?

    提效降本

    低代码开发平台致力于以工业化标准化的方式替代传统手工作坊式的软件开发。平台提供了众多的基础设施、公共组件、自动化流水线等功能。这使业务团队能够从重复的工作中释放出来,更多的聚焦在业务本身。

    质量保证

    质量保证始终是软件开发绕不开的话题。线上故障频发,项目延期交付甚至成了行业常态。低代码开发平台的引入将规范化软件开发的流程,减少人工出错的可能。

    团队协作

    软件开发过程非常的复杂,往往也需要不同职能团队的配合。

    但在传统的开发模式下,各个团队往往各司其职,长期来看会形成团队壁垒,使得跨团队的沟通极其低效。

    而低代码开发平台的引入会使得诸如业务开发团队、基础设施开发团队、运维团队工作在同一个平台下,轻松打破团队间的壁垒,实现高效地协作。

    3

    低代码开发平台构建之路
    经过数月的开发、试错与重构,团队打造了基于AWS云原生的低代码开发平台——Bingo。

    该平台包含了一套Web UI,用户可以通过可视化界面创建新的服务。平台对规模化生产、CICD、监控、日志等功能提供了支持。

    随着平台功能的不断完善,运维团队人员也加入了Bingo开发团队,Bingo平台开始在推广使用。

    ▊ 平台的技术选型

    针对Bingo平台,我们从以下几个方面进行了技术对比和选型。

    前端技术栈

    前端技术栈选择了React。一方面,React有着非常成熟的社区与生态;另外一方面,开发团队有着丰富的React使用经验。

    后端技术栈

    后端编程语言选择了Golang。和其他Web框架如Ruby on Rails相比,Golang使用虽然烦琐,却有着更好的性能。此外,这也与团队微服务的技术栈一致。

    数据存储

    数据库选择了Amazon Relational Database Service(RDS)。文件存储选择了Amazon Simple Storage Service(S3)和Amazon Elastic File System(EFS)。云原生的方式极大地降低了维护成本。

    部署方式

    Bingo平台的部署可以考虑Amazon Elastic Kubernetes Service(EKS)、Amazon Elastic Compute Cloud(EC2)或者Amazon Lambda。鉴于平台可以独立于微服务集群存在,没必要部署到EKS当中。

    另外,和EC2相比,Lambda更加灵活,部署更为简单,成本也更为低廉。

    因此,平台选择了无服务器架构。同时,平台的CI/CD是自服务的,即Bingo的上线发布采用了Bingo平台提供的CI/CD的功能。这使得平台上线任何新功能都可以通过平台做一手的验证,然后再交付给用户。

    ▊ 平台架构
    根据以上对比,我们选择了一套云原生+定制化组件的架构,如下图所示。

    在这里插入图片描述

    与业内流行的低代码开发平台类似,Bingo平台有一套可视化UI,即Bingo Web UI。

    平台的后端(Bingo Lambda)包含模板管理、服务管理、服务创建、服务部署等功能,每个功能是一个单独的Lambda。

    平台的存储层(Storage)包含数据库存储RDS与用于存储模板代码、服务代码的代码存储GitHub。

    图中左边描述了日志的收集,我们通过Amazon CloudWatch收集Lambda的日志,并经由Kafka将日志通过ElasticSearch+Logstash+Kiabana呈现给用户。

    图中右边是CI/CD部分。CI流水线会在每次服务代码改动后将服务打包并上传到远端仓库。CD流水线会从仓库中获取Lambda zip包,然后上传到S3,再完成部署。部署使用了运维团队提供的基础设施即代码(Infrastructure as Code, IaC),这就使得我们很轻松地做到了不同环境部署的自动化。

    ▊ 平台的落地实现

    Bingo平台提供了一套可视化界面,支持服务模板的管理和服务全生命周期的管理。

    服务模板的管理

    我们提供了服务模板的管理功能来做到规模化的生产。针对每一种类型的服务提供一种模板,每个模板定义了一个业务场景的最佳实践。使用Bingo创建新服务时,根据业务场景选择合适的模板即可。这里举几个例子。

    Amazon Gateway + Lambda模板提供外部API

    Amazon ALB + Lambda模板提供内部API

    Amazon EventBridge + Lambda模板处理异步任务、定时任务

    Amazon Kinesis + Lambda模板处理数据流

    gRPC + 微服务模板搭建基于gRPC的微服务

    模板管理功能提供了模板列表页面和模板详细信息页面。模板列表页支持模板的分页和搜索的功能。可以点击特定的模板进入详细信息页面。每个模板都有一个对应的详细信息页面。页面包含贡献者、模板名称、模板代码的Git仓库、使用场景介绍、关键字标签等。其中关键字标签支持编辑功能,可以选择添加已有标签或者创建新的标签,也可以按需删除标签。此外,还可以通过点击创建模板问题按钮,对模板提出反馈。下图是一个使用 ALB + Lambda构建API的模板。

    在这里插入图片描述

    模板管理还提供了新增模板的功能。新增模板时需要填写贡献者、名称、模板代码的Git仓库、使用场景介绍、关键字标签等。其中模板代码的Git仓库需要预先准备好,并包含对应的模板代码文件。

    模板代码是模板的核心内容。模板代码由说明书、Makefile、配置文件、部署描述文件、流水线文件等组成,并包含一个可执行的hello world程序。下图是ALB + Lambda模板代码的目录结构,具体说明如下。

    在这里插入图片描述

    (1)说明书即README.md,内容包含模板的名称和使用说明。

    (2)functions目录包含了一段可执行的代码,例如一个返回hello world的API,开发人员可以基于此进行二次开发,实现自己的业务逻辑代码,示例如下。

    func GetHelloWorld(ctx context.Context, req *model.Request) (interface{}, error) {
    InitConfig()

      log.Println("Hello World!")
      log.Printf("Request path: %v", req.Path)
    
    
      //get parameter value from Lambda env
      DomainServiceUrl := os.Getenv("Bingo Service")
    
    
      message := fmt.Sprintf("Message: Hello, Bingo! Bingo service url is [%s] (Time: %s) ",
          DomainServiceUrl, time.Now().UTC().String())
      return message, nil
    

    }

    // Init Viper Config from Environment Variables.
    func InitConfig() {
    v := viper.New()
    v.AutomaticEnv()
    config.Set(&config.Config{Viper: *v})
    }

    (3)Makefile文件定义了单元测试、测试覆盖率、打包等命令。这些命令是约定俗成的,会整合到持续集成的流水线中。

    (4)配置文件是给开发环境、预发布环境、生产环境等环境使用的配置变量。

    (5)部署描述文件是基于yaml的DSL,用来描述AWS云原生的部署内容。在服务实际部署时,DSL文件会被转成基础设施编排工具Terraform可以识别的tf文件。部署描述文件的代码如下。

    bingo-alb-template bingo config

    application: bingo-alb-template

    common:
    tags:
    Project: Bingo
    App: ALBTemplate

    lambda functions

    functions:
    - name: HelloWorld # required!
    handler: hello # required! binary name
    runtime: go1.x # optional, default go1.x
    description: API of bingo hello # optional
    timeout: 10 #optional, default 6s
    environment:
    - hello_env

    events:
    alb:
    - priority: 1
    conditions:
    path: # path is array to support multiple path
    - /bingo/hello
    method: # method is array to support multiple http METHOD
    - GET
    functions:
    - name: HelloWorld
    weight: 100

    在上述示例中,模板名称为bingo-alb-template,AWS Tag是Project: Bingo和App: ALBTemplate。模板还包含一个名为HelloWorld的Lambda、一个环境变量hello_env,以及一个指向此Lambda的的ALB。ALB对外暴露了一个路径为/bingo/hello的HTTP接口。而hello_env则定义在配置文件当中。

    (6)流水线文件是用来触发持续集成流水线的模板文件。

    全生命周期的管理

    Bingo平台支持服务的全生命周期的管理,,如下图所示,提供了从设计到开发,从集成到部署再到运维的支持。

    在这里插入图片描述

    1.设计阶段

    在设计阶段,平台通过服务模板提供服务设计的最佳实践。可以参考最佳实践来进行需求的调研和AWS云原生的调研,从而避免从零开始设计新服务。也可以提炼总结新的最佳实践,并以模板代码的形式贡献到Bingo平台上,供未来使用。

    1. 开发阶段

    在开发阶段,平台支持快速的搭建新的服务。创建新服务需要选择模板,并填写服务的名称、描述、Git仓库的名称、Git组织的名称、持续集成流水线及服务的标签,如下图所示。

    在这里插入图片描述

    其中,Git仓库、Git组织用来唯一指定服务代码的位置。持续集成流水线会有一个默认值,指向一个预先创建好的公共的流水线。可以选择使用默认流水线,也可以填写单独搭建的流水线的地址。服务的标签特指AWS Tag。我们使用Project+App+Service三级Tag来区分不同的服务。AWS Tag非常重要,首先,可以用Tag定义服务的唯一标识,便于资源的管理;其次,可以基于Tag于AWS开销进行统计,并定期清理没有Tag的资源;最后,可以基于Tag做好资源权限的隔离。

    在Bingo UI上填好服务信息后,点击“CREATE”按钮即可自动创建服务模板,流程如下图所示。

    在这里插入图片描述

    具体来说,自动搭建的功能包含下述步骤。

    (1)验证服务的Git组织是否存在,如果不存在则退出。

    (2)验证服务的Git仓库是否存在,如果存在则退出,否则创建服务的Git仓库。

    (3)赋予当前用户Git仓库的开发权限。

    (4)根据服务模板的名称找到对应的模板的Git仓库,然后克隆到平台服务器端。

    (5)根据用户需求对模板代码进行编辑。如将模板名称替换成服务名称、按需增加或者减少公共组件库等。

    (6)将代码的Git远端从模板的Git仓库修改成服务的Git仓库。

    (7)使用Git命令提交代码并push到远端,从而完成框架代码的生成。

    (8)平台服务器端清理临时文件,并将结果写入平台的数据库。

    (9)开发人员基于Git仓库中的框架代码进行后续的业务开发。

    新建的服务是一个可执行的hello world代码框架,同时会自动对接好持续集成持续部署流水线。团队成员可以直接打包和并在开发环境进行部署,也可以通过ELK查看服务日志。

    1. 集成阶段

    持续集成的流水线由开发人员创建新服务时候指定。我们推荐使用默认的公用流水线,从而减少维护成本。以触发公共集成流水线为例,部分代码如下。

    stage(“Bingo_CI_Trigger”) {
    steps{
    script {
    if ("KaTeX parse error: Expected '}', got 'EOF' at end of input: …MMIT", value: "{GIT_COMMIT}"), string(name: “service_name”, value: “ s e r v i c e n a m e " ) , s t r i n g ( n a m e : " r e p o g i t u r l " , v a l u e : " {service_name}"), string(name: "repo_git_url", value: " servicename"),string(name:"repogiturl",value:"{SSHGitUrl}”)
    ])
    } else {
    // fullci trigger
    Triggered_Build = build(job: “UI/UI_CI/bingo/Bingo_FullCI_Pipeline”, propagate: false, parameters: [
    string(name: “GITHUB_TRIGGER”, value: “true”), string(name: “GITHUB_BRANCH”, value: “ B R A N C H N A M E " ) , s t r i n g ( n a m e : " s e r v i c e n a m e " , v a l u e : " {BRANCH_NAME}"), string(name: "service_name", value: " BRANCHNAME"),string(name:"servicename",value:"{service_name}”), string(name: “repo_git_url”, value: “${SSHGitUrl}”)
    ])
    }
    if (Triggered_Build) {
    Downstream_Url = Triggered_Build.absoluteUrl
    Downstream_Res = Triggered_Build.result
    echo “DownStream Build Result: KaTeX parse error: Undefined control sequence: \n at position 18: …ownstream_Res} \̲n̲{Downstream_Url}”
    if (Downstream_Res != “SUCCESS”) {
    err_message = “Build Result: ${Downstream_Res}”
    ep_tools.highlight_info(“error”, err_message)
    }
    }
    }
    }
    }

    每个Pull Request会触发subci,验证代码是否可以编译,单元测试是否可以通过。只有subci成功后代码才可以被合并。代码合并会触发fullci,触发单元测试、回归测试,并生成测试覆盖率报告。fullci会调用平台提供的bingo命令行工具对部署描述文件做格式校验,并对部署描述文件和服务代码分别打包,再上传到远端的Artifactory服务器,供部署使用。团队成员可以使用命令行工具在本地环境验证部署描述文件的正确性。

    1. 部署阶段

    开发人员完成开发后,可以在平台上完成一键部署。

    以Serverless服务的部署为例,开发人员选择AWS账号、AWS region、部署的环境,并填写服务的版本号,然后点击部署即可。

    部署流水线会从Artifactory服务器下载服务的tar包,解压后将Lambda的二进制文件以zip的形式上传到S3上,然后从Artifactory服务器下载部署描述文件包,并将其转成Terraform可以识别的tf文件,最后使用Terraform完成服务的部署,同时将配置文件以环境变量的形式应用到Lambda上。

    生成的tf文件会包含AWS标签、Lambda对应S3的地址以及其他AWS配置参数。tf文件会上传到GitHub代码库中。这样一来,只需要简单地修改参数就能完成不同环境的部署,或者对Lambda的zip包进行替换。代码如下。

    module “Alblambda-Bingo-BingoAPI-” {

    source = “…/module/bingo/alblambda/v1_0_0”

    tags = {
    ENV = “${var.ENV}”
    Project = “Bingo”
    App = “BingoAPI”
    Service = “”
    Owner = “”
    }

    ticket = “ODP-1000”
    enable_alb = true
    enable_log2elk = true
    lambda_pkg_s3 = “ v a r . l a m b d a p k g s 3 " l a m b d a p k g v e r s i o n = " v 39 − r e v 20210816 − 123456 − a w s " a l b d n s n a m e = " b i n g o d e m o . {var.lambda_pkg_s3}" lambda_pkg_version = "v39-rev20210816-123456-aws" alb_dnsname = "bingo_demo. var.lambdapkgs3"lambdapkgversion="v39rev20210816123456aws"albdnsname="bingodemo.{var.domain_name}”

    lambda_functions = [
    … …
    ]

    alb_rules = [
    {
    priority = 1

      conditions = {
        http_request_method = ["GET"]
        path_pattern = ["/bingo/hello"]
      }
    
    
      functions = [
      ]
      target_groups = [
        {
          arn    = "......"
          weight = 100
        }
      ]
    }
    

    ]

    }

    1. 运维阶段

    Bingo平台还对服务的运维进行了支持。Bingo平台和基于ELK的日志解决方案进行了自动对接,屏蔽了烦琐的配置细节。仍旧以Serverless服务为例,日志收集流程如下图所示。

    在这里插入图片描述

    服务产生的原始日志会被CloudWatch收集。而Log Lambda会将Cloudwatch中的日志写入到Kafka,再由ELK消费日志。从Cloudwatch到ELK的过程对团队人员透明,服务部署成功后开发人员即可在ELK中查看服务的日志。

    此外,Bingo平台也我们团队使用和基于Jaeger的分布式追踪系统进行了自动对接,从而对服务的上下游进行追踪。

    4

    展望未来
    Bingo平台作为云原生的低代码开发平台,短短数个月的就取得了巨大的成功。平台极大地缩短了团队搭建新服务的时间,减少了开发和维护的成本,加强了跨职能团队的协作。

    平台在未来会持续的提供不同的服务模板,沉淀云原生的最佳实践,进一步增强平台扩展的能力。越来越多的服务登陆Bingo平台又将促进应用黄页的诞生。我们期待着打造一体化的可复用平台,构建Bingo的生态体系。

    《云原生应用架构:微服务开发最佳实战》一书从真实案例出发反推技术难点,汇聚名企一线工程师的真知灼见!

    一网打尽微服务、云原生、服务网格、敏捷开发、分布式事务、无服务器架构、可观察性、质量保证、CI/CD等前沿话题,热点技能各个击破!

    要想了解更多有关名企云原生微服务最佳实战的相关话题,就来读一读《云原生应用架构:微服务开发最佳实战》吧!

    在这里插入图片描述

    FreeWheel成立于2007年,是美国传媒巨头康卡斯特集团旗下的高端视频广告技术供应商,在北京、纽约、旧金山、芝加哥、伦敦、巴黎等地设有分支机构。FreeWheel核心业务系统开发团队在多年的实践中探索出了一条云原生微服务应用构建之路。

    本书基于这些实践经验,从设计、开发到测试、部署,介绍了团队如何利用云原生技术为应用开发的全生命周期赋能。从架构技术选型到具体工程实践,书中内容理论联系实际,较为全面地剖析了容器落地、服务网格、无服务器计算、持续集成和持续部署等核心云原生技术,适合关注微服务、云原生技术的架构师、工程师及技术决策者阅读。

    在这里插入图片描述

    京东满100减50,扫码即购!

    在这里插入图片描述

    展开全文
  • 文章目录云计算在我们身边数字化转型国内云计算公司简介华为信服腾讯阿里青云总结:我们该学些什么? 人生不会有太多的十年,但仅仅一个十年也可以成就很多事情。 云计算在我们身边 可能对很多人来说,...

    在这里插入图片描述

    人生不会有太多的十年,但仅仅一个十年也可以成就很多事情。

    云计算在我们身边

    可能对很多人来说,云计算离我们还挺遥远的,我们也感受不到它给我们的生活带来了哪些变化。我举一些例子吧。
    智慧城市、数字化转型、云上办公,再接地气点,百度云盘 ···
    可能有的人会觉得,这些不是物联网、大数据相关的东西吗,还有后面那个百度云盘怎么也能算云计算???
    但是,物联网、云计算、大数据、人工智能,三者本来就是密不可分的。
    云计算为物联网和人工智能提供平台与算力,大数据作为物联网的数据分析手段,其数据大多也是放在云上计算,那你说,这三者可以分割吗?

    所以,其实云计算早已来到我们身边,进入了我们的生活中。

    后面我会整理一篇对云计算和云原生到底是什么的博客,我觉得我们对云原生的学习应该是从这里开始。


    数字化转型

    2020 年,在疫情刺激下,企业数字化转型的需求增多,云计算作为必要的基础设施迎来快速增长的机遇,混合云在灵活应对各个场景下的用云需求,以及成本优势等方面表现出独特的优势,其增长潜力也逐渐成为行业共识,各大云计算厂商争相布局。国际厂商中,如微软推出了由 Azure 延伸出的 AzureStack 混合云解决方案,帮助企业在本地数据中心部署云应用;AWS 和 VMware 共同开发了 VMware Cloud on AWS 混合云解决方案;华为在 Stack(HCS)全栈云解决方案通过云联邦混合云组件,为企业提供轻量化混合云管理能力;中兴通讯推出了多云管理和混合云管理平台,通过云接入、云间互联等能力实现混合云的统一管理等等。与此同时,国内云计算厂商也能以敏锐地感知到行业机会,参与混合云的市场角逐。

    在这里插入图片描述


    国内云计算公司简介

    排名不分先后。我想看过这些公司的简介之后,对于当下国内云计算发展的繁荣程度也就不用我多说什么了。

    华为云

    在这里插入图片描述

    直接抓关键词:共建世界智能云底座。
    这两年领了不少华为云社区的礼品,我发现一个很有意思的事情,就是这些礼品,都可以绑定到华为云平台上。大件的如空气净化器,小件的如手表、牙刷、水杯。也参与过一些华为云举办的云计算峰会和论坛,感觉华为的云生态做的确实挺好的。

    了解不多,各位可自行查阅官网。


    信服云

    在这里插入图片描述

    抓关键词:让每个用户数字化更简单,更安全。

    这我熟。

    信服云,传统数据中心云化演进的优选方案。聚焦用户数字化转型各阶段核心问题,以创新实用的产品、服务和解决方案,致力于为政府及企事业单位交付省时省事、平滑弹性、安全可靠、业务承载丰富的云数据中心,帮助用户解放生产力,专注业务创新。

    深信服云原生平台(Sangfor Cloud Native Platform)是一个基于容器技术,全面集成Kubernetes,并深度支持 DevOps 及微服务治理的全栈式云原生PaaS 平台。云原生平台可以帮助用户简化部署、监控、运维等容器应用生命周期管理工作,同时提供DevOps 流水线、微服务治理的管理及运维能力。帮助用户实现传统应用容器化改造及新型应用的快速上线,为数字化转型降本提效。

    容器平台在Rancher2.3.3版本基础上构筑了安全、可靠、易用的容器管理能力。提供标准化开发、测试、运维流程;根据业务峰值,弹性扩容,实现应用秒级调度、部署、运行。Docker 容器提供内核级的虚拟化,帮助企业节省基础设施成本。


    腾讯云

    在这里插入图片描述

    抓关键字:产业数字化助手。

    腾讯云,腾讯集团倾力打造的云计算品牌,面向全世界各个国家和地区的政府机构、企业组织和个人开发者,提供全球领先的云计算、大数据、人工智能等技术产品与服务,以卓越的科技能力打造丰富的行业解决方案,构建开放共赢的云端生态,推动产业互联网建设,助力各行各业实现数字化升级。


    阿里云

    在这里插入图片描述

    青云

    第一家以混合云上市的公司。

    在这里插入图片描述


    总结:我们该学些什么?

    实不相瞒,写到这里我已经发现这篇就这样了。

    作为一个云计算部门的实习生,我来谈一谈自己对于要入这个领域的门的感受吧,不一定对,跟其他同类型的文章契合度也不一定高。

    1、学一门主语言。
    建议是 C++。因为 C++ 要转其他语言是很快的,降维打击。我刚入职的时候九天学了四个语言,还好我会 Python,不然还得多学一个。
    云原生的开发多是基于 go 语言的,而 go 语言的开发者一个是 C++ 之父,一个是 Python之父,就酱。
    云原生的部署多是基于 Ansible 的,因为其它的更难。由于大部分公司的历史原因,shell 语言也可以说是必备的技能。
    Python,现在做开发好意思说自己不会 Python 吗?
    Yaml,Ansible 的语法是基于 Yaml 的,DockerFile 也是。

    and so on。基于此,我建议以 C++ 作为主语言。

    2、DevOps 思想。
    Dev 是 开发的缩写,Ops 是运维的缩写。DevOps 是敏捷开发的思想,是一种持续集成,快速交付的思想。
    我想是应当具备的。

    3、容器及容器编排。
    容器建议 Docker,容器编排建议 k8s,共识。

    4、操作系统、计网基础 等。
    5、MySQL、Redis 等中间件。

    把 4/5 和在一起讲吧。云计算提供的是一个平台,是把原先放在大型机器上运行的程序放到云上运行,并不意味着我们可以忽略原先支撑那些程序运行起来的技术。恰恰相反,我们需要了解的更多,因为迁移,会触发到很多的特性。

    6、源码剖析能力 && 英文阅读能力、
    前面的能力决定你能不能走进来,而这两个能力决定你能走多远。

    展开全文
  • 关注「开源Linux」,选择“设为星标” 回复「学习」,有我为您特别筛选的学习资料~ 1带你了解云原生技术图谱如果你研究过云原生应用程序和相关技术,大概率你遇到过 CNCF 的云原生全景...
  • 云原生本身甚至不能称为是一种架构,它首先是一种基础设施,运行在其上的应用称作云原生应用,只有符合云原生设计哲学的应用架构才叫云原生应用架构。 云原生的设计理念 云原生系统的设计理念如下: 面向分布式...
  • hi, 大家好,如今几乎所有大厂都将容器和K8s列入未来的战略重心,K8s可能将成为下一代分布式操作系统,今天分享一篇很经典云原生文章(万字雄文),希望可以帮大家彻底了解到底什么是云原生。...
  • 就有必要进行服务化拆分了,包括拆分为微服务架构、小服务(Mini Service)架构,通过服务化架构把不同生命周期的模块分离出来,分别进行业务迭代,避免迭代频繁模块被慢速模块拖慢,从而加快整体的进度和稳定。...
  • 云原生存储和云存储有什么区别?

    千次阅读 2019-11-06 16:14:37
    导读:新的企业负载/智能工作负载容器化、迁云、存储方面遇到的性能、弹性、高可用、加密、隔离、可观测以及生命周期等方面的问题,不但需要存储产品层次的改进,更需要在云原生的控制/数据平面的改进,推进...
  • 主要介绍云原生架构原则
  • 前言9 月初给 BG 的新人开了一门课,专门来讲云原生技术,云原生技术从出现到现在按最早的时间出现来说也是有 10 多年了。尤其是这几年火热的不得了,但是 cloud native 这个外...
  • 什么是云原生云原生之前 云原生 云原生简介 微服务 DevOps 持续交付 容器化 云原生的发展历程 云原生技术生态现状 云原生基金会 —— CNCF 云原生技术社区 云原生技术产业 我们正处于时代的关键节点...
  • 云原生和云计算的区别是什么?小编从非技术的角度来给大家整理一下,普通人都能看得懂! 什么是云计算? 百度解释:云计算是分布式计算的一种,指的是通过网络“云”将巨大的数据计算处理程序分解成无数个小程序,...
  • 云原生背景介绍与思考 图是基于 ECS 底座的 EMR 架构, 这是一套非常完整的开源大数据生态, 也是近 10 年来每个数字化企业必不可少的开源大数据解决方案。 主要分为以下几层: ECS 物理资源层, 也就是 Iaas 层。...
  • “一个互联网技术玩家,一个爱聊技术的家伙。在工作和学习中不断思考,把这些思考总结出来,并分享,和大家一起交流进步。”前言9 月初给 BG 的新人开了一门课,专门来讲云原生技术,云原生技术...
  • 类似于云原生+大数据这样技术的“强强联合”将成为云原生时代的发展趋势,运维和基础软件开发者、服务端和前端开发者所关注的技术点各有不同。
  • 云原生模式读后感(一)

    千次阅读 2020-10-28 14:34:19
    第一部分云原生上下文 1.什么是云原生 (1)即使遇到基础设施不断变化甚至发生故障的情况,云原生应用程序依然可以保持稳定。 (2)现代应用程序的关键要求是支持快速迭代和频繁发布新版本、零停机时间以及大量新的设备...
  • 随着云原生生态系统的发展,对DevOps和DevSecOps团队的需求越来越大,他们需要在开发和部署周期的早期识别并解决安全和合规问题。 企业需要在几分钟(而不是几个月)的时间内发布软件。 为了做到这一点,那些...
  • 云原生与12因素

    2022-02-13 17:32:34
    12因素是云原生应用的设计理念,用于指导开发者充分利用云平台提供的优势开发出易维护、高可靠和便于扩展的应用程序。具体内容如下: Codebase: 基准代码,一份基准代码多分部署。用一个代码长裤进行版本控制和...
  • 什么是 云原生

    2020-12-16 21:14:46
    云原生”这个词被大量引用,尤其是云服务商。不仅如此,云原生甚至还有自己的基金会:由Linux基金会于2015年推出的云原生应用基金会(CNCF)。“云原生”定义在一般用法中,“云原生”是一种构建和运行应用程序的...
  • 把应用迁移到云上就是云原生架构吗?什么才是云原生架构?为什么要作云原生架构?本文告诉你,除了把应用搬到云上,要实现云原生,你还要做很多。
  • 什么是云原生中台业务架构?

    千次阅读 2022-04-12 20:33:36
    什么是云原生中台业务架构? 最近公司说要做中台架构,业务中台,技术中台,数据中台,很谦虚的请教一下,什么是业务中台?业务中台是什么样子的,它是一个什么样的产品,是一个个的业务系统吗,业务中台还有没有...
  • 云原生的不同解释及正确含义

    千次阅读 2019-12-12 19:28:00
    云原生的解释可以说五花八门,本文从不同角度探讨云原生的内涵以及如何从不同维度准确理解它的含义。 云原生起源 网上有些文章提到云原生是“Pivotal公司的Matt Stine于2013年首次提出云原生(CloudNative)的概念”...
  • 目录 日志记录( Logging) 是什么 解决了什么问题 它如何解决 相应的解决工具 监视( Monitoring ) ...在《叮,你收到一份来自CNCF的云原生景观简介》中,我们对CNCF云原生生态系统做了概述。 在《云原生景.
  • 目录概括云计算发展市场云技术云安全云原生技术中间件ServerlessSaaS分布式云分类中心云区域云边缘云从中心到边缘边缘云边缘终端云边协同云原生安全架构重塑引起的端到端安全挑战容器镜像链路追踪问题微服务端口暴露...
  • 前文中,我们分析并讲述了云原生技术体系在传统企业数字化转型过程中的价值和意义,并重点描述和分析了云原生技术体系如何重构传统企业零散分布式的异构基础设施,进而实现底层分布式异构基础设施的大一统和上层丰富...
  • 云原生是不是未来的趋势?如何落地是个问题? 谈到云原生,不管从技术角度还是从业务角度出发,很多人对云原生众说纷纭,但结论不同。我咨询过很多在云计算这个领域里面的专业人士。有人说云原生就是容器、微服务、...
  • 作者 | 侯淼淼出品 | CSDN(ID:CSDNnews)云原生这个词对于业内大多数人来说都不陌生,伴随着云计算的蓬勃发展,大有愈演愈烈之势,已经赫然成为企业数字化转型的重要基石。与此同...
  • 您能否以每周为单位向客户发布...事实上,这种快捷的发布周期需要配合一系列流程、工具甚至是管理文化,从而共同支撑起一套安全且可靠的云原生应用程序运作机制。而这也成为软件驱动型企业的核心战略因素之一,其目...
  • 云原生落地实践的25个步骤

    千次阅读 2020-06-01 08:13:30
    其实我们在很多的技术大会上,看到的都是分层架构图,就像上一节我们分的六个层次一样,这容易给希望落地云原生的企业造成误解,因为大部分公司的云原生体系的建设都不是按层次来建设的,不会IaaS完全建设完毕,再...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 15,018
精华内容 6,007
热门标签
关键字:

云原生的必要性