ucc

美国时间 2020 年 5 月 27 日，知名复杂环境应用交付与基础设施管理项目 Crossplane 将联合 Open Application Model （OAM）社区共同举办 Crossplane Community Day。 谷歌公司 Kubernetes 项目首席布道师 Kelsey Hightower 、阿里云资深技术专家、CNCF TOC 李响 与微软杰出工程师、Kubernetes 联合创始人 Brendan Burns 将共同出席并做关于标准化定义应用与基础设施的重要主题演讲。在本次 Crossplane Community Day 上，你将了解到 OAM 社区同 Crossplane 项目正在展开的深度技术合作，以及世界各地的平台构建者如何通过 OAM 和 Crossplane 来配置和管理面向复杂环境的应用程序、基础架构与云服务。 部分出席嘉宾一览 Kelsey Hightower Kelsey Hightower 就职于 Google Cloud，是负责维护开发者关系的开发者布道师、Kubernetes 引擎的倡导者和领导者。此外，Kelsey Hightower 过去的工作还包括 CoreOS 的软件开发人员和开发者布道师。 Brendan Burns Brendan Burns 是微软 Azure 的杰出工程师，也是 Kubernetes

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

什么是架构图？ 如何画好一张架构图，要做好这件事情首先要回答的就是什么是架构图。我们日常工作中经常能看到各种各样的架构图，而且经常会发现大家对架构图的理解各有侧重。深入追究到这个问题，可能一下子还很难有一个具象的定义，如果我们把这个问题进行拆分（如下）理解起来就会容易一点。 架构图 = 架构 + 图 按照这个等式，我们可以把问题转换： 架构是什么？ 图是什么？ 图是什么？这个比较容易回答，图是一种信息的表达方式，所以架构图，即表达“架构”的图，也就是一种架构的表达方式。也即： 架构图 = 架构的表达 = 表达架构的图 按照这种思路我们需要回答： 什么是架构？要表达的到底是什么？ 如何画好一张架构图？ 接下来的内容基本上就是按照这两个维度来做分析。 什么是架构？要表达的到底是什么？ Linus 03 年在聊到拆分和集成时有一个很好的描述： I claim that you want to start communicating between independent modules no sooner than you absolutely HAVE to, and that you should avoid splitting things up until you really need to, because that communication complexity

前言 最早提出“大数据”时代到来的是全球知名咨询公司麦肯锡，麦肯锡称：“数据，已经渗透到当今每一个行业和业务职能领域，成为重要的生产因素。人们对于海量数据的挖掘和运用，预示着新一波生产率增长和消费者盈余浪潮的到来。”数据，让一切有迹可循，让一切有源可溯。我们每天都在产生数据，创造大数据和使用大数据，只是，你，仍然浑然不知。 企业组织利用相关数据和分析可以帮助它们降低成本、提高效率、开发新产品、做出更明智的业务决策等等。大数据的价值，远远不止于此，大数据对各行各业的渗透，大大推动了社会生产和生活，未来必将产生重大而深远的影响。 具体展开图（点击“阅读原文”可下载），详细内容请看下文： 一 大数据基础技术 数据分片路由 在大数据的背景下，数据规模已经由 GP 跨越大屏 PB 的级别，单机明显已经无法存储与处理如此规模的数据量，只能依靠大规模集群来对这些数据进行存储和处理。对于海量的数据，通过数据分片（Shard/Partition）来将数据进行切分到不同机器中去，分片以后，如何能够找到某一条记录。这就是数据的分片和路由。 数据复制 & 一致性 在大数据的存储系统中，为了增加系统的可靠性，往往会将同一份数据存储多个副本。数据是如何复制？以及数据复制后带来的一致性问题如何的解决？ 大数据常用算法与数据结构 对于大数据或者大规模的分布式系统来说，如何能够高效快速地进行海量数据的处理非常关键

作者 | 于雨、何鑫铭 等 引语 计算机技术浪潮每 10 年都有一次技术颠覆，相关知识体系最迟每 5 年都会革新一次，大概每两年贬值一半，在应用服务通信框架领域亦然。凡是有长期生命的通信框架，大概有 5 年的成长期和 5 年的稳定成熟期。每个时代都有其匹配的应用通信框架，在 20 年前的 2G 时代，强跨语言跨平台而弱性能的 gRPC 是不会被采用的。 每个通信框架，不同的人从不同角度看出不同的结论：初学者看重易用易学，性能测评者注重性能，应用架构师考虑其维护成本，老板则考虑则综合成本。一个应用通信框架的性能固然重要，其稳定性和进化能力更重要，得到有效维护的框架可在长时间单位内降低其综合成本：学习成本、维护成本、升级成本和更换成本。 **什么是 Dubbo-go？**第一，它是 Dubbo 的 Go 语言版本，全面兼容 Dubbo 是其第一要义；第二，它是一个 Go 语言应用通信框架，会充分利用作为云原生时代第一语言---Go 语言的优势，扩展 dubbo 的能力。 2008 年诞生的 Dubbo 已有十多年历史，依靠阿里和其社区，历久弥新。2016 年发布的 Dubbo-go 也已进入第五个年头，如今全面兼容 Dubbo v2.7.x 的 Dubbo-go v1.5 终于发布了。 回首过往，Dubbo-go 已经具备如下能力： 互联互通：打通了 gRPC 和 Spring

