全球卓越的K8S集群构建厂商,为你揭开云原生面纱
2019 年 6 月 24 日至 26 日,由 Cloud Native Computing Foundation (CNCF) 主办的云原生技术大会 KubeCon + CloudNativeCon + Open Source Summit(上海)即将在中国上海盛装启幕。
作为业内顶级“盛宴”,KubeCon + CloudNativeCon 和 Open Source Summit(原 LC3)自 2015 年开始吸引了社会各界人士关注。
本届 KubeCon 将吸引来自全世界数千名技术人员参加此次盛会,参与 CNCF 全部项目和话题的深度探讨,以及案例分析,聆听 CNCF 项目的运维者和用户的分享。
在本次 KubeCon 上,京东云将在大会上为对云原生感兴趣的研发和运维人员带来《利用延迟加载快速启动 Docker 容器》的话题分享。
在展会来临之际,我们专门梳理了 CNCF、K8S、微服务架构、交付与云原生之间关系,同时给出了我们关于如何构建云原生的应用 Tips。帮助大家全方位深入了解云原生。
计算机领域每过几年都会产生一些新的概念出来,网格计算、云计算、物联网、微服务、区块链、边缘计算… …
每一个新概念都很难从名称直接看出来它的含义,所以一开始大家都会问到底什么是 X 计算,几年后再说起 X 计算大家却似乎都知道了,但是如果让他们解释一下,大多数人还是会解释不清楚。
今天聊的主角“云原生”(Cloud Native)也是一样。(关于云原生的定义众说纷纭,本文的介绍仅代表个人理解,欢迎指正。)
云原生是利用云快速交付应用的一种方式
Pivotal 公司是云原生概念的早期推广者,同时也是 Spring 框架和 Spring Cloud 的主要贡献者,它对云原生的定义是:
“Cloud-nativeis an approach to building and running applications that exploits theadvantages of the cloud computing delivery model.”
——云原生是利用云交付效率的优势来构建和运行应用的方式。
同时,他还补充道:
“Organizationsrequire a platform for building and operating cloud-native applications andservices that automates and integrates the concepts of DevOps, continuousdelivery, microservices, and containers.”
——组织需要一个平台来构建和运行云原生应用,这个平台要包含 DevOps,持续交付,微服务和容器。
简单总结一下,也就会说云原生的目的是为了充分利用云的能力使应用交付更快。为了达到这个目的,将用到 DevOps、持续交付、微服务和容器等理念和技术。
此外,提起云原生,业内人士还会提到另一个词:云原生基金会。那么云原生和云原生基金会(Cloud Native ComputingFoundation,简称 CNCF)又是什么关系呢?
云原生基金会致力于推广云原生计算模式,并维护一个厂商中立的开源生态系统来普惠大众。
云原生计算使用开源软件栈来构建微服务,打包为容器,并且动态编排容器来最大化资源利用。
CNCF孵化了软件容器领域的一个值得关注的 Kubernetes 项目以及围绕它的很多其他项目,而 Kubernetes 目前已经成为云原生应用的重要基石。
所以,云原生是一种理念和应用交付模式,云原生基金会是以推广这种理念和模式,孵化支撑这种模式的开源项目。
注意,这里的“云”并不特指公有云,而是泛指可动态提供资源的各种平台。要应用云原生,会涉及到一些核心的技术:微服务、容器、交付。下面看一下为什么云原生会强依赖这些技术。
微服务、容器、交付
微服务简单来说就是将应用所需要的功能拆分成一个个小型独立的软件服务,即“微服务”。
每个微服务专注于自己的任务,可被独立部署、更新、伸缩和重启,同时基于 API 彼此通讯来进行协同工作,以形成大型可伸缩应用程序。
微服务最重要的点不是把服务拆的有多小,而是把除了应用本身关注的业务以外的其他逻辑都拆除出去。
应用开发者不用去关心其他应用在哪里,不用去实现其他应用失效了怎么去重试怎么容错的逻辑,不用去为灰度和 AB 测试等需求开发代码,也不需要去实现逻辑来监控应用运行状态… …应用开发者就只专注于实现业务逻辑。
同时,每个服务要实现的业务逻辑尽可能清晰,尽可能是高内聚的一组功能。
容器是应用的运行环境,是微服务的最佳载体。运行在容器而不是虚拟机,性能上的优势是一方面,更重要的是关注主体发生了变化。
当运行一个虚拟机时,值得关注的主体是这台虚拟机,里边到底有多少种应用、具体是什么应用这并不是重点。
而当运行一个容器时,关注点是放在容器中打包的那个应用,应用是整个动作的中心。
但是也不能说用了虚拟机就一定不是云原生,利用虚拟机实现基于云的快速交付,也是云原生的另一种最佳实践。
交付是将容器中的服务真正用起来的过程。传统运维关注点在于一个一个的运维动作,而面向交付的运维重点在应用本身。
关注的是应用最终需要提供多少个实例或者支持多少并发调用,这些运维的动作不应该是应用的关注点,应该全由底层平台解决。
因此,有了声明式模型,应用只说需要几个实例,平台自己想着怎么启动,当有设备故障时怎么恢复;有了无服务器架构,应用根本不关注实例个数和启停逻辑,平台根据调用压力动态分配计算资源。
之所以很多人一提到云原生就想到 Kubernetes,一方面因为 Kubernetes 是云原生基金会孵化的代表作,另外一方面也和它的能力有很大关系。
作为市场领先的编排解决方案,Kubernetes 正是实现了将应用以容器的方式快速交付,让应用不用再关注系统和网络差别,不用再关注部署和伸缩细节,并且具备丰富的生态(如 Istio,Envoy,Prometheus,Jaeger 等),提供应用的微服务治理能力,解决应用上云这个难题。
构建云原生的应用
知道了什么是云原生,那要如何让应用更好地符合云原生的交付模式呢?
首先,你需要有一个云。这个云不一定是公有云,也可以是私有云,混合云,甚至是区块链服务,也可以是任何其他形式动态提供资源的平台。
这个云需要具体如下基本能力:
管理程序包/容器镜像/虚机镜像的能力
弹性将应用通过容器/虚拟机等方式交付的能力
对应用进行灵活的服务治理的能力
对应用的各种状态进行临时/永久存储的能力
对应用的安全性提供保障的能力
其次,你要有用云的能力,不要在应用里去实现应该云平台提供的功能。有些团队用云服务只敢用云主机和存储,担心使用云的其他能力会被这个云服务绑定。
有这个担心是对的,但是更好的方式应该是选择更开放、更兼容的云产品来使用。
例如京东云的 Kubernetes 集群、微服务平台都是与开源项目完全兼容的,可以放心使用,不喜欢了也可随时切换到自己运维的开源项目上。
同时,你还需要改造你的应用,使之能更好的适用于在各种云平台上快速交付。
关于云原生应用该如何设计,Heroku 团队提出的十二要素(Twelve-Factor)提供了很多非常有价值的建议。
十二要素包含:
序号 |
要素 |
含义 |
1 |
基准代码(Codebase) |
应用对应唯一的基准代码,使用此基准代码多次部署。 |
2 |
依赖(Dependencies) |
明确定义依赖清单,不要隐式依赖第三方库和工具。 |
3 |
配置(Config) |
需要在不同部署时改变的配置项应该放在环境中,不要包含在代码中。 |
4 |
后端服务(Backing services) |
所有后端服务看做可附加的资源,可以在运行时动态的附加和摘除。 |
5 |
构建、发布、运行(Build, release, run) |
发布过程严格区分构建、发布、运行,基于构建的包在多个环境运行,不要再改变包本身的内容。 |
6 |
进程(Processes) |
应用保持无状态,将状态数据存储在云提供的后端服务。 |
7 |
端口绑定(Port binding) |
应用通过端口对外提供服务(不是ip+端口)。 |
8 |
并发(Concurrency) |
通过对应用进程水平伸缩来支持高并发。 |
9 |
易处理(Disposability) |
可以快速启动和优雅终止,以便达到更好的健壮性。 |
10 |
开发/线上环境等价(Dev/Prod parity) |
尽可能的保证开发、预发布、线上环境相同,不存在代码差异和操作差异。 |
11 |
日志(Logs) |
应用产生的日志作为事件流有运行环境的云服务进行收集和存档。 |
12 |
管理进程(Admin Processes) |
后台管理任务也和普通应用一样处理,例如一样管理代码、构建和发布,差别仅在于任务为一次性进程运行。 |
按照十二要素的要求,编码、开发、构建、运维等操作都需要被清晰界定和规范,应用需要专注在业务逻辑,将部署环境、运行依赖,状态保存、并发、日志等问题都交给云平台来处理。
云原生应用的开发过程变成:快速响应业务需求开发精简的应用构建标准包,然后在不同的环境以不同配置动态部署,运行的各种依赖利用云平台解决。
按照这些原则去设计自己的应用,应用会更易于使用云服务提供的标准能力,会更易于实现快速交付,更易于进行灵活扩展。
在十二要素发布后,Pivotal 公司的 Kevin Hoffman 编写的 Beyond theTwelve-Factor App 一书中,又增加了三个新要素作为补充:
1 |
API优先(API first) |
需要设计出合理、高兼容性的API作为服务间交互的契约。 |
2 |
观测(Telemetry) |
应用提供需要观测的数据,观测系统进行收集和展现。 |
3 |
认证和授权 (Authentication and Authorization) |
需要考虑认证和授权等安全问题,结合云平台提供的安全能力。 |
最后,要构建云原生的应用,下面是在应用研发上线过程中的一些建议:
代码里应该重点关注业务逻辑而不是其他
代码尽量不要有任何状态,状态都存到云服务里
代码里不要有和本应用无关的业务逻辑,它应该在其他应用里通过 API 调用
不要实现用于运维和服务治理和观测的具体逻辑,要依赖第三方库和云服务
不要硬编码地址等任何配置,这段代码要运行在很多环境
不要假定这段代码会部署在什么地址,会部署几个实例
不要假定程序永远不死,要保证单个实例的死去不要影响其他实例
构建结果是一个整体,不能把构建的代码部署后再去改动代码包里的内容
关于云原生,我们在做什么?
云原生聚焦的是如何在 IaaS 基础构建之上创建有效的应用平台,而为企业级信息应用提供更好的技术环境也正是京东云的使命。
京东云,作为具有强产业属性的云智能厂商,在云原生技术的大量投入来自于自身业务的需求,从电商的前端网站、订单、结算、支付、搜索、推荐,到后端的仓储、配送、客服、售后,以及采销人员使用的各种业务系统都面临前所未有的挑战。
京东几千个系统,几万个应用,每一个环节正常工作才能保证整体业务顺利运行。云原生技术正是承载京东零售科技的技术基石。
经过多年的实践,京东构建了全球最大的 Kubernetes 集群,积累了大量的云原生开发和运维经验,并且加入云原生计算基金会成为最高等级的白金会员。
作为社区一员,京东云也会积极采用 CNCF 的项目、参与开发贡献并与其他成员一同合作共建社区。
在即将开始的KubeCon + CloudNativeCon和Open Source Summit(China,2019)活动中,我们的技术专家在现场将为大家带来《利用延迟加载快速启动 Docker 容器》话题分享。
通过京东云研发的容器镜像延迟加载技术,优化 Docker 镜像的加载过程,显著提高容器的启动速度。
同时,还有《Kubernetes 中 MySQL 容器的正确大小和自动扩展》、《使用 Vitess 的两年:京东如何运行全球最大的 Vitess》、《在 Kubernetes 中经济高效地调度大量容器》的主题演讲。
京东云 2016 年开始对集团外部提供服务以来,逐渐将集团内部多年积累的云原生开发和运维能力标准化为 Kubernetes 集群、微服务平台、Devops、函数服务、云安全、API 网关等上百种标准的云服务,方便客户利用京东云服务的强大能力,快速、安全、高可靠地交付产品。
扫描二维码,加入京东云开发者社区
点击”阅读原文“,可了解更多云原生相关信息
- 揭开J2EE集群的神秘面纱(一)
- 系统架构--揭开J2EE集群的神秘面纱(三)
- 揭开J2EE集群的神秘面纱(六)
- 揭开J2EE集群的神秘面纱(二)
- 系统架构--揭开J2EE集群的神秘面纱(四)
- 揭开J2EE集群的神秘面纱(七)
- 为你揭开投行、咨询的神秘面纱
- 揭开J2EE集群的神秘面纱(三)
- 系统架构--揭开J2EE集群的神秘面纱(五)
- 揭开J2EE集群的神秘面纱
- 为你揭开PCB的面纱 感受她的美与好
- 系统架构--揭开J2EE集群的神秘面纱(六)
- 揭开J2EE集群的神秘面纱(二)
- 揭开J2EE集群的神秘面纱(四)
- 揭开J2EE集群的神秘面纱(三)
- 揭开J2EE集群的神秘面纱(五)
- k8s原生的集群监控方案(Heapster+InfluxDB+Grafana)
- 揭开J2EE集群的神秘面纱(五)
- 揭开J2EE集群的神秘面纱(六)
- 揭开J2EE集群的神秘面纱(七)