ucc

从 2018 年 Nacos 开源说起

和自甴很熟 提交于 2021-01-23 05:01:39
2018 年夏天 国内微服务开源 领域,迎来了一位新成员。此后,在构建微服务注册中心和配置中心的过程中,国内开发者多了一个可信赖的选项。 Nacos 是阿里巴巴开源的一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台( 官方网站 ),它凝聚了阿里巴巴十多年来在超大规模注册和配置上的最佳实践,可以用在微服务场景作为服务注册中心、配置中心等核心场景中,和阿里的其他微服务开源项目一样,Nacos 也是始于阿里,成长于社区的典型。 为什么要开源 Nacos ? 在大规模服务发现和服务治理领域,现有的开源解决方案并非已经非常完美,阿里巴巴从 IOE 集中式应用架构升级为互联网分布式服务化架构的演进过程中,积累了大量有关服务注册和服务配置的实践经验,而这些经验是可以在各个行业大规模复用。除此之外,更重要的是,希望和社区开发者共同发展,让 Nacos 可以帮助国内企业更自由的构建基于云原生应用的动态服务发现、配置和服务管理。 相比其他服务注册和配置中心开源方案,Nacos 的起步虽然晚了点,但除了注册和配置中心的功能外,他还提供了动态服务发现、服务共享与管理的功能,在大规模场景下具备更优秀的性能,在易用性上更便捷,分布式部署上更灵活。例如和 Consul / Eureka / Zookeeper 相比:(内容摘自 《主流微服务注册中心浅析和对比》 ) Nacos Consul

一文读懂 Serverless,将配置化思想复用到平台系统中

╄→尐↘猪︶ㄣ 提交于 2021-01-20 20:56:31
作者 | 春哥大魔王 来源 | Serverless 公众号 写在前面 在 SaaS 领域 Salesforce 是佼佼者,其 CRM 的概念已经扩展到了 Marketing、Sales、Service 等领域。那么 Salesforce 靠什么变成了这三个行业的解决方案呢?得益于 Salesforce 强大的 aPaaS 平台 。 ISV、内部实施、客户均可以从自己的维度基于 aPaaS 平台构建自己的行业,实现业务定制,甚至是行业定制。因为在此之前只有在 Sales 方向有专门的 SaaS 产品,而 Marketing 和 Service 都是由自己的 ISV 在各自行业的解决方案。所以 Salesforce 已经从一家 SaaS 公司变成了一家 aPaaS 平台公司了。 搭建一个 aPaaS 平台是需要很长时间的,当然也可以基于一些公有云产品的 Serverless 方案 实现现有系统的灵活性与扩展性,从而实现针对于不同客户的定制。 什么是 Serverless Serverless 由两部分组成,Server 和 Less。 前者可以理解为其解决方案范围处在服务端; 后者可以译为少量的; 组合起来就是较少服务端干预的服务端解决方案。 与 Serverless 相对的是 Serverfull,比较下对应的概念可能更便于理解。 在 Serverfull 时代

对容器镜像的思考和讨论

拜拜、爱过 提交于 2021-01-20 10:52:51
作者 | Liu,Bo 来源| 阿里巴巴云原生公众号 前言 常言道,startup 有 startup 的好,大厂有大厂的好,那么大厂究竟好在哪呢?拿硅谷老牌大厂们 FLG 来说,如果要问最令人怀念的是什么?Free food 和基础设施(Infrastructure)一定是会上榜的,两者均极大提升了广大应用开发者的幸福指数。那么能不能“让天下没有难做的应用”呢?请大家把目光投向正在兴起的云原生生态。 在云原生生态中,容器服务包括了镜像和容器引擎两个部分。其中容器镜像作为核心的云原生应用制品,打包了完整的操作系统和应用运行环境,应用的迭代也因为使用了这种不可变架构而变得更简单,更频繁。 本文将围绕着容器镜像这一核心,分享它的相关知识和业界的思考与实践。 容器镜像的概念 1)容器镜像 容器镜像有一个官方的类比,"生活中常见的集装箱",虽然拥有不同的规格,但箱子本身是不可变的(Immutable),只是其中装的内容不同。 对于镜像来说,不变的部分包含了运行一个应用软件(如 mysql)所需要的所有元素。开发者可以使用一些工具(如 Dockerfile)构建出自己的容器镜像,签名并上传到互联网上,然后需要运行这些软件的人可以通过指定名称(如 example.com/my-app )下载、验证和运行这些容器。 2)OCI 标准镜像规范 在 OCI 标准镜像规范出台之前

OpenYurt v0.3.0 重磅发布:全面提升边缘场景下应用部署效率

