云原生趋势报告
根据 IT 资讯公司 Capgemini 的最新研究: 到 2020 年, 云原生架构将成为面向客户的应用首要选项, 当然, 这一举措的前提是公司的领导层对于云原生这个概念有充分的了解以及愿景.
Capgemini 公司调查了 11 个国家的 900 多位资深专业人士, 发现 15% 的企业应用, 都以云计算为基础, 而到 2020 年, 这个数字将上升到 32%.
转向云原生应用的主要原因有: 提高开发部署交付等速度 (74%), 更好的进行团队协作(70%) 和改善用户体验 (67%), 使用敏捷和 DevOps 的方法和自动化的应用部署, 具有极强的云实践能力公司在这一趋势中一直处于领先地位. 这些公司也更倾向于以增长为中心的 IT 功能, 改善客户体验(90%), 提高业务敏捷性(87%) 和可伸缩性 (85%) 被视为是比降低成本的优先级更高.
不过, 这对于 CIO 来说是一种新的挑战, CIOS 的调查指出, 整合云原生应用和传统基础设施的困难是一个绊脚石, 因为与现有的应用提供商的合同, 网络安全和数据保护以及本地基础设施的成本方面都会面临着许多问题.
但他们也必须与业内大咖们的根深蒂固的态度进行斗争, 三分之二 (65%) 的受访者表示, 他们希望对传统文化进行革新, 70% 的受访者认为, 技能上的不足是一个很大的问题, 62% 的人指出与遗留基础设施的融合是一项挑战.
根据 Capgemini 的调查: 亚马逊, 苹果, 谷歌, Netflix,Airbnb,Uber 和 Deli veroo 等公司都通过使用应用作为差异化竞争优势的关键来源, 它们的成功源自能够采用云原生应用的开发方法充分利用云的弹性.
报告称: 在云端直接构建应用, 并使用模块化的微服务架构, 意味着这些创新者可以更快速创新并扩大新产品的规模, 实现业务速度和灵活性, 这对那些依赖于单片系统的企业来说是不可能的.
构建云原生业务的 6 个步骤:
Capgemini 为寻求建立云原生业务的企业提供了 6 步线路图:
评估应用组合并确定云原生开发的优先级
通过展示云路线图和交付增长的能力建立信誉
从小做起, 再去想扩大规模, 发展一个高技能的团队
调整 IT 操作模型以支持业务的敏捷性和稳定性
在选择技术时要注重实效
培养一种创新, 协作, 测试和学习的文化
云原生工具 & 框架
在确定应用云原生以后, 企业需要根据自身的实际情况, 按照本文选取开发框架 & 工具:
1,Kubernetes
在过去的两年中, Kuberentes 已成为火爆的开源项目之一, 毫无疑问, 在未来 Kuberentes 的势头会更劲, 其拥有大量的扩展工具, 其优势在于:
通过基于角色的访问控制可以更好地支持企业部署
将 Kuberentes 从单一用户操作系统转移到 Unix
支持在 Kubernetes 管理的容器和容器中运行有状态应用
当然, 除了 Kuberentes 容器调度器外, CNCF(云原生基金会)还提供了一套广泛的兼容工具, 用于操作和交付现代分布式系统, 这些组合创建的功能可以扩展到成千上万个自修复的多租户节点上, 同时还可以实现操作上的差异.
这个工具套件的关键点在于, 通过开发兼容新标准去允许持续的创新, 同时还可以以多种标准兼容的实现形式进行重复.
2,Prometheus
Prometheus 的设计初衷就就是一个通用监控系统, 它并没有设计集群, 类似 HDFS 一套东西去存储数据, 它是一种度量标准的监控系统, 旨在为监视服务提供云本地的方法.
3,OpenTracing
OpenTracing 通过提供平台无关, 厂商无关的 API, 使得开发人员能够方便的添加 (或更换) 追踪系统的实现. OpenTracing 正在为全球的分布式追踪, 提供统一的概念和数据标准.
4,Fluentd
Fluentd 是一个免费, 而且完全开源的日志管理工具, 简化了日志的收集, 处理, 和存储, 可以不需要在维护编写特殊的日志处理脚本. Fluentd 的性能已经在各领域得到了证明: 目前最大的用户从 5000 + 服务器收集日志, 每天 5TB 的数据量, 在高峰时间处理 50,000 条信息每秒.
5,Linkerd
Linkerd 是一个 "服务网格", 它是专用于处理时间敏感的服务到服务的通信基础设施层. 与传统网格物料相反, 服务网格进行请求级别操作.
6,gRPC
gRPC 基于如下思想: 定义一个服务, 指定其可以被远程调用的方法及其参数和返回类型. gRPC 默认使用 protocol buffers 作为接口定义语言, 来描述服务接口和有效载荷消息结构. 如果有需要的话, 可以使用其他替代方案.
7,CoreDNS
CoreDNS 的前身是 SkyDNS, 它的主要目的是构建一个快速灵活的 DNS 服务器, 让用户可以通过不同方式访问和使用 DNS 内的数据. 它被设计为 Caddy 网络服务的一个服务器插件. CoreDNS 的每个特性都可以被实现为可插拔的中间件, 如, 日志, 基于文件的 DNS 以及多种后端技术, 进而可以拼接多个插件来创建定制化的管道. CoreDNS 已经得到扩展, 可以直接被 Kubernetes 访问服务数据, 并以 KubeDNS 的形式提供给用户使用.
8,Containerd
Containerd 是一个控制 runC 的守护进程, 主要是为了性能和密度. Containerd 提供一个命令行客户端和 API, 在一个机器上管理容器. Containerd 使用 runC 来根据 OCI 规范运行容器 .
来源: http://cloud.51cto.com/art/201912/607995.htm