Serverless

OAM 创始团队:揭秘 OAM Kubernetes 实现核心原理

安稳与你 提交于 2020-07-28 20:50:34
作者 | Andy Shi(阿里云高级技术专家)、天元(阿里云技术专家) 今年 5 月,阿里云和微软云共同宣布, Open Application Model (OAM) 社区携手知名混合云管理项目 Crossplane 社区,联合发布了 OAM 在 Kubernetes 平台上的标准实现与核心依赖库。 本次合作达成后,OAM 社区成功的将标准应用定义和标准化的云服务管理能力统一起来,迈出了实现真正意义上的无差别云端应用交付的关键一步 。 去年 10 月 , 阿里云和微软共同推出了 OAM 项目 ,旨在构建围绕 Kubernetes 的云原生应用规范。OAM 描述了一个模型 —— 开发人员可以在其中定义应用程序组件;应用程序操作员负责创建这些组件的实例并为它们分配应用程序配置;基础架构运营商负责定义、安装和维护平台上可用的基础服务。 本次合作是阿里云、微软与 Crossplane 社区的三方技术合作,主要围绕 OAM 在 Kubernetes 上的标准实现以及 Crossplane 项目的 OAM 化展开。因为 Kubernetes 社区在落地 OAM 模型的过程中,提出了关于 OAM 标准实现的诉求。所以这次合作的一个重点,就是三方工程师使用 Go 语言开发了一个 OAM Kubernetes 核心依赖库。这个项目的名字叫做 oam-kubernetes-runtime 。OAM

Serverless 原生框架:Malagu Framework

谁说胖子不能爱 提交于 2020-07-28 20:15:02
背景 早期,Serverless Framework 的定位是偏运维侧,通过 Yaml 文件定义规则,Serverless Framework 负责部署到对应的云厂商。Serverless Framework 提供了一种方案去适配不同的云厂商。 最近 Serverless 提供了一个 Serverless Component 方案,这个方案更面向开发侧。在同一时间,Malagu Framework 也想到了 Component 类似的方案。 Malagu Framework 一开始定位就是偏开发侧的。Malagu Component 与 Serverless Component 解决的问题是一样的:适配不同平台的服务(阿里云函数计算、阿里云 oss、腾讯云函数、aws lambda 等等)和封装通用的业务代码。 Malagu Component 与 Serverless Component 设计上也存在不同的地方,后面可以单独写一篇文章介绍一下。 Malagu 由 CLI + Framework 组成,其中 Framework 本身就是基于 Malagu Component 实现。 简介 Malagu 是基于 TypeScript 的 Serverless First、可扩展和组件化的应用框架。 在 Malagu 的世界里 一切皆组件 ,应用也是组件:根组件

IT巨头齐聚首届KubeCon 2020线上峰会,开启云原生下一个十年

别说谁变了你拦得住时间么 提交于 2020-07-28 18:51:04
首届线上开源峰会“ Cloud Native + Open Source Virtual Summit China 2020 中国线上峰会 ”,将于 2020年7月30日-8月1日 举行。峰会官网「cncf.lfasiallc.cn」已经上线,会议注册免费, 诚邀全球广大的开源组织、企业、技术大咖和开发者报名参会,提前锁定这场开源界最负盛名的旗舰峰会,开启云原生下一个十年。 自KubeCon+CloudNativeCon 2018首次落地中国以来,大会每年都得到国内外众多IT巨头的鼎力支持,去年在上海圆满落幕的KubeCon + CloudNativeCon + Open Source Summit 2019大会上, 包括华为云、腾讯云、阿里云、Intel、Rancher Labs、SUSE、AWS、百度云、CloudBees、谷歌云、京东云、Red Hat等知名企业悉数到场,为参会者们奉上了一场关于开源技术的前瞻知识盛宴。 在首届线上峰会上,包括华为云、阿里云、腾讯云、HYPERLEDGER、京东智联云、LFAI、Linux Foundation开源软件大学、ORACLE Linux、TARS Foundation、易捷行云、EMQ、FUTUREWEI、NGINX、青云QingCloud、虚云科技等IT企业已确认参加Cloud Native + Open Source

Istio 网关之南北向流量管理(内含服务网格专家亲自解答)

不打扰是莪最后的温柔 提交于 2020-07-28 17:31:58
作者 | 王夕宁 阿里巴巴高级技术专家 参与阿里巴巴云原生公众号文末留言互动,有机会获得赠书福利! 本文摘自于由阿里云高级技术专家王夕宁撰写的《Istio 服务网格技术解析与实践》一书,文章介绍将集群外部的客户端连接到集群内运行的服务,以及如何从集群内的服务访问集群外部的任何服务,即通常所说的南北向流量管理。其中介绍了 Istio 在南北向流量方面的路由控制能力,引出 Istio 网关的概念及其工作原理。 本文文末汇集并整理了近期 Istio 的相关问题并特邀王夕宁老师进行解答,希望能够对大家有所帮助~ Istio 网关 网络社区中有一个术语 Ingress,是指入口请求到集群内服务的流量管理。Ingress 指的是源自本地网络之外的流量,指向本地集群网络中的端点。此流量首先路由到公开的入口点,以便通过执行一些本地网络的规则和策略来确认哪些流量被允许进入。如果流量未通过这些入口点,则无法与集群内的任何服务连接。如果入口点允许流量进入,则将其代理到本地网络中的合适节点。Istio 对入口流量的管理是由 Istio 网关进行的。 Istio 网关的工作原理 传统上,Kubernetes 使用 Ingress 控制器来处理从外部进入集群的流量。使用 Istio 时,情况不再如此。Istio 网关用新的 Gateway 资源和 VirtualServices 资源来控制入口流量

业界首发|阿里云重磅发布云原生架构白皮书

瘦欲@ 提交于 2020-07-28 17:23:57
2020 年 7 月 21 日,由阿里云 20+ 位云原生技术专家共同编撰的《云原生架构白皮书》正式对外发布 。作为业界首本全方位构建云原生架构规划与实践全景图的白皮书,本书在详细阐述云原生架构定义的同时,完整展示云原生架构应用所需的演进路径与设计规则,旨在帮助企业更好地理解与应用云原生架构,助力企业数字化转型升级。 <关注阿里巴巴云原生公众号,回复 白皮书 即可下载本书> 阿里云智能基础产品事业部高级研究员蒋江伟表示,“阿里云原生架构经验来自于过去数年实际场景的积累,这些经验可以帮助不同企业系统化解决所面挑战,在本书的加持下,企业可以更大幅度的提升架构灵活性,降低大流量型业务的研发成本和技术门槛,也让架构具备更高的可用性。” 面对“如何将云技术更好地跟各行业业务相结合”这一难题,阿里云在总结自身实践经验的同时,积极与各行业架构师、开发者共同探讨、提炼更加贴合行业场景,满足业务所需的云原生架构。 在本书筹备期间,阿里云发起“共同定义”云原生架构的倡议,收集了诸多架构师、开发者眼中的云原生及云原生架构的定义与思考,将之提炼并融入书中。本书涵盖了云原生架构的产生缘由、阿里云对于云原生架构的定义、目前行业领先的云原生技术、阿里巴巴的云原生架构设计、云原生架构的实践案例、云原生架构未来发展趋势等内容。希望这本与架构师、开发者共同定义的《云原生架构白皮书》

上亿条数据,如何查询分析简单又高效?

若如初见. 提交于 2020-07-28 12:30:15
摘要: 正值618大促,小张遇到了一个棘手的问题,需要在一周内将公司近1年电商部门的营收和线下门店经营数据进行联合分析。 这将产生哪些数据难题呢? 数据孤岛:电商部门的数据存在数仓A、门店经营收入数据存在数仓B,如何便捷的进行多仓联合分析? PB级数据量:多电商平台+全国线下门店每天将产生TB级数据量,年数据量高达PB级! 他在第一时间联系了集团CTO,希望将各部门数据在一天内导出给他。 这时候,CTO犯难了: 公司现有的资源池可自如应对TB级数据量,而小张要的数据量粗略估计达到了PB级,大大超出了公司现有资源池承受范围,只能以时间为代价导出;而为了不常见场景扩大公司资源池,整体的成本太高。 面对小张遇到的棘手问题,云湖湖推荐了一款华为云大数据查询分析神器——数据湖探索(DLI)服务;一个DLI即可撬动EB级数据量联合查询,每CU仅需0.35元/小时(1CU=1Core4G Mem),1CU包月仅需150元。 数据湖探索(DLI)服务 2.0是完全兼容Apache Spark和Apache Flink生态的Serverless大数据计算分析服务,用户仅需使用标准SQL或程序即可查询分析各类异构数据源。 DLI是如何解决小张问题的呢? DLI服务架构——Serverless DLI是无服务器化的大数据查询分析服务它的优势在于: (1)按量计费:真正的按使用量(扫描量/CU时)计费

基于 API 网关 + 云函数 SCF 部署 Serverless 外卖订单系统

守給你的承諾、 提交于 2020-07-28 10:52:32
API 网关结合云函数 SCF 的使用场景非常丰富,本文将介绍如何基于 API 网关+云函数 SCF 快速部署 Serverless 的外卖订单系统。 消息推送使用的典型场景 外卖订单系统架构图 Demo 实战 1. 安装Serverless Framework npm install -g serverless 2. 初始化项目模板 sls init -t websocket-order 3. 查看项目目录 下载到本地后,查看项目目录结构如下: 包含 DB、网关、函数等多个子模块。 db 目录用于创建 PG Serverless 数据库实例 apigateway 用于创建对应的 API : /bill 下单 API,HTTP 类型 /get_shop_info,获取店铺菜单 API /pgws,用于做消息推送的 websocket API 函数列表如下: 消息推送相关函数: 注册函数 ws_register.py, 配置 DB 的环境变量 传输函数 ws_trans.py ,配置 DB 的环境变量以及 apiid= 消息推送API 注销函数 ws_unregister.py ,配置 DB 的环境变量以及 apiid= 消息推送API 下单函数 bill.py , 配置 DB 的环境变量以及 apiid= 消息推送API 拉取店铺信息函数 get_shop_info.py,配置

社区首款 OAM 可视化平台发布!

蹲街弑〆低调 提交于 2020-07-28 07:19:15
作者 | 徐运元,杭州谐云科技合伙人及资深架构师,云计算行业和 Kubernetes 生态资深从业者 导读: 什么是 OAM?2019 年 10 月 17 日,阿里巴巴合伙人、阿里云智能基础产品事业部总经理蒋江伟(花名:小邪)在 QCon 上海 2019 重磅宣布,阿里云与微软联合推出开放应用模型 Open Application Model (OAM)开源项目 。 OAM 的核心关注点 关注点分离: 开发者关注应用本身,运维人员关注模块化运维能力,让应用管理变得更轻松、应用交付变得更可控; 平台无关与高可扩展: 应用定义与平台层实现解耦,应用描述支持任意扩展和跨环境实现; 模块化应用运维特征: 可以自由组合和支持模块化实现的运维特征描述。 OAM 的核心模块 1. 应用组件(Components) 在 OAM 中,“应用”是由多个概念共同组合而成。第一个概念是:应用组件(Components),它是整个应用的重要组成部分。应用组件既可以包括应用运行所依赖的服务:比如 MySQL 数据库,也包括应用服务本身:比如拥有多个副本的 PHP 服务器。开发者可以把他们写的代码“打包”成一个应用组件,然后编写配置文件来描述该组件与其他服务之间的关系。 应用组件的概念让平台架构师等能够将应用分解成一个个可被复用的模块,这种模块化封装应用组成部分的思想,代表了一种构建安全

Serverless 选型:深度解读 Serverless 架构及平台选择

我与影子孤独终老i 提交于 2020-07-28 07:15:17
作者 | 悟鹏 阿里巴巴技术专家 **导读:**本文尝试以日常开发流程为起点,分析开发者在每个阶段要面对的问题,然后组合解决方案,提炼面向 Serverless 的开发模型,并与业界提出的 Serverless 产品形态做对应,为开发者采用 Serverless 架构和服务提供参考。 近两年来,Serverless 概念在开发者中交流的越来越多,主题分享呈现爆发趋势,如在云原生领域颇具影响力 KubeCon&CloudNativeCon 会议中,关于 Serverless 的主题,2018 年有 20 个,到 2019 年增长至 35 个。 在 Serverless 产品层面,从最早的 AWS Lambda,到 Azure Functions、Goolge Functions、Google CloudRun,再到国内阿里云 Serverless Kubernetes、Serverless 应用引擎、函数计算等,面向计算的 Serverless 云上基础设施越来越丰富。 新概念、新产品的产生不是凭空出现,它们诞生之初要解决的是当前问题。随着实践者对问题域的理解越来越清晰和深刻,问题的处理方法也会逐步迭代,更接近问题本质的解决方案也会出现。若不从问题域出发来理解解决方案,容易陷入两个极端,即「它能解决一切问题」和「它太超前了,理解不了」。 从日常迭代看 Serverless 图 1

云原生已来,只是分布不均

笑着哭i 提交于 2020-07-28 03:47:18
云栖号资讯:【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯,还在等什么,快来! 导读: 云原生是什么?相信不同的人有不同的认识和解读。本文结合大家的各种讨论及项目实践经验,从交付的角度,分享阿里交付专家对云原生的理解,阐述如何构建云原生应用,云原生有哪些关键技术,以及关于云原生落地的思考。 前言 Internet 改变了人们生活、工作、学习和娱乐的方式。技术发展日新月异,云计算市场风起“云”涌,从最初的物理机到虚拟机(裸金属) ,再到容器(Container),而互联网架构也从集中式架构到分布式架构 ,再到云原生架构。如今 “云原生” 被企业和开发者奉为一种标准,并被认为是云计算的未来,让我想到一句话:“未来已来,只是分布不均”。 伴随着 “云原生” 技术(架构)越来越火,火得一塌糊涂,每个人对它的理解都各不相同,网上和阿里内部关于 Cloud Native 的相关文章和讨论也非常多。不过,我发现大家对于云原生的定义、理解及实践还处于探索阶段,还没有一个非常明确或者顶层设计的标准化定义。 最近参与了一个上云项目,里面用到很多云原生的技术,借此机会结合大家的各种讨论,以及项目中的实践,聊一下个人对于云原生的一些粗浅思考。 追本溯源 在正式讨论之前,我们不妨先来看看几位网红主播是怎么定义云原生的。 1. Pivotal 的定义 Pivotal