末鹿安然 提交于 2021-01-14 12:00:10
作者 | 张杰(冰羽) 来源| 阿里巴巴云原生公众号 简介 OpenYurt 是由阿里云开源的 基于原生 Kubernetes 构建的、业内首个对于 Kubernetes 非侵入式的边缘计算项目 ,目标是扩展 Kubernetes 以无缝支持边缘计算场景。它提供了完整的 Kubernetes API 兼容性;支持所有 Kubernetes 工作负载、服务、运营商、CNI 插件和 CSI 插件;提供良好的节点自治能力,即使边缘节点与云端断网,在边缘节点中运行的应用程序也不会受影响。OpenYurt 可以轻松部署在任何 Kubernetes 集群服务中,让强大的云原生能力扩展到边缘。 OpenYurt v0.3.0 重磅发布 北京时间 2020 年 11 月 8 号,Openyurt 发布 v0.3.0 版本,首次提出节点池和单元化部署概念, 新增云端 Yurt-App-Manager 组件 ,全面提升在边缘场景下的应用部署效率,降低边缘节点和应用运维的复杂度。 全面优化 yurthub、yurt-tunnel 核心组件的性能 ,yurtctl 提供 kubeadm 的 provider,可以快速方便地将由 kubeadm 创建的 Kubernetes 集群转换成 Openyurt 集群。 1. Yurt-App-Manger 为边缘应用运维而生 经过与社区同学的广泛讨论

人生苦短,开发用云 | 如何优雅完成程序员的侠客梦?

天大地大妈咪最大 提交于 2021-01-12 20:00:34
作者 | 马超 来源| 阿里巴巴云原生公众号 Coding 的魅力如此之强,引无数程序员竞折腰,在今年由 CSDN 举办的 1024 程序员节上,中国初代程序员大宗师求伯君说,当年看到有人在用 WPS,可开心了,因为有很多人用。然后,也会去找看是谁破解的,于是就这么认识雷军的,目前我虽然退休了,还在写代码,写游戏代码,不是商业软件....其实是写外挂,这个不好意思拿出来炫耀但确实可以让游戏简单点嘛。让自己的代码、自己的项目广泛流传,可以说是每一位程序员的最高目标。 工欲善其事,必先得其器。一款得心应手的编程工具,对于程序员来说无疑是效率神器,可以令开发工作事半功倍,在笔者亲身试用了云原生开发工具之后,可以说目前以云开发平台为代表的最新开发平台,其带来的效率提升加成,令人叹为观止了。 在十年前业界普遍流传着一句话,叫做“代码正在吞没世界”,后来又说“互联网世界的一切源自开源”,而直到最近,人们才真正醒悟:原来云原生才是背后的那个大 BOSS,凡是不使用云的都将落后,都无法做到敏捷,跟不上时代。云开发平台作为云原生工具的典范,在未来必然会成为主流的编程神器。 下面我们先盘点一下开发平台的发展历程,和各位读者一起读懂云原生与 DEVOPS 结合从而形成的大趋势。开发平台就像是程序员手中的剑,只是程序员手中的剑已经由从前只能随身携带,变成了现在来自云端的天外飞仙。 从本地化开发到在线开发

再见 2020!Apache RocketMQ 发布 4.8.0,DLedger 模式全面提升!

偶尔善良 提交于 2021-01-07 22:22:40
作者 | RocketMQ社区 来源| 阿里巴巴云原生公众号 “童年的雨天最是泥泞,却是记忆里最干净的曾经。凛冬散尽,星河长明,新的一年,万事顺遂,再见,2020!” 走过这个岁末,万众期待的 Apache RocketMQ 4.8.0 终于发布 了,在这个版本中社区对 RocketMQ 完成大量的优化和问题修复。更重要的是,该版本从性能、稳定性、功能三个方面大幅度提升 DLedger 模式能力。 DLedger 是 OpenMessaging 中一个基于 Raft 的 CommitLog 存储库实现,从 RocketMQ 4.5.0 版本开始,RocketMQ 引入 DLedger 模式来解决了 Broker 组内自动故障转移的问题,而在 4.8.0 版本中社区也对 RocketMQ DLedger 模式进行了全面升级。 性能升级 异步化 pipeline 模式 RocketMQ 4.7.0 重新升级了同步双写的架构,利用异步化 pipeline 模式大幅提升了同步双写的性能。在 RocketMQ 4.8.0 中,社区将这一改进应用到 DLedger 模式中, 下图展示了 DLedger 模式下 broker 处理发送消息的过程。在原本的架构中, SendMessageProcessor 线程对每一个消息的处理,都需要等待多数派复制成功确认,才会返回给客户端,而在新版本中,利用

阿里巴巴云原生的 2020,注定不凡的一年

删除回忆录丶 提交于 2021-01-04 22:12:14
来源| 阿里巴巴云原生公众号 划重点 2020 年我们发布了 360 篇文章,共 1966320 字,相当于 2 部《红楼梦》,比 2019 年多 94 篇文章,约 1 部《西游记》。 内容方向由 2019 年主攻的容器方向转向容器、中间件、微服务等云原生综合技术领域,其中技术解读和实践类文章最受大家的欢迎。 2020 年注定是不凡的一年 有人见尘埃 有人见星辰 但是没关系 好在这一年所有的遗憾都将收尾 美好的 2021 即将开启 在 2020 年的最后一天 一起来看看我们共同经历过的那些“大事件”吧~ 2020 年 1 月 容器调度、混部等面向突变型峰值的关键技术获 2019 年国家技术发明二等奖 2020 年 2 月 Kubernetes SIG-Cloud-Provider-Alibaba 首次网研会召开 OCI 完成 TOB 选举,阿里工程师傅伟作为唯一华人入选全球 9 人名单 2020 年 3 月 阿里云 Java initializr 正式发布,受到了广大开发者欢迎 2020 年 4 月 Gartner 发布 2020 年公共云容器报告:阿里云覆盖九项产品能力,成为全球云原生产品丰富度最高的厂商之一 Dragonfly 晋升成为 CNCF 孵化项目 国内首个《Serverless 技术公开课》上线 2020 年 5 月 首个边缘计算云原生项目 OpenYurt 正式开源