作者 | 白寂 阿里云开发工程师 导读 ：前三篇文章我们介绍了应用的开发和部署，那么在应用成功上云后，我就要面对应用的管理话题了，这一篇我们来看看如何做线上发布，并且是可灰度的。 相关文章推荐： 《SpringCloud 应用在 Kubernetes 上的最佳实践 —— 开发篇》 《SpringCloud 应用在 Kubernetes 上的最佳实践 — 部署篇(开发部署）》 《SpringCloud 应用在 Kubernetes 上的最佳实践 — 部署篇(工具部署)》 前言 在新版本上线时，无论是从产品稳定性还是用户对新版本的接受程度上考虑，直接将老应用升级到新版本应用都有很大风险的。我们一般的做法是，保证新老版本同时在线，并且先将少部分流量切换到新版本应用上，同时在此期间对新版本的应用请求进行观察。在确认新版本没有问题后，再逐步将更大比例的流量切换到新版本上。这个过程的核心是可以对流量的流入转发规则进行配置，EDAS 的金丝雀发布能力，提供了多个版本同时在线的能力，并且提供了灵活的配置规则来给不同的版本进行流量分配。 部署在 EDAS Kubernetes 集群中的 Spring Cloud 微服务应用，在新版本发布的时候可以使用金丝雀发布进行小规模验证，验证通过后再全量升级。 金丝雀发布配置 首先，进入 EDAS 的应用部署页面，对我们要进行部署升级的应用进行发布

作者 | 许晓斌 阿里云高级技术专家 本文整理自《Serverless 技术公开课》第 1 讲， 点击开始学习 。 关注 “ Serverless ” 公众号，回复 **入门 **，即可获取 Serverless 系列文章 PPT。 传统单体应用架构 十多年前主流的应用架构都是单体应用，部署形式就是一台服务器加一个数据库，在这种架构下，运维人员会小心翼翼地维护这台服务器，以保证服务的可用性。 （单体架构） 随着业务的增长，这种最简单的单体应用架构很快就面临两个问题。首先，这里只有一台服务器，如果这台服务器出现故障，例如硬件损坏，那么整个服务就会不可用；其次，业务量变大之后，一台服务器的资源很快会无法承载所有流量。 解决这两个问题最直接的方法就是在流量入口加一个负载均衡器，使单体应用同时部署到多台服务器上，这样服务器的单点问题就解决了，与此同时，这个单体应用也具备了水平伸缩的能力。 （单体架构-水平伸缩） 微服务架构 1. 微服务架构演进出通用服务 随着业务的进一步增长，更多的研发人员加入到团队中，共同在单体应用上开发特性。由于单体应用内的代码没有明确的物理边界，大家很快就会遇到各种冲突，需要人工协调，以及大量的 conflict merge 操作，研发效率直线下降。 因此大家开始把单体应用拆分成一个个可以独立开发、独立测试、独立部署的微服务应用，服务和服务之间通过 API 通讯，如

作者 | 孔德慧（夏莞） 阿里云函数计算开发工程师 本文整理自《Serverless 技术公开课》， 关注 Serverless 公众号，回复“入门”，即可获取 Serverless 系列文章 PPT 。 什么是函数计算？ 大家都了解，Serverless 并不是没有服务器，而是开发者不再需要关心服务器。下图是一个应用从开发到上线的对比图： 在传统 Serverful 架构下，部署一个应用需要购买服务器，部署操作系统，搭建开发环境，编写代码，构建应用，部署应用，配置负载均衡机制，搭建日志分析与监控系统，应用上线后，继续监控应用的运行情况。而在 Serverless 架构下，开发者只需要关注应用的开发构建和部署，无需关心服务器相关操作与运维，在函数计算架构下，开发者只需要编写业务代码并监控业务运行情况。这将开发者从繁重的运维工作中解放出来，把精力投入到更有意义的业务开发上。 上图展示了函数计算的使用方式。从用户角度，他需要做的只是编码，然后把代码上传到函数计算中。上传代码就意味着应用部署。当有高并发请求涌入时，开发者也无需手动扩容，函数计算会根据请求量毫秒级自动扩容，弹性可靠地运行任务，并内置日志查询、性能监控、报警等功能帮助开发者发现问题并定位问题。 函数计算核心优势 1. 敏捷开发 使用函数计算时，用户只需聚焦于业务逻辑的开发，编写最重要的 “核心代码”； 不再需要关心服务器购买

作者 | 冬岛 阿里巴巴技术专家 导读 ：托管 Knative 开箱即用，您不需要为这些常驻实例付出任何成本。结合 SLB 云产品提供 Gateway 的能力以及基于突发性能型实例的保留规格功能，极大的节省您的 IaaS 开支，您支付的每一分钱都没有浪费。 <关注阿里巴巴云原生公众号，回复 报告 即可下载完整调查报告> CNCF 发布的年度调查报告显示 2019 年 Serverless 技术进一步获得了更大的认可。其中 41% 的受访者表示已经在使用 Serverless，另外 20% 的受访者表示计划在未来 12-18 个月内会采用 Serverless 技术。而在众多开源的 Serverless 项目中 Knative 是最受欢迎的一个。如下图所示， Knative 占据了 34% 的份额，遥遥领先于第二名 OpenFaaS，Knative 是自己搭建 Serverless 平台的首选。 Knative 之所以这么受欢迎和容器的生态不无关系。和 FaaS 模式不同的是 Knative 不要求用户对应用做非常大的改造，只要用户的应用完成了容器化就能部署在 Knative 中。并且 Knative 在 Kubernetes 之上提供了更聚焦的应用模型，让用户无需为应用的升级、流量灰度花费精力，这一切都是自动完成的。 云主机的发展历程 在云计算出现之前

来源： oschina 链接： https://my.oschina.net/u/1464083/blog/4333578