免费下载来自阿里巴巴 双11 的《云原生大规模应用落地指南》

房东的猫 提交于 2021-01-04 22:11:49
来源| 阿里巴巴云原生公众号 复制链接到浏览器完成下载或分享: https://developer.aliyun.com/topic/download?id=1055 11 月 11 日零点零分 26 秒,天猫 双11 的订单创建峰值就达到 58.3 万笔/秒,阿里云又一次扛住全球最大规模流量洪峰。与此前不同的是,继去年天猫 双11 核心系统上云后,阿里巴巴基于数字原生商业操作系统,实现了全面云原生化,底层技术升级带来了澎湃动力和极致效能。 如今,企业上云已经成为一种必然趋势。与此同时,作为诞生于云计算时代的新技术理念,云原生让企业用云的方式发生着从“上云”到“云上”的转化。速度下载《云原生大规模应用落地指南》,从技术体系升级、到技术能力突破、再到双11云原生实践,看最全面的阿里巴巴 双11 云原生技术实践经验。 独家下载《云原生大规模应用落地指南》 《云原生大规模应用落地指南》一书目录 推荐嘉宾寄语 “2020 年 双11 的主题是「云原生」,是在「云上」实现核心系统全面云原生化的的第一年。我们看到,云的定义在不断变化,它成为了商业领域数字化的底座和基础,不再单指传统云计算了,而是将未来的方向指向云原生。某种程度上,恰恰是因为云原生,我们才能从过去的束缚中解放出来。不迈出这一步,我们的综合能力很维迎来下一次突破。” “云原生让企业用云的方式发生着从‘上云’到‘云上’的转化

OpenKruise v0.5.0 版本发布,支持无损的流式分批发布策略

人盡茶涼 提交于 2020-12-19 08:35:01
作者 | 酒祝 阿里云技术专家 导读 : OpenKruise 是阿里云开源的大规模应用自动化管理引擎,在功能上对标了 Kubernetes 原生的 Deployment/StatefulSet 等控制器,但 OpenKruise 提供了更多的增强功能如 优雅原地升级、发布优先级/打散策略、多可用区 workload 抽象管理、统一 sidecar 容器注入管理等,都是经历了阿里巴巴超大规模应用场景打磨出的核心能力。这些 feature 帮助我们应对更加多样化的部署环境和需求、为集群维护者和应用开发者带来更加灵活的部署发布组合策略。 目前在阿里巴巴内部云原生环境中,绝大部分应用都统一使用 OpenKruise 的能力做 Pod 部署、发布管理,而不少业界公司和阿里云上客户由于 K8s 原生 Deployment 等负载不能完全满足需求,也转而采用 OpenKruise 作为应用部署载体。 背景问题 在介绍 OpenKruise 新增能力之前,我们先来看一下原生 K8s workload 所提供的发布能力: Deployment 目前支持 maxUnavailable 和 maxSurge: StatefulSet 目前支持 partition: 其余 workload 如 DaemonSet,也只支持了 maxUnavailable。 以上这些策略在测试环境或是小场景下尚且可行

一文讲透 Serverless Kubernetes 容器服务

生来就可爱ヽ(ⅴ<●) 提交于 2020-12-15 18:07:28
作者 | 张维(贤维) 阿里云函数计算开发工程师 导读 :Serverless Kubernetes 是以容器和 kubernetes 为基础的 Serverless 服务,它提供了一种简单易用、极致弹性、最优成本和按需付费的 Kubernetes 容器服务,其无需节点管理和运维,无需容量规划,让用户更关注应用而非基础设施的管理。我们可以把 Serverless Kubernetes 简称为 ASK。 Serverless 容器 首先从 Serverless 开始讲起,相信我们已经熟知 Serverless 理念的核心价值,其中包括无需管理底层基础设施,无需关心底层 OS 的升级和维护,因为 Serverless 可以让我们更加关注应用开发本身,所以应用的上线时间更短。同时 Serverless 架构是天然可扩展的,当业务用户数或者资源消耗增多时,我们只需要创建更多的应用资源即可,其背后的扩展性是用户自己购买机器所无法比拟的。Serverless 应用一般是按需创建,用户无需为闲置的资源付费,可以降低整体的计算成本。 以上所讲的几种都是 Serverless 理念的核心价值,也是 Serverless 容器与其他 Sererless 形态的相同之处。然而,Serverless 容器和其他 Serverless 形态的差异,在于它是基于容器的交付形态。 基于容器意味着通用性和标准性