阿里巴巴成立云原生技术委员会,云原生升级为阿里技术新战略

alicloudnative阅读(7591)评论(0)

1.png

9 月 18 日,2020 杭州云栖大会期间,阿里巴巴正式成立云原生技术委员会(以下简称委员会),阿里巴巴高级研究员蒋江伟担任委员会负责人,达摩院数据库首席科学家李飞飞、阿里云计算平台高级研究员贾扬清、阿里云原生应用平台研究员丁宇等多位阿里技术负责人参与其中。同时,阿里云推出包括软硬结合的沙箱容器 2.0、离线实时一体化数据仓库 MaxCompute、云原生多模数据库 Lindorm 在内的多款云原生产品。

2.jpg

云原生是一种新型技术体系,被视为云计算未来的发展方向。云原生应用也就是面向“云”而设计的应用,在使用云原生技术后,开发者无需考虑底层的技术实现,只需做好自己的业务,就可以充分发挥云平台的弹性+分布式优势,实现快速部署、按需伸缩、不停机交付等。

蒋江伟表示,委员会将大力推动阿里经济体全面云原生化,并沉淀阿里巴巴 10 多年的云原生实践,对外赋能数百万家企业进行云原生改造,提升 30% 研发效率的同时降低 30% IT 成本,帮助客户迈入数字原生时代。

3.jpg

此次委员会的成立,也意味着阿里已经将云原生升级为新的技术战略方向。蒋江伟介绍,阿里拥有 10 多年的云原生实践经验,从 2009 年首次上线核心中间件系统,到 2011 年淘宝天猫开始使用容器调度技术,再到推出自研云原生硬件神龙服务器、云原生数据库 PolarDB。2019 年 双11,阿里电商核心系统 100% 上云,这也是全球规模最大的云原生实践。

公开资料显示,阿里云目前拥有国内规模最大的云原生产品家族和开源生态,提供云原生裸金属服务器、云原生数据库、数据仓库、数据湖、容器、微服务、DevOps、Serverless 等超过 100 款创新产品,覆盖政务、零售、教育、医疗等各个领域。在 Gartner 发布的 2020 年公共云容器报告中,阿里云容器以丰富的产品布局在 9 项产品评选中排名全球第一,是全球容器产品最完善的云服务商。

4.jpg

在今年疫情期间,基于阿里云容器解决方案,钉钉 2 小时内扩容 1 万台云主机支撑 2 亿上班族在线开工;申通快递将核心系统搬到阿里云上,并进行应用容器化和微服务改造,在日均处理订单 3000 万的情况下,IT 成本降低 50%;采用了阿里云原生 PaaS 平台的中国联通号卡应用,开卡业务效率提升了 10 倍,需求响应时间缩短了 50%,支撑访问量由 1000 万上升至 1.1 亿……

此前,阿里云宣布未来一年投入 20 亿优选合作 10000 家伙伴,共同服务百万客户,加速百行千业实现数字化转型。同时,阿里云还启动了“云原生人才计划”,三年内产教融合进入 300 所高校,新增培养 100 万云原生开发者。

2020 云栖大会-企业云原生创新与实践分论坛,声网、好未来、新浪微博、CNCF 等嘉宾邀你共同探讨如何帮助企业和开发者共同迈入数字原生时代。

点击链接直达直播页面:https://yunqi.aliyun.com/2020/session88

阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的公众号。”

设计稿生成代码与 Serverless 的前世今生与未来!

alicloudnative阅读(2041)评论(0)

1.png

一场脑洞实验

云栖大会云上 Hello World 活动火热进行中!每位参与者都可收获一份阿里云出品的全球唯一序列号纪念证书!

作为阿里经济体前端委员会的四大技术方向之一,前端智能化方向一被提及,就不免有人好奇:前端结合机器学习能做些什么,怎么做,未来会不会对前端产生很大的冲击等等。本文以「设计稿自动生成代码」场景为例,细述我们的思考及过程实践。

前端智能化与云 IDE 的结合,通过后者打通的各种服务与接口,再加上设计稿生成代码的能力,可以进一步地提升前端开发者的开发体验,由原来的设计稿生成代码,转变为生成可随时可部署的应用/页面,因此本文最后会介绍如何在阿里云云开发平台使用 imgcook 插件,一键完成设计稿稿生成应用,开启您的智能开发之旅。

前端智能化背景

业界机器学习之势如火如荼,「AI 是未来的共识」频频出现在各大媒体上。李开复老师也在《AI · 未来》指出,将近 50% 的人类工作将在 15 年内被人工智能所取代,尤其是简单的、重复性的工作。并且,白领比蓝领的工作更容易被取代;因为蓝领的工作可能还需要机器人和软硬件相关技术都突破才能被取代,而白领工作一般只需要软件技术突破就可以被取代,那我们前端这个“白领”工作会不会被取代,什么时候能被取代多少?

回看 2010 年,软件几乎吞噬了所有行业,带来近几年软件行业的繁荣;而到了 2019 年,软件开发行业本身却又在被 AI 所吞噬。你看:DBA 领域出现了 Question-to-SQL,针对某个领域只要问问题就可以生成 SQL 语句;基于机器学习的源码分析工具 TabNine 可以辅助代码生成;设计师行业也出了 P5 Banner 智能设计师“鹿班”,测试领域的智能化结合也精彩纷呈。那前端领域呢?

那就不得不提一个我们再熟悉不过的场景了,它就是设计稿自动生成代码(Design2Code,以下简称 D2C),阿里经济体前端委员会 – 前端智能化方向当前阶段,就是聚焦在如何让 AI 助力前端这个职能角色提效升级,杜绝简单重复性工作,让前端工程师专注更有挑战性的工作内容!

imgcook 是什么?

imgcook 使用 Sketch、PSD、静态图片等形式作为输入,通过智能化技术一键生成可维护的前端代码,包含视图代码、数据字段绑定、组件代码、部分业务逻辑代码等。

2.png

它期望能够利用智能化手段,让自己成为一位前端工程师,在对设计稿轻约束的前提下实现高度还原,释放前端生产力,助力前端与设计师高效协作,让工程师们专注于更具挑战性的工作!

设计稿生成代码的目标是让 AI 助力前端这个职能角色提效升级,杜绝简单重复性工作内容。那我们先来分析下,“常规”前端尤其是面向 C 端业务的同学,一般的工作流程日常工作内容大致如下:

3.png

“常规”前端一般的开发工作量,主要集中在视图代码逻辑代码数据联调这几大块,接下来,我们逐块拆解分析。

1. 问题定义

视图代码研发,一般是根据视觉稿编写 HTML 和 CSS 代码。如何提效?当面对 UI 视图开发重复性的工作时,自然想到组件化、模块化等封装复用物料的解决方案,基于此解决方案会有各种 UI 库的沉淀,甚至是可视化拼装搭建的更高阶的产品化封装,但复用的物料不能解决所有场景问题。个性化业务、个性化视图遍地开花,直面问题本身,直接生成可用的 HTML 和 CSS 代码是否可行?

4.png

这是业界一直在不断尝试的命题,通过设计工具的开发插件可以导出图层的基本信息,但这里的主要难点还是对设计稿的要求高、生成代码可维护性差,这是核心问题,我们来继续拆解。

1)设计稿要求高

对设计稿的要求高,会导致设计师的成本加大,相当于前端的工作量转嫁给了设计师,导致推广难度会非常大。

一种可行的办法是采用 CV(ComputerVision, 计算机视觉) 结合导出图层信息的方式,以去除设计稿的约束,当然对设计稿的要求最好是直接导出一张图片,那样对设计师没有任何要求,也是我们梦寐以求的方案,我们也一直在尝试从静态图片中分离出各个适合的图层,但目前在生产环境可用度不够(小目标识别精准度问题、复杂背景提取问题仍待解决),毕竟设计稿自带的元信息,比一张图片提取处理的元信息要更多更精准。

2)代码可维护性

生成的代码结构一般都会面临可维护性方面的挑战:

  • 合理布局嵌套:包括绝对定位转相对定位、冗余节点删除、合理分组、循环判断等方面;
  • 元素自适应:元素本身扩展性、元素间对齐关系、元素最大宽高容错性;
  • 语义化:类名的多级语义化;
  • 样式 CSS 表达:背景色、圆角、线条等能用 CV 等方式分析提取样式,尽可能用 CSS 表达样式代替使用图片。

将这些问题拆解后,分门别类专项解决,解决起来看似没完没了,但好在目前发现的大类问题基本解决。

很多人质疑道:这部分能力的实现看起来和智能化一点关系都没有,顶多算个布局算法相关的专家规则系统。没错,现阶段这部分比较适合规则系统,对用户而言布局算法需要接近 100% 的可用度,另外这里涉及的大部分是无数属性值组合问题,当前用规则更可控。如果非要使用模型,那这个可被定义为多分类问题。同时,任何深度学习模型的应用都是需要先有清晰的问题定义过程,把问题规则定义清楚本就是必备过程。

但在规则解决起来麻烦的情况下,可以使用模型来辅助解决。比如 合理分组(如下图) 和 循环项 的判断,实践中我们发现,在各种情况下还是误判不断,算法规则难以枚举,这里需要跨元素间的上下文语义识别,这也是接下来正在用模型解决的重点问题。

5.png

2. 技术方案

基于上述的概述和问题分解后,我们对现有的 D2C 智能化技术体系做了能力概述分层,主要分为以下三部分:

  • 识别能力:即对设计稿的识别能力,智能从设计稿分析出包含的图层、基础组件、业务组件、布局、语义化、数据字段、业务逻辑等多维度的信息;如果智能识别不准,就可视化人工干预补充纠正,一方面是为了可视化低成本干预生成高可用代码,另一方面这些干预后的数据就是标注样本,反哺提升智能识别的准确率;
  • 表达能力:主要做数据输出以及对工程部分接入:a)通过 DSL 适配将标准的结构化描述做 Schema2Code;b)通过 IDE 插件能力做工程接入;
  • 算法工程:为了更好的支撑 D2C 需要的智能化能力,将高频能力服务化,主要包含数据生成处理、模型服务部分:
    • 样本生成:主要处理各渠道来源样本数据并生成样本;
    • 模型服务:主要提供模型 API 封装服务以及数据回流。

6.png
(前端智能化 D2C 能力概要分层)

在整个方案里,我们用同一套数据协议规范(D2C Schema)来连接各层的能力,确保其中的识别能够映射到具体对应的字段上,在表达阶段也能正确地通过出码引擎等方案生成代码。

1)智能识别技术分层

在整个 D2C 项目中,最核心的是上述识别能力部分的机器智能识别部分,这层的具体再分解如下:

  • 物料识别层:主要通过图像识别能力识别图像中的物料(模块识别、原子模块识别、基础组件识别、业务组件识别);
  • 图层处理层:主要将设计稿或者图像中图层进行分离处理,并结合上一层的识别结果,整理好图层元信息;
  • 图层再加工层:对图层处理层的图层数据做进一步的规范化处理;
  • 布局算法层:转换二维中的绝对定位图层布局为相对定位和 Flex 布局;
  • 语义化层:通过图层的多维特征对图层在生成代码端做语义化表达;
  • 字段绑定层:对图层里的静态数据结合数据接口做接口动态数据字段绑定映射;
  • 业务逻辑层:对已配置的业务逻辑通过业务逻辑识别和表达器来生成业务逻辑代码协议;
  • 出码引擎层:最后输出经过各层智能化处理好的代码协议,经过表达能力(协议转代码的引擎)输出各种 DSL 代码。

7.png
(D2C 识别能力技术分层)

2)技术痛点

当然,这其中的识别不全面、识别准确度不高一直是 D2C 老生常谈的话题,也是 imgcook 的核心技术痛点。我们尝试从这几个角度来分析引起这个问题的因素:

  • 识别问题定义不准确:问题定义不准确是影响模型识别不准的首要因素,很多人认为样本和模型是主要因素,但在这之前,可能一开始对问题的定义就出现了问题,我们需要判断我们的识别诉求模型是否合适做,如果合适那该怎么定义清楚这里面的规则等;
  • 高质量的数据集样本缺乏:我们在识别层的各个机器智能识别能力需要依赖不同的样本,那我们的样本能覆盖多少前端开发场景,各个场景的样本数据质量怎么样,数据标准是否统一,特征工程处理是否统一,样本是否存在二义性,互通性如何,这是我们当下所面临的问题;
  • 模型召回低、存在误判:我们往往会在样本里堆积许多不同场景下不同种类的样本作为训练,期望通过一个模型来解决所有的识别问题,但这却往往会让模型的部分分类召回率低,对于一些有二义性的分类也会存在误判。

【问题定义】

深度学习里的计算机视觉类模型目前比较适合解决的是分类问题和目标检测问题,我们判断一个识别问题是否该使用深度模型的前提是——我们自己是否能够判断和理解,这类问题是否有二义性等,如果人也无法准确地判断,那么这个识别问题可能就不太合适。

假如判断适合用深度学习的分类来做,那就需要继续定义清楚所有的分类,这些分类之间需要严谨、有排他性、可完整枚举。比如在做图片的语义化这个命题的时候,一般图片的 ClassName 通用常规命名有哪些,举个例子,其分析过程如下:

8.png

  • 第一步:尽可能多地找出相关的设计稿,一个个枚举里面的图片类型;
  • 第二步:对图片类型进行合理归纳归类,这是最容易有争论的地方,定义不好有二义性会导致最有模型准确度问题;
  • 第三步:分析每类图片的特征,这些特征是否典型,是否是最核心的特征点,因为关系到后续模型的推理泛化能力;
  • 第四步:每类图片的数据样本来源是否有,没有的话能否自动造;如果数据样本无法有,那就不适合用模型,可以改用算法规则等方式替代先看效果。

D2C 项目中很多这样的问题,问题本身的定义需要非常精准,并且需要有科学的参考依据,这一点本身就比较难,因为没有可借鉴的先例,只能先用已知的经验先试用,用户测试有问题后再修正,这是一个需要持续迭代持续完善的痛点。

【样本质量】

针对样本问题,我们需要对这部分数据集建立标准规范,分场景构建多维度的数据集,将收集的数据做统一的处理和提供,并以此期望能建立一套规范的数据体系。

在这套体系中,我们使用统一的样本数据存储格式,提供统一的针对不同问题(分类、目标检测)的样本评估工具来评估各项数据集的质量,针对部分特定模型可采取效果较好的特征工程(归一化、边缘放大等)来处理,同类问题的样本也期望能在后续不同的模型里能够流通作比较,来评估不同模型的准确度和效率。

9.png
(数据样本工程体系)

【模型】

针对模型的召回和误判问题,我们尝试收敛场景来提高准确度。往往不同场景下的样本会存在一些特征上的相似点或者影响部分分类局部关键特征点,导致产生误判、召回低,我们期望能够通过收敛场景来做模式化的识别,提高模型准确度。

我们把场景收敛到如下三个场景:无线 C 端营销频道场景、小程序场景以及 PC 中后台场景。这里面几个场景的设计模式都有自己的特色,针对各个场景来设计垂直的识别模型可以高效地提高单一场景的识别准确度。

10.png
(D2C 场景)

3)思考与解法

总的来说,既然使用了深度模型,有一个比较现实的问题是,模型的泛化能力不够,识别的准确率必然不能 100% 让用户满意,除了能够在后续不断地补充这批识别不到的样本数据外,在这之前我们能做什么?

在 D2C 的整个还原链路里,对于识别模型,我们还遵守一个方法论,即设计一套协议或者规则能通过其他方式来兜底深度模型的识别效果,保障在模型识别不准确的情况下用户仍可完成诉求:手动约定 > 规则策略 > 机器学习 > 深度模型。举个例子比如需要识别设计稿里的一个循环体:

  • 初期,我们可以在设计稿里手动约定循环体的协议来达成;
  • 根据图层的上下文信息可做一些规则的判断,来判断是否是循环体;
  • 利用机器学习的图层特征,可尝试做规则策略的更上游的策略优化;
  • 生成循环体的一些正负样本来通过深度模型进行学习。

其中手动约定的设计稿协议解析优先级最高,这样也能确保后续的流程不受阻塞和错误识别的干扰。

imgcook x 云开发平台

了解前端智能化和 imgcook 大致思路之后,那么为什么会选择在云开发平台上集成 imgcook 呢?那就是 imgcook 和云开发平台通过彼此的打通,将能够为双方解决彼此的痛点,无论是为云上开发者,还是 imgcook 开发者都提供了全新的用户体验。

对于 imgcook 开发者来说,其中一个痛点就来自于对于设计稿的管理,以及前后端交互的逻辑,然而通过云开发平台,开发者不再需要在本地安装 Sketch,通过云开发平台直接上传设计稿即可开始生成代码,真正做到了0成本一键生成。

另外云开发平台上直接提供了Midway Serverless 框架,我们通过云开发平台的插件定制化,可以让开发者直接选择某个页面所使用的函数(Function),这样就节省掉编写一些前后端交互的基础逻辑或请求代码。

对于云开发平台的开发者来说,最想得到的便是极速的上线体验和更加便捷的开发体验,imgcook 可以降低云开发平台的使用门槛,比如一位 FaaS 应用工程师不再需要学习如何切图,如何写 CSS,而只需要编写 FaaS 函数的逻辑即可,剩下的前端逻辑代码都可以通过 imgcook 插件在开发平台内即可完成,这是多么棒的体验啊!

那么,接下来就看看如何快速地从0到1生成代码吧。

首先需要先打开云开发平台创建应用,选择 imgcook 创建应用:

11.png

然后在应用的 WebIDE 中通过右键打开 imgcook 云插件,就可以正式开始使用了。

12.png

第一步,在插件中选择“导入”,打开上传设计稿界面:

13.png

第二步,imgcook 可视化编辑器:

14.png

第三步,生成代码:

15.png

第四步,导出代码到应用:

16.png

第五步,上线应用:

$ npm install
$ npm run dev
正在启动,请稍后...
---------------------------------------
开发服务器已成功启动
请打开 >>> http://*****-3000.xide.aliyun.com/
---------------------------------------
感谢使用 Midway Serverless,欢迎 Star!
https://github.com/midwayjs/midway
---------------------------------------

启动成功后通过命令行的地址打开页面效果如下,是不是很简单呢?

17.png

总结

本文通过介绍前端智能化的背景,imgcook 的问题定义以及技术方案,以及如何在云开发平台上使用 imgcook 开始智能开发,总的来说,还是希望让业内的前端工程师们从使用 imgcook 开始,将日常工作中的一些繁琐、耗时的工作交给 AI 来完成,这样能关注工程师本身更感兴趣,也更有价值的事情,也相信不久的将来,前端工程师将借助于 AI 能更加快乐与从容地工作!

点击链接立即体验:https://yunqi.aliyun.com/2020/hol

阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的公众号。”

写在 Dubbo go 的第五年

alicloudnative阅读(5602)评论(0)

头图.png

作者 | 于雨

阿里巴巴云原生公众号后台回复“915”即可查看 dubbogo v1.5.1 项目管理图清晰大图!

引语

dubbogo 项目已进入第五个年头。

项目发展的前两年,我们把 hessian2 协议库、网络库和整体基础框架搭建一番。从 2018 年项目被 Dubbo 官方接纳开始,依托阿里平台,社区开始形成并快速发展。与社区同学们齐心合力之下,如今全面兼容 Dubbo v2.7.x 的 Dubbo-go v1.5.1 已经发布。

立项

一个项目整体必须提炼出核心目标,指明其存在的意义和价值。有了初心,项目发展过程中产生困惑时,才能明确答复 “我是谁?从哪里来?到哪里去”。

1. dubbogo

dubbogo 项目有其自身的 milestone 要求,大致规划了每个阶段的关键里程碑,在项目发展初期仅仅是实现 Dubbo 的某个功能,但在发展过程中会不断结合当下的技术发展潮流,不断修正其未来发展方向。

其发版计划是通过“开发当前版本、规划新版本、根据反馈修正新版本”的模式定义当前版本的开发内容和下一个版本的发展方向。每次发版后会根据社区使用反馈对下一代的发展目标进行修正。

站在吃瓜人的角度,或许可以说出 “dubbogo 不就是 dubbo 的 Go 语言版本嘛,照着抄就是了” 之类的论调。而参与过 dubbogo 项目跟着社区一路走来的人,就知道 dubbogo 并不简单定位于 Dubbo 项目的 Go 语言版本。

dubbogo 初心不变,不同时间对自身定位均有升级。我认为当前 dubbogo 的定位是:

  • 全面兼容 Dubbo;
  • 一个 Go 语言应用通信框架,充分利用作为云原生时代第一语言—Go 语言的优势,扩展 dubbo 的能力。

2. dubbo-go-proxy

dubbogo 项目初期目的是依靠 Dubbo 实现 “bridge the gap between Java and Go” ,目前 dubbogo 正与 Dubbo 齐头并进,已经达到项目立项的目标。有长期生命的通信框架,大概有 5 年的成长期和 5 年的稳定成熟期。目前的 dubbogo 处在成长期和稳定成熟期的过渡期,这意味着社区如果想保持发展态势,就必须开始走多元化道路,发展自己的生态了。

眼下 dubbogo 社区正在集中精力孵化一个新的项目—实现一个基于 dubbogo 的 HTTP 网关,项目的意义是:dubbogo 自身是一个流量控制中间件,在其上扩展项目,其方向很自然就是做一个 proxy/sidecar or gateway,且社区一直有网关这方面的需求。

项目目的如下:

  • 做一个具有生产使用意义的网关;
  • dubbo-go-proxy 验证 dubbogo 的能力,对 dubbogo 未来的进化指出新方向,共同进化;
  • 优化 dubbogo 的稳定性和性能。

团队

项目立项完毕后,就进入招兵买马阶段了。

1. 来源

dubbogo 社区发展初期,其关键成员都是通过提交 issue 或者 pr 的同学撩来的。通过这种方式撩来的同学因为志同道合,有极高的概率同社区一起走下来。dubbogo 社区的 core member 就是这样来的。

其次是与其他公司的合作。dubbogo 本身是一个有着极高生产环境需求的项目,在发展过程中依次与携程、涂鸦、斗鱼、虎牙、蚂蚁金服和阿里集团有过极深的合作,其间与携程的合作对 dubbogo 成型而言极为关键。

另一个途径是与其他社区合作。dubbogo 项目发展过程中,与以下社区合作过:

  • 与 MOSN 社区合作实现 Dubbo Mesh;
  • 与 sentinel 社区合作,在 Dubbo/Dubbo-go 完整接入 sentinel 的降级和限流方案;
  • 与 Apollo 社区合作,在 Dubbo-go 中实现远程配置下发;
  • 与 Nacos 社区合作,实现基于 Nacos 的服务发现。

与其他社区合作的好处是使得双方的项目都受益:扩展双方的能力和使用场景,其次是社区间人员的流动。在合作过程中,dubbogo 自身受益极大,目前有 4 个社区 committer 来自于其它社区。合作完成后并不意味着结束,而是一个新的双赢的开始:社区项目也是发展的,当一个项目有新特性时可以同时快速被另一个项目采用验证,对扩展开发者们的技术能力和人脉也是极为有利的,dubbogo 社区目前的好几个同学同时活跃在多个社区。

dubbogo 项目已经过了草莽阶段,形成了一个的 800 多人的社区群,所以 dubbogo-proxy 项目立项后,很快就在社区群内找到很多项目爱好者。

2. 成员的 qualification

项目发展初期有很多同学会 Java 不懂 Dubbo 不会 Go,最后都通过参与项目提升了自我的能力。当然有些人会担心项目代码的质量,但只要秉持 “Community Over Code” 这个 “Apache Way”,在发展过程中这些问题都不大。

2019 年时,参与 dubbogo 项目的成员中一部分同学平时的工作是进行业务开发,秉承着对中间件通信技术 “我是谁?我从哪里来?要到那里去” 的初心参与 dubbogo 的开发,无论是对 dubbogo 抑或是对其自身技术水平提升都产生了积极的影响。

dubbogo 社区对 dubbogo 发版时间有一定期限要求,所以对参与人员的时间投入也有一定的要求。每个版本的核心功能的 owner,需要保证在 deadline 期限内完成开发任务。

dubbogo 每个版本都有一个发版人,负责相应版本的任务拆分、发展跟踪、代码 Review 和最后的测试验收,这就要求发版人自身的技术水平和时间投入极高。目前 dubbogo 每个大版本的发版人都不是同一个人,每次 dubbogo 发版,都意味着每个发版人的体力和精力的极大付出。于某在此致敬历届发版人!

管理

项目立项后,就需要明确发展大方向、发展 milestone、版本规划、以及一段时间内的具体的开发规划。项目发展初期,Roadmap 可以不清晰,先摸着石头过河,在发展过程中逐步明确其内容。

1. 需求收集

dubbogo 项目发展初期,其目标仅仅是实现 dubbo 某个版本的功能, 所以其需求收集并不用花费很久时间。随着 2019 年 8 月份发布 v1.0 后,dubbogo 越来越多地被多家生产厂商投入生产使用环境中,目前其需求方来源如下:

  • 实现 dubbo 某个版本的功能;
  • 实际使用方的生产需求;
  • 为紧跟当下最近技术发展方向而进行的技术预演。

dubbogo 当前的 K8s 注册中心技术方案就是紧跟最新技术发展方向而进行预演的极好例证,其发展时间线如下:

  • 2019 年 7 月,随着阿里集团和蚂蚁金服在云原生方向的推波助澜,阿里 dubbo 开发团队并未给出可靠的技术方向,dubbogo 社区 core members 也都没有云原生方向的技术积累和相应人才,决定先开发一个基于 kube-apiserver 的注册中心,以进行技术储备;
  • 2019 年 8 月, 调研 dubbo 的 K8s 注册中心方案后,dubbogo 社区决定抛开它独立实现一个,争取以最低代价把 dubbo 应用迁移到 K8s 环境中运行起来,同时决定未来的发展方向是 dubbogo operator;
  • 2019 年 11 月,社区的王翔同学给出了初步实现,在 2020 年 1 月随 dubbogo v1.2 版本发布;
  • 2020 年 4 月,有用户要求在 K8s 环境中 consumer 可跨 namespace 访问 provider,相应实现在 2020 年 7 月随着 dubbogo v1.5 版本发布;
  • 2020 年 5 月,dubbogo 社区和 mosn 社区合作实现了 dubbo mesh;
  • 2020 年 6 月,社区意识到 kube-apiserver 是系统的运维态 IaaS 层的核心组件,不应该跨过 PaaS 层直接暴露给应用层,否则应用层使用不当或者框架自身的流量方面的 bug 把 kube-apiserver 打垮后将造成整个系统的 P0 级故障,dubbogo v1.6 应当给出 dubbogo operator 的具体实现;
  • 2020 年 7 月,dubbogo v1.5 发布后,社区已经知道完全可以把目前的 kube-apiserver 注册中心的实现独立成为一个 dubbogo operator,未来的方向是结合 Istio 拓展其灰度发布、限流、故障注入和配置动态下发能力。

至于 dubbo-go-proxy ,dubbogo 社区并不打算借鉴其他项目,完全依靠社区同学贡献各自想法后,进行项目需求收集。目前 dubbogo 社区已经收集完毕 dubbo-go-proxy 的项目需求方的意见,社区已有 5 位同学参与项目一期开发,预计 10 月份发布初版。

2. 项目管理

需求收集完毕,定义近期一段时间内的开发目标后,就进入了项目任务拆解和项目开发管理阶段。像 dubbogo 和 dubbo-go-proxy 这种后来者项目,处于追赶阶段,个人理解它们并没有所谓的后发优势,更没有特定的技术优势,能够做的就是快速迭代,缩短与竞品的差距。

dubbogo 要求接受开发任务的各个 feature owner 必须在某个 deadline 前完成相应的开发任务。当然,feature 的等级不同,非核心 feature 【如技术预演性的 feature】允许 delay,顺延发布也无不可。

我们在项目每个版本的需求收集阶段,会把爱好者统一拉入一个小群进行沟通交流。进入开发阶段时,由于项目时间 deadline 限定以及技术匹配度两项要求,每个版本就很自然能选出能够留下来参与项目开发的人。最终参与每个版本开发的人尽量不要超过 7 个人,否则沟通成本就会剧增。

下图是 dubbogo v1.5.1 的项目管理图(阿里巴巴云原生公众号后台回复“915”即可查看清晰大图)

1.png

其有任务分解、技术风险以及风险预案。

2.png

工具是生产力,目前以 dubbogo 项目开发进度跟踪工具使用 Github Projects。如上图,每个子任务进度,这个工具都会及时显示,相应的任务 owner 可以及时根据任务进度和 deadline ,调整开发计划。更进一步的好处是,没有人会对工具产生意见,摆脱“交通基本靠走,通讯基本靠吼”的沟通模式,减少版本发版人和 feature owner 之间的戾气。

3. 代码质量

开源项目的开发任务不仅仅是开发代码,也不意味着因为各个 owner 仅仅是业余时间参与开源项目就可以降低对代码质量要求。

工具就是生产力,合适的工具能够减少人工工作量和提升代码质量。dubbogo 在项目开发过程中的各个阶段都用到了如下工具:

  • auto-comment:contributor 提出 issue 或者 pr 后,可很方便地发出预先定制的评语;
  • hound:一个 Go 语言项目静态代码检测工具,自动 Review 代码;
  • travis:一个 Github 项目自动化测试工具,可自动执行代码单测和用户自定义的集成测试,并发出钉钉通知;
  • 人工 Review:dubbogo 社区要求每个 pr 至少有三个 committer 级别的人 Review 通过;
  • goreportcard:一个很好的 Github 项目静态代码检测工具;
  • gitee:作为国内一个比较强大的代码托管网站,免费为项目提供了一些代码安全和静态代码质量检测工具,dubbogo 也经常使用,受益良多;
  • 代码规范,社区内部有一份简单的代码规范,并随着项目发展不断完善。

展望

dubbogo 项目每次发完版本,发版人都会首先发出一份 “What’s New”,除了总结最新版本的特性外,还会总结其近期进展并对未来发展进行规划,以帮助项目爱好者和使用者了解其实现思路和使用方法。

dubbogo 自身还有很多缺点,如:

  • 网站建设和文档质量都有待改进;
  • API 用户友好度不够;
  • 配置文件过多且没有合理的文档说明导致入门门槛高;
  • 整体性能改进,很多地方可添加调用链的缓存以减小锁竞争;
  • 添加 prometheus 指标,继续提高 可观测性;
  • 在协议层面支持其他微服务框架,实现原生通信,以继续提升其互联互通性;
  • dubbo-samples 用例不够丰富,继续添加测试用例,以减小入门门槛;

希望借助社区之力,在 dubbogo 发展过程中消化并解决掉这些问题,dubbogo 社区【钉钉群号 23331795】与 dubbogo 同在。

作者简介

于雨,一个有十多年服务端基础架构研发一线工作经验的程序员,目前在蚂蚁金服可信原生部从事容器编排和 service mesh 工作。热爱开源,从 2015 年给 Redis 贡献代码开始,陆续改进过 Muduo/Pika/Dubbo/Dubbo-go 等知名项目。

阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的公众号。”

阿里云 OpenYurt 成为 CNCF 沙箱项目,加速原生 Kubernetes 边缘场景全覆盖

alicloudnative阅读(5072)评论(0)

1.png

2020 年 9 月 9 号,经 CNCF 技术监督委员会投票一致同意,阿里巴巴云原生边缘计算平台 OpenYurt 正式成为 CNCF 沙箱级别项目(Sandbox Level Project),标志着 OpenYurt 在边缘计算场景中构建云原生基础设施的能力受到了行业的广泛认可。

OpenYurt 项目地址:https://github.com/alibaba/openyurt

OpenYurt 致力于将阿里云在云原生边缘计算领域的大规模实践经验回馈给开源社区,加速云计算向边缘全面延伸的进程,与社区共建未来云原生边缘计算架构的统一标准。

如何打造边缘基础设施成为新课题

Gartner 预测,到 2022 年,超过 50% 的企业生成数据将在数据中心或云之外进行创建和处理,20% 的新工业控制系统将拥有分析和 AI 边缘推理能力,至少 50% 的现场物联网项目将使用容器进行边缘应用程序生命周期管理。边缘计算正在成为新时代网络、计算、存储、应用等近端整体解决方案的基础设施和基础能力。

然而,边缘计算规模和业务复杂度的日益提升对效率、可靠性、资源利用率等能力提出了新的诉求。传统云计算中心集中存储、计算的模式已经无法满足边缘设备对于时效、容量、算力的需求,如何打造边缘基础设施成了一个新课题。

OpenYurt 应运而生,边缘场景全覆盖

2017 年底,作为典型的边缘计算业务,阿里云物联网(IoT)和 CDN 服务正面临着产品规模的爆发式增长、运维复杂度急剧攀升、运维效率不高的“三难”境地,边缘应用运维管理模式的全面转型成为亟待解决的问题。

秉承“Extending your native Kubernetes to  Edge”的非侵入式设计理念,云原生边缘计算平台 OpenYurt 诞生于阿里云容器服务团队。与其他类似产品不同的是,OpenYurt 拥有可实现边缘计算全场景覆盖的能力。在短短两年内,作为公共云服务 ACK@Edge 的核心框架,OpenYurt 已实现全网覆盖和本地覆盖的全场景落地,全网覆盖的应用场景如 CDN、音视频直播、物联网、物流、工业大脑、城市大脑等;本地覆盖的应用场景和案例如阿里云 LinkEdge、优酷、盒马、AIBox、银泰商城等,其中,帮助优酷实现端到端延迟降低 75%,机器成本节省 50%;盒马鲜生实现新门店开服效率提升 70%,资源成本节省 50% 以上。

2.png

Kubernetes 生态全兼容,打造边缘云原生基础设施

自 OpenYurt 诞生以来,接管业务容器数量超过百万,覆盖新零售、医疗、物联网、在线教育、边缘智能、交通等众多行业,受到了业界广泛欢迎与认可。这一切得益于 OpenYurt 沿用了目前业界流行的“中心管控、边缘自治”的边缘应用管理架构,以非侵入式增强 Kubernetes 的设计理念,将云原生能力拓展至边缘端,可降低资源成本、降低运维复杂度、获得云边一致性运维体验、实现大规模边缘业务轻松管理。

3.png
OpenYurt 架构图

OpenYurt 主要特性包括:

  • Kubernetes 生态全兼容:对原生 Kubernetes “零”侵入,保证对原生 Kubernetes 完整生态的全部兼容,OpenYurt 集群可以紧跟 Kubernetes 社区版本升级节奏,同时也意味云原生社区主流技术(如 Service mesh, Serverless 等)可以轻松落地 OpenYurt;
  • 边缘异构资源支持:对不同边缘节点硬件架构(x86 / arm / arm64 等),硬件规格,通信协议提供一致体验;
  • 高可靠/稳定性:基于边缘自治和边缘单元化能力,为多地域,大规模的边缘应用的持续稳定运行提供保障。支持各类开源 AI 系统(如 Tensorflow,pytorch 等),为 AI 用户提供最佳体验;
  • 云平台无关:OpenYurt 可以轻松部署在任何公共云的 Kubernetes 服务中。

作为对原生 Kubernetes 完整生态全部兼容的智能开放平台,OpenYurt 将以更灵活和可扩展的体系结构方向发展,不断增强开源开发者友好体验。阿里云容器服务负责人易立表示OpenYurt 还将基于行业场景与 5G、AI、大数据、区块链等新兴技术结合,驱动企业业务加速创新。未来 OpenYurt 将与社区并肩、与生态同行,致力于推进云原生技术在边缘计算领域的生态建设与普及,与全球开发者一起拓展云原生的边界。

欢迎大家参与该项目的共建,有问题可以钉钉搜索群号:31993519,进群交流!

阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的公众号。”

2020 年微服务项目活跃度报告

alicloudnative阅读(3476)评论(0)

头图.png

导读:2020 年 8 月 18 日,首届云原生微服务大会于线上召开,会议首日,阿里云资深技术专家、CNCF TOC 李响 Keynote 演讲中正式发布了《 2020 年微服务领域开源数字化报告》。

微服务体系就像是一剂催化剂,可以加速数据和业务结合的过程,更好地提升生产力,从而实现业务的提升。本项目旨在通过建立一份建立在微服务领域的相对完整、可以反复进行推演的数据报告(报告、数据、算法均开源),分析微服务框架项目以及 Spring Cloud 项目的 GitHub 开发者行为日志,通过多维度数据分析的视角,来观察微服务领域的开源现状、进展趋势、演化特征等问题。

本报告根据 2020 年 1 月到 6 月的 GitHub 日志进行统计。值得一提的是,报告显示 Apache Dubbo 作为中国本土开源的项目,在微服务框架中排名第 5,全球排名跻身 693;Spring 社区第一个国产 Spring Cloud 项目 Spring Cloud Alibaba 作为开源的微服务全家桶,在 Spring Cloud 榜单中居于榜首。

关键词:微服务、开源、行为数据、GitHub

背景

随着业务的扩张,单体应用架构的开发、部署和运维都会越来越慢,越来越复杂,甚至在单体架构应用开发中敏捷模式无法施展开。基于此,具有更高独立性、可用性和弹性的微服务应运而生。从结构上看,微服务架构将一个应用拆分成多个松耦合的服务,这些服务之间通过某种协议(REST、rpc 等)进行互相协作,完成原单体架构功能,但提供更灵活的部署模式,更容易扩展,降低了开发、运维上的复杂度。微服务的核心思想就是分而治之。微服务是商业应用程序发中最热门的新事物。微服务这个词取代了敏捷、DevOps 和 RESTful。

2020 年 7 月 O’Reilly 公布了一份关于企业微服务市场现状的数据调研。报告显示,在访问了全球 1502 名软件工程师、系统和技术架构师、工程师以及决策者后,有 77% 的组织反馈采用了微服务,其中 92% 的组织成功使用了微服务。了解并分析微服务领域开源项目的发展,有助于掌握该领域的发展趋势,从而帮助提高企业的竞争力。

因此,进一步深入研究微服务领域的开源数字化现状具有非常重大的意义。

总体宏观统计结果

1. Key Takeaways

  • Quarkus 作为云原生微服务框架,在微服务框架中活跃度排名第一,全球 GitHub 开源项目活跃度中排名 40;
  • Spring 作为 Java 微服务框架事实标准,Spring Cloud 和 Spring Boot 项目在微服务框架中活跃度分别位列第二和第三;
  • Apache Dubbo 作为中国本土开源的项目,微服务框架活跃度排名第五,全球 GitHub 开源项目活跃度中排名跻身 693;
  • 在厂商 Spring Cloud 项目中,Spring Cloud Alibaba 活跃度排名第一。

2. 微服务框架榜单

根据附录中给出的项目活跃度定义,我们使用 2020 年 1 月~6 月的数据对微服务框架相关的项目及社区进行了活跃度的统计与排名,结果如下表所示,quarkusio/quarkus 项目、spring-cloud 社区、spring-projects / spring-boot 项目分别位于 Top1,Top2,Top3。需要注意的是,global_rank 是指该项目在全球 GitHub 开源项目中的活跃度排名。

1.jpg
(点击查看大图)

【注】:表格中的 developer 是指执行了五种动作:Issue comment、Open issue、Open pull request、Pull reuqest review comment 和 Pull request merged 的开发者。

3. Spring Cloud 榜单

根据附录中给出的项目活跃度的定义,我们使用 2020 年 1 月~6 月的数据对 Spring Cloud 项目进行了活跃度的统计与排名,结果如下表所示:

2.jpg
(点击查看大图)

【注】:表格中的 developer 是指执行了五种动作:Issue comment、Open issue、Open pull request、Pull reuqest review comment 和 Pull request merged的开发。

展望

此次开源项目数据报告针对微服务领域的项目进行了研究,主要是提供了一些统计数据。未来,会对社区协作关系做可视化的呈现;在数据挖掘的层面,会基于真实数据挖掘数据背后的价值。希望报告所倡导的开源开放的业态有助于推动中国微服务领域的开源走向更深层次。

致谢

本次报告由 X-lab 开放实验室撰写。

3.png

X-lab 开放实验室是由来自华东师范大学、同济大学的师生所构成的开放创新共同体,专业背景包括计算机科学、数据科学及其相关跨学科,长期思考并实践教育与开源两大主题。

附录:数据集及方法

1. 数据集

  • 时间:2020 年 1 月~2020 年 6 月
  • 微服务框架数据

4.jpg

  • spring-cloud 数据集

5.jpg

2. 活跃度计算方式

(1)开发者活跃度

开发者活跃度,其定义为某特定 GitHub 账号在一段时间内在某特定 GitHub 项目中的活跃评价指标。其活跃度由该账号在该项目中的行为数据决定。本报告中所关心的行为包含如下几种:

  • Issue comment:在 issue 中参与讨论是最基本的行为,每个评论计入 1 次;
  • Open issue:在项目中发起一个 issue,无论是讨论、Bug 报告或提问,对项目都是带来活跃的,每个发起的 issue 计入 1 次;
  • Open pull request:为项目提交一个 PR,表示已对该项目进行源码贡献,则每次发起一个 PR 计入 1 次;
  • Pull reuqest review comment:对项目中的 PR 进行 review 和讨论,需要对项目有相当的了解,并且对项目源码的质量有极大帮助,每个评论计入 1 次;
  • Pull request merged:若有 PR 被项目合入,即便是很小的改动,也需要对项目有较为深入的理解,是帮助项目进步的真切贡献,则每有一个 PR 被合入计入 1 次。

以上 5 个种行为在该报告模型中,具有不一样的权重,其加权值逐级增加,加权值分别为 1、2、3、4、5,即:

6.png
7.jpg

(2)项目活跃度

项目活跃度,其定义为某特定项目在一段时间内的活跃评价指标。其活跃度由该段时间内在本项目中产生活跃的开发者活跃度加权计算得到,即:

8.png

使用开方的加权方式,用于抹平因核心开发者活跃度过高而导致项目活跃度过高,在该计算方式下,活跃度计算方式对参与人数较多而活跃情况平均的项目更加友好。

本报告将周期性更新、发布,报告长期沉淀地址:https://github.com/alibaba/OpenSourceReport

首届云原生微服务大会

首届云原生微服务大会正在火热直播中,点击 PC 端地址即可观看:https://developer.aliyun.com/topic/microservices2020#/

阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的公众号。”

我在阿里写代码学会的六件事

alicloudnative阅读(2473)评论(0)

8.14头图.png

写了多年的代码,始终觉得如何写出干净优雅的代码并不是一件容易的事情。按 10000 小时刻意训练的定理,假设每天 8 小时,一个月 20 天,一年 12 个月,大概也需要 5 年左右的时间成为大师。其实我们每天的工作中真正用于写代码的时间不可能有 8 个小时,并且很多时候是在完成任务,在业务压力很大的时候,可能想要达到的目标是如何尽快的使得功能 work 起来,代码是否干净优雅非常可能没有能放在第一优先级上,而是怎么快怎么来。

在这样的情况下是非常容易欠下技术债的,时间长了,这样的代码基本上无法维护,只能推倒重来,这个成本是非常高的。欠债要还,只是迟早的问题,并且等到要还的时候还要赔上额外的不菲的利息。还债的有可能是自己,也有可能是后来的继任者,但都是团队在还债。所以从团队的角度来看,写好代码是一件非常有必要的事情。如何写出干净优雅的代码是个很困难的课题,我没有找到万能的 solution,更多的是一些 trade off,可以稍微讨论一下。

代码是写给人看的还是写给机器看的?

在大部分的情况下我会认为代码是写给人看的。虽然代码最后的执行者是机器,但是实际上代码更多的时候是给人看的。我们来看看一段代码的生命周期:开发 –> 单元测试 –> Code Review –> 功能测试 –> 性能测试 –> 上线 –> 运维、Bug 修复 –> 测试上线 –> 退休下线。开发到上线的时间也许是几周或者几个月,但是线上运维、bug 修复的周期可以是几年。

在这几年的时间里面,几乎不可能还是原来的作者在维护了。继任者如何能理解之前的代码逻辑是极其关键的,如果不能维护,只能自己重新做一套。所以在项目中我们经常能见到的情况就是,看到了前任的代码,都觉得这是什么垃圾,写的乱七八糟,还是我自己重写一遍吧。就算是在开发的过程中,需要别人来 Code  Review,如果他们都看不懂这个代码,怎么来做 Review 呢。还有你也不希望在休假的时候,因为其他人看不懂你的代码,只好打电话求助你。这个我印象极其深刻,记得我在工作不久的时候,一次回到了老家休假中,突然同事打电话来了,出现了一个问题,问我该如何解决,当时电话还要收漫游费的,非常贵,但是我还不得不支持直到耗光我的电话费。

所以代码主要还是写给人看的,是我们的交流的途径。那些非常好的开源的项目虽然有文档,但是更多的我们其实还是看他的源码,如果开源项目里面的代码写的很难读,这个项目也基本上不会火。因为代码是我们开发人员交流的基本途径,甚至可能口头讨论不清楚的事情,我们可以通过代码来说清楚。代码的可读性我觉得是第一位的。各个公司估计都有自己的代码规范,遵循相关的规范保持代码风格的统一是第一步(推荐谷歌代码规范和微软代码规范)。规范里一般都包括了如何进行变量、类、函数的命名,函数要尽量短并且保持原子性,不要做多件事情,类的基本设计的原则等等。另外一个建议是可以多参考学习一下开源项目中的代码。

KISS (Keep it simple and stupid)

一般大脑工作记忆的容量就是 5-9 个,如果事情过多或者过于复杂,对于大部分人来说是无法直接理解和处理的。通常我们需要一些辅助手段来处理复杂的问题,比如做笔记、画图,有点类似于在内存不够用的情况下我们借用了外存。

学 CS 的同学都知道,外存的访问速度肯定不如内存访问速度。另外一般来说在逻辑复杂的情况下出错的可能要远大于在简单的情况下,在复杂的情况下,代码的分支可能有很多,我们是否能够对每种情况都考虑到位,这些都有困难。为了使得代码更加可靠,并且容易理解,最好的办法还是保持代码的简单,在处理一个问题的时候尽量使用简单的逻辑,不要有过多的变量。

但是现实的问题并不会总是那么简单,那么如何来处理复杂的问题呢?与其借用外存,我更加倾向于对复杂的问题进行分层抽象。网络的通信是一个非常复杂的事情,中间使用的设备可以有无数种(手机,各种 IOT 设备,台式机,laptop,路由器,交换机…), OSI 协议对各层做了抽象,每一层需要处理的情况就都大大地简化了。通过对复杂问题的分解、抽象,那么我们在每个层次上要解决处理的问题就简化了。其实也类似于算法中的 divide-and-conquer, 复杂的问题,要先拆解掉变成小的问题,从而来简化解决的方法。

KISS 还有另外一层含义,“如无必要,勿增实体” (奥卡姆剃刀原理)。CS 中有一句 “All problems in computer science can be solved by another level of indirection”, 为了系统的扩展性,支持将来的一些可能存在的变化,我们经常会引入一层间接层,或者增加中间的 interface。在做这些决定的时候,我们要多考虑一下是否真的有必要。增加额外的一层给我们的好处就是易于扩展,但是同时也增加了复杂度,使得系统变得更加不可理解。对于代码来说,很可能是我这里调用了一个 API,不知道实际的触发在哪里,对于理解和调试都可能增加困难。

KISS 本身就是一个 trade off,要把复杂的问题通过抽象和分拆来简单化,但是是否需要为了保留变化做更多的 indirection 的抽象,这些都是需要仔细考虑的。

DRY (Don’t repeat yourself)

为了快速地实现一个功能,知道之前有类似的,把代码 copy 过来修改一下就用,可能是最快的方法。但是 copy 代码经常是很多问题和 bug 的根源。有一类问题就是 copy 过来的代码包含了一些其他的逻辑,可能并不是这部分需要的,所以可能有冗余甚至一些额外的风险。

另外一类问题就是在维护的时候,我们其实不知道修复了一个地方之后,还有多少其他的地方还需要修复。在我过去的项目中就出现过这样的问题,有个问题明明之前做了修复,过几天另外一个客户又提了类似的问题出现的另外的路径上。相同的逻辑要尽量只出现在一个地方,这样有问题的时候也就可以一次性地修复。这也是一种抽象,对于相同的逻辑,抽象到一个类或者一个函数中去,这样也有利于代码的可读性。

是否要写注释

个人的观点是大部分的代码尽量不要注释。代码本身就是一种交流语言,并且一般来说编程语言比我们日常使用的口语更加的精确。在保持代码逻辑简单的情况下,使用良好的命名规范,代码本身就很清晰并且可能读起来就已经是一篇良好的文章。特别是 OO 的语言的话,本身 object(名词)加 operation(一般用动词)就已经可以说明是在做什么了。重复一下把这个操作的名词放入注释并不会增加代码的可读性。并且在后续的维护中,会出现修改了代码,却并不修改注释的情况出现。在我做的很多 Code Review 中我都看到过这样的情况。尽量把代码写的可以理解,而不是通过注释来理解。

当然我并不是反对所有的注释,在公开的 API 上是需要注释的,应该列出 API 的前置和后置条件,解释该如何使用这个 API,这样也可以用于自动产品 API 的文档。在一些特殊优化逻辑和负责算法的地方加上这些逻辑和算法的解释还是非常有必要的。

一次做对,不要相信以后会 Refactoring

通常来说在代码中写上 TODO,等着以后再来 refactoring 或者改进,基本上就不会再有以后了。我们可以去我们的代码库里面搜索一下 TODO,看看有多少,并且有多少是多少年前的,我相信这个结果会让你很惊讶(欢迎大家留言分享你查找之后的结果)。

尽量一次就做对,不要相信以后还会回来把代码 refactoring 好。人都是有惰性的,一旦完成了当前的事情,move on 之后再回来处理这些概率就非常小了,除非下次真的需要修改这些代码。如果说不会再回来,那么这个 TODO 也没有什么意义。如果真的需要,就不要留下这个问题。我见过有的人留下了一个 TODO,throw 了一个 not implemented 的 exception,然后几天之后其他同学把这个代码带上线了,直接挂掉的情况。尽量不要 TODO, 一次做好。

是否要写单元测试?

个人的观点是必须,除非你只是做 prototype 或者快速迭代扔掉的代码。

Unit tests are typically automated tests written and run by software developers to ensure that a section of an application (known as the “unit”) meets its design and behaves as intended. In procedural programming, a unit could be an entire module, but it is more commonly an individual function or procedure. In object-oriented programming, a unit is often an entire interface, such as a class, but could be an individual method.

From Wikipedia

单元测试是为了保证我们写出的代码确实是我们想要表达的逻辑。当我们的代码被集成到大项目中的时候,之后的集成测试、功能测试甚至 e2e 的测试,都不可能覆盖到每一行的代码了。如果单元测试做的不够,其实就是在代码里面留下一些自己都不知道的黑洞,哪天调用方改了一些东西,走到了一个不常用的分支可能就挂掉了。我之前带的项目中就出现过类似的情况,代码已经上线几年了,有一次稍微改了一下调用方的参数,觉得是个小改动,但是上线就挂了,就是因为遇到了之前根本没有人测试过的分支。单元测试就是要保证我们自己写的代码是按照我们希望的逻辑实现的,需要尽量的做到比较高的覆盖,确保我们自己的代码里面没有留下什么黑洞。关于测试,我想单独开一篇讨论,所以就先简单聊到这里。

要写好代码确实是已经非常不容易的事情,需要考虑正确性、可读性、鲁棒性、可测试性、可以扩展性、可以移植性、性能。前面讨论的只是个人觉得比较重要的入门的一些点,想要写好代码需要经过刻意地考虑和练习才能真正达到目标!

首届云原生微服务大会

首届云原生微服务大会 PC 端地址:https://developer.aliyun.com/topic/microservices2020#/

阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的公众号。”

Kubernetes 容灾解决方案的关键能力

Portworx阅读(2546)评论(0)

Kubernetes 容灾解决方案关键能力

我们面临着不断地需要实施和部署新的软件应用、发展新的商业模式、以及吸引新的客户。通过Kubernetes,我们可以采用云原生方式来进行软件的开发、部署和运维。

基于Kubernetes开发和运行的应用,对于我们实现我们的商业目标,非常重要。但新技术的导入,也会要求我们考虑更多:新的开发方法、新的团队、新的工程师、新的技术、新的合作伙伴、新的供应商、新的挑战。

对CIO们来说,将关键应用转移到Kubernetes上的最大挑战之一,就是容灾恢复能力。

在投入大量资金开发了Kubernetes上的应用后,我们最担心的就是:一旦出现我们无法控制的意外事件,我们的应用变得无法访问。如:云供应商服务意外停止、数据中心电力中断、云服务中断、网络连接中断等。导致用户无法访问应用后,用户满意度大幅下降。

根据著名研究机构Uptime Institute的报告,通常发生服务中断,一般我们会归因到第三方服务上,如托管服务供应商或云服务供应商。31%的服务中断是由由我们无法控制的因素导致的,如:网络错误(30%),IT/软件错误(28%)。对于Kubernetes上的应用,我们需要一个可靠的容灾恢复方案。

根据451 Research的报告,对于关键性应用来说,57%的应用要求RPO<1小时,48%要求RTO<1小时。即使是非关键应用,也有容灾恢复的需求。这对已经满负荷工作的IT团队来说都是较大的压力。

在这样的情况下,企业的IT团队,需要为诸多企业级应用交付强健的容灾恢复方案。

要点小结

Portworx解决了云原生Kubernetes应用企业级容灾的三个关键难点。

基于Kubernetes底层原生开发的PX-DR:

  • 以Kubernetes原生方式进行保护和恢复:容器颗粒度的保护、命名空间可感知。
  • 可应用感知的整体企业级解决方案、而不是多种方法的应用复合。
  • 操作简单,可实现零数据损失的跨云自动化快速恢复。

Kubernetes容灾解决方案,不仅需要操作简单方便,而且需要对容器化应用的技术细节进行有效感知。因此,一个为Kubernetes原生构建的、简单、易用、方便的容灾恢复方案变得更加重要。

Kubernetes应用保护的主要难点

容器的基本结构原理与虚拟机有着根本的不同

容器化应用与虚拟机中的应用有很大不同。为了有效的保护和恢复容器化应用,我们需要在分布式系统中编排执行一系列复杂的操作。这是因为应用是同时运行在多个容器里的,并且这些容器存在于Kubernetes集群里的不同的节点之上。

相对于在过去15年里我们常见的基于虚拟机的单体应用来说,这是架构上的很大不同。

传统的备份和恢复方案对于虚拟机的应用来说已足够。但是对于Kubernetes和容器来说,就不再适合。使用传统的基于VM的备份方案,不仅会让你失去对系统安全的控制,甚至会在关键时候导致应用不可用或者数据丢失,这是存在较大风险的。

容器应用需要智能化的自动恢复

在出现灾难事件后,恢复一个Kubernetes应用,并不是仅在另一个区域重新启动一个新容器那么简单。简单的快照无法有效确保数据的一致性。

容器应用的组件都是单独部署和单独扩展的,每个容器都有自己的容器镜像、部署配置、状态规则、外部配置、运维周期、依赖关系和数据。配置数据和应用的商业逻辑通常是作为元数据进行存储,保存在Kubernetes集群上,并且需要被保护和恢复,以确保应用能够正常的工作。

今天的容器化应用不再仅仅是一个只包括容器镜像和数据的单体。处于微服务架构下的应用,包括前端服务和中间件层。中间件层包括大量的正在运行商业逻辑的中间件,并且它们都连接到了持久数据服务上。这个完整的堆栈都需要被作为一个整体来进行备份和恢复。

一些流行的数据服务,如Kafka、Cassandra、Elastic、MySQL、MongoDB,是由不同的社区来创建的,每一个的运维管理和要求的技能都很不一样。

分布式数据服务的广泛采用,要求我们重新思考我们的数据保护机制,需要同时考虑数据、以及运维中的元数据。

零数据损失情况下的跨云快速恢复

备份和数据保护是非常重要的。在零数据损失的情况下,及时的恢复应用是容灾恢复最重要的目标。

超过53%的组织认为,对于关键应用来说,RTO(恢复时间目标)应该小于1个小时,但实际上,超过50%的应用需要1~4小时来恢复。因此为了达到理想的可用性目标,我们还有一定的差距。

对于商业组织来说,拥有有效的应用保护和恢复能力,正在变得越来越重要。超过65%的大型组织,已经实施部署了混合云/多云的策略。而其中的31%,正在同时使用超过2个以上的公有云服务。企业不可能从每一个单独的基础设施服务商,或者云服务商那里分别采购它们自行定制的解决方案。

Portworx为Kubernetes提供数据保护

Portworx是基于Kubernetes和容器的原生方式构建的。我们创建了一系列的存储和数据管理解决方案,专门来解决企业在现代化IT架构中面临的挑战。

Portworx PX-DR产品的定位,是为了保护Kubernetes应用,以达到零数据损失的快速恢复,并且赋能团队可以快速的掌握使用,不需要过多深入到每一个容器化应用的技术细节。

为Kubernetes原生设计

容器化应用通常跨多个主机,运行在多个容器里。通过Pods和命名空间来运行。Portworx PX-DR按照原生Pods和命名空间构建的方式来运行,从而让我们可以在容器颗粒度和命名空间层面上来对应用进行保护。

通过保护Pod和整个命名空间,不论应用如何配置或者应用如何在集群上跨主机来运行,我们都可以容易的选择应用并进行保护。

虽然应用是复杂的,我们采用快照操作,就可以对应用进行保护。Portworx的数据保护解决方案,让我们可以在另一个Kubernetes集群上快速的恢复和重启应用,不论集群是位于什么样/什么位置的云服务之上。

通过保护应用、应用的配置、以及应用的数据,Portworx提供了真正的Kubernetes原生容灾恢复解决方案。

应用可感知

今天的容器化应用变的越来越复杂:展现技术、消息流、分析、数据存储,每种技术都由不同的社区来构建,并且需要不同的运维方法。

为了达到应用的扩展性和数据保护,我们要么严格限制我们所采用的技术的来源数量,这会降低我们的灵活性。或者我们采用有效的解决方案来原生化的处理各种复杂性问题,从而更快的推动数字化。

这意味着我们可以持续性的创新和部署新的应用,而不需要对每一个技术都有深入的了解。Portworx会帮助我们完成底层的集成。我们只需要制定我们的应用保护时间计划,来满足可用性需要。

跨多云/混合云环境下的一致性的、可靠的容灾恢复 

我们的应用并不是处于单一控制的环境中。即便我们仅仅使用单一的云服务提供商,我们也会跨区域来部署应用。当我们使用混合云/多云环境时,复杂度就进一步提升。

Portworx PX-DR是按Kubernetes原生的分布式方式构建的。能够交付零数据损失(零RPO)和快速恢复时间(低RTO)是保持系统稳健的重要能力。

当应用被部署在彼此高速连接的云平台上时,例如,由专线连接的不同区域的云服务,Portworx可以帮助我们达到零RPO和零RTO。这意味着不会有数据损失,并且在发生问题时,可以即时恢复。

如果应用部署采用传统配置方式,如跨不同地理位置的数据中心的部署,通过Portworx,我们可以在几秒至几分钟的时间内恢复应用,并且不会有数据损失。

大多数企业的数据保护目标是1小时内恢复应用11,使用Portworx PX-DR数据保护,可以让我们达到更加快速的恢复。

如果当我们正在使用的某个云服务发生错误后,而我们的应用依然在运行,我们的客户满意度会更高。

加拿大皇家银行RBC的成功案例

加拿大皇家银行RBC正在通过Red Hat OpenShift使用Kubernetes,但是无法达到可用性的要求。通过Portworx企业级数据管理平台和PX-DR,RBC达到了零RPO、以及小于2分钟的RPO指标。这意味着RBC可以在2分钟内在另一个数据中心恢复应用,而没有数据损失。

结论

我们的商业环境在快速演进,我们的竞争对手在快速追赶。在互联网时代,客户的体验是成功的关键,我们无法允许让客户不快的事情的发生。

错误时常会出现,服务中断时常会发生,云服务时常会宕机。我们需要一个强健、灵活和快速的恢复解决方案,来保证我们的应用能够持续性的满足客户的需要。

我们在Kubernetes上部署的容器化应用是我们的增长引擎,但是容器化应用与传统应用有很大的不同。需要有针对性的通过Kubernetes和容器的方式来对应用进行保护。而不是传统的数据保护方式。

为了让DevOps能够充分的发挥效能,如果每一个技术都需要专业的工程师来应对,会极大的增加我们的投入。我们的容灾恢复方案需要与这些技术事先集成,可感知应用,这样通用型的运维工程师就可以很好的处理问题。

混合云/多云架构变得普遍,我们不能允许云服务提供商的任何错误对我们的应用造成影响。不论我们选择什么样的基础架构服务商,都应确保我们应用的可用性。

下一步

Portworx已服务全球2000强企业超过5年。我们理解您的目标、您的难点。我们愿竭诚帮助您。

这里是PX-DR的介绍视频,欢迎观看。

https://v.qq.com/x/page/m30648ptszh.html

DevOps最佳实践“建设单一可信源”

JFrog捷蛙阅读(3140)评论(0)

怎么理解单一可信源呢?经过思考之后,笔者觉得用我们小时候最常听到的一句话来描述:“事实的真相只有一个”,没错,就是柯南的这句话,来形容单一可信源最为贴切。单一可信源这个概念其实很早就被各个行业所提出,尤其是在身份管理系统中(比如我们的身份证),打造单一可信源可以说是重要的一项工作。那么什么是单一可信源呢?我们先来了解下面两个概念

Single source of truth(SSOT)

SSOT是在信息系统的设计理论中,构建信息模型和关联模式的实践,确保每个数据元素只能在一个地方掌握。

Single version of truth(SVOT)

SVOT是一种向决策者提供清晰准确的数据的实践,确保数据的准确性、唯一性、及时性、对齐性等。

 

单一可信源与上面两个概念有什么关系呢, “单一可信源”中的两个形容词“单一”与“可信”是本文需要探讨的两个关键词。我们分这两个维度来说明:

单一

“单一”对应的理论是SSOT,保证我们信息是从一个单一及统一的位置获取。

落地到DevOps中,需要我们的数据资产有统一的源码仓库、制品仓库、文档等管理体系,并且要覆盖研发环境及生产环境,确保软件开发整个生命周期的数据资产管理的连续性。该统一体系需要在组织内共享,并将积累的知识与经验在组织内复用。

可信

“可信”对应的理论是SVOT,确保我们获取的信息是真实可信的,具有权威性的。

落地到DevOps中,需要我们软件、版本在部署到测试或生产环境时都是可信的,其中可信包含两个方面,质量与安 全。

可信质量: 指开发过程中的代码质量、测试通过率、审批结果、合规性、所属人等。

可信安全: 指开发过程中的代码安全风险、外部依赖安全风险、开源许可证合规性风险、开源软件使用风险、动态应用安全风险等。

 

如果企业不建设DevOps体系的单一可信源会导致什么问题呢?

  • 信息孤岛,生产率下降

大研发团队涉及的所有人员没有单一的版本获取位置。对于协同开发的团队,该问题愈发明显,代码及版本存储位置分散,导致获取时间延长,生产率下降

  • 错误频出,代价高昂

大研发团队涉及的所有人员没有没有可信的版本获取位置。尤其是对于运维人员,获取的版本如果不可信,会导致发布故障频出,修复代价高昂。

 

企业建设DevOps体系的单一可信源会有什么收益呢?

  • 统一管理、提高生产率

信息很容易在单一可信源中获取,减少使用成本,避免重复造轮子、浪费生产力

  • 故障修复成本低

质量可信、安全可信。开发过程中可以做到全流程质量及安全监控,保障交付物内建质量高标准。降低沟通成本,减少维护及修复工作量。

 

DevOps中落地“单一可信源”的最佳实践与案例

参考

《CapitalOne – 千亿资产银行如何进行唯一可信源的建设》

《从混乱到有序 –AppsFlyer如何通过唯一可信源改进制品管理》

 

欢迎观看JFrog杰蛙每周二在线课堂,点击报名:

https://www.bagevent.com/event/6643470

如何在Kubernetes上部署MySQL数据库

王延飞阅读(14081)评论(0)

Kubernetes是开发中一项重大的改进,而数据库是应用程序的重要组成部分。在本文中,我们将展示如何在Kubernetes中部署数据库,以及可以使用哪些方法在Kubernetes中部署数据库。

数据库

数据库是一种用于在计算机系统上存储和处理数据的系统。数据库引擎可以在数据库上创建,读取,更新和删除。数据库由数据库管理系统(DBMS)控制。

在大多数数据库中,数据按行和列进行建模,称为关系型,这种类型的数据库在80年代占主导地位。在2000年代,非关系数据库开始流行,被称为No-SQL,它们使用不同的查询语言,并且这些类型的数据库可用于键值对。

StatefulSet

在本文中,我们将在Kubernetes中部署数据库,因此我们必须了解什么是StatefulSet。

StatefulSet是用于管理有状态应用程序的工作负载。它管理一组Pod的实现和扩展,并保证这些Pod的顺序和唯一性。

像Deployment一样,StatefulSet也管理具有相同容器规范的一组Pod。由StatefulSets维护的Pod具有唯一的,持久的身份和稳定的主机名,而不用管它们位于哪个节点上。如果我们想要一个跨存储的持久性,我们可以创建一个持久性卷并将StatefulSet用作解决方案的一部分。即使StatefulSet中的Pod容易发生故障,存储卷与新Pod进行匹配也很容易。

StatefulSet对于需要以下一项或多项功能的应用程序很有价值:

  • 稳定的唯一网络标识符。
  • 稳定,持久的存储。
  • 有序,顺畅的部署和扩展。
  • 有序的自动滚动更新。

在Kubernetes上部署数据库时,我们需要使用StatefulSet,但是使用StatefulSet有一些局限性:

  • 需要使用持久性存储卷为Pod提供存储。
  • 删除副本或按比例缩小副本将不会删除附加到StatefulSet的存储卷。存储卷确保数据的安全性。
  • StatefulSet当前需要Headless Service 来负责Pod的网络标识。
  • 与Deployment 不同,StatefulSet不保证删除StatefulSet资源时删除所有Pod,而Deployment在被删除时会删除与Deployment关联的所有Pod。在删除StatefulSet之前,你必须将pod副本数量缩小到0 。

Kubernetes上的数据库

我们可以将数据库作为有状态应用程序部署到Kubernetes。通常,当我们部署Pod时,它们具有自己的存储空间,但是该存储空间是短暂的-如果容器被杀死了,则其存储空间将随之消失。

因此,我们需要有一个Kubernetes资源对象来解决这种情况:当我们想要数据持久化时,我们就把Pod和持久化存储卷声明关联。通过这种方式,如果我们的容器被杀死了,我们的数据仍将位于集群中,新的pod也能够相应地访问数据。

Pod -> PVC-> PV

  • PV =持久性存储
  • PVC =持久性存储声明

Operators将数据库部署到Kubernetes

  • 我们可以使用由Oracle开发的Kubernetes Operators来部署MySQL数据库:

https://github.com/oracle/mysql-operator

  • 使用Crunchydata开发的PostgreSQL Operators,、将PostgreSQL部署到Kubernetes:

https://github.com/CrunchyData/postgres-operator

  • 使用MongoDB开发的Operators,可将MongoDB Enterprise部署到Kubernetes集群:

https://github.com/mongodb/mongodb-enterprise-kubernetes

在Kubernetes上部署数据库是否可行?

在当今世界上,越来越多的公司致力于容器技术。在进行深入研究之前,让我们回顾一下用于运行数据库的选项。

1.完全托管的数据库

完全托管的数据库是那些不用自己来管理的数据库-这种管理可以由AWS Google,Azure或Digital Cloud等云提供商完成。托管数据库包括Amazon Web Services,Aurora DynamoDB或Google Spanner等。

使用这些完全托管的数据库的优势是操作少,云提供商可以处理许多维护任务,例如备份,扩展补丁等。你只需创建数据库即可构建应用程序,其他的由云提供商帮你处理。

2.在VM或本地自行部署

使用此选项,你可以将数据库部署到任何虚拟机(EC2或Compute Engine),并且将拥有完全控制权。你将能够部署任何版本的数据库,并且可以设置自己的安全性和备份计划。

另一方面,这意味着你将自行管理,修补,扩展或配置数据库。这将增加基础架构的成本,但具有灵活性的优势。

3.在Kubernetes上运行

在Kubernetes中部署数据库更接近full-ops选项,但是从Kubernetes提供的自动化方面来看,你将获得一些好处–能够保持数据库应用程序的正常运行。

要注意,pod是短暂的,因此数据库应用程序重新启动或失败的可能性更大。另外,你将负责更具体的数据库管理任务,例如备份,扩展等。

选择在Kubernetes上部署数据库时要考虑的一些重要点是:

  • 有一些自定义资源和 operators可用于在Kubernetes上管理数据库。
  • 具有缓存层和瞬时态存储的数据库更适合Kubernetes。
  • 你必须了解数据库中可用的复制模式。异步复制模式为数据丢失留有空间,因为事务可能会提交给主数据库,而不会提交给从数据库。

上面,我们用一个简单的图表来显示在Kubernetes上部署数据库时的决策。

首先,我们需要尝试了解数据库是否具有与Kubernetes友好的功能,例如MySQL或PostgreSQL,然后我们查找kubernetes operators将数据库与其他功能打包在一起。

第二个问题是-考虑到在Kubernetes中部署数据库需要多少工作量,这是可以接受的?我们是否有一个运维团队,或者在托管数据库上部署数据库是否可行?

在Kubernetes上部署有状态应用程序:

步骤1:部署MySQL服务

apiVersion: v1
kind: Service
metadata:
  name: mysql
spec:
  ports:
  - port: 3306
  selector:
    app: mysql
  clusterIP: None

首先,我们在端口3306上为MySQL数据库部署服务,所有Pod均具有标签键app: mysql。

接下来,创建以下资源:

Kubectl create -f mysql_service.yaml

步骤2:部署MySQL Deployment

apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
  name: mysql
spec:
  selector:
    matchLabels:
      app: mysql
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - image: mysql:5.6
        name: mysql
        env:
          # Use secret in real usage
        - name: MYSQL_ROOT_PASSWORD
          value: password
        ports:
        - containerPort: 3306
          name: mysql
        volumeMounts:
        - name: mysql-persistent-storage
          mountPath: /var/lib/mysql
      volumes:
      - name: mysql-persistent-storage
        persistentVolumeClaim:
          claimName: mysql-pv-claim

此Deployment在3306端口上创建带有MySQL5.6镜像和密码(使用secret)的Pod。我们还将附加一个持久卷mysql-pv-claim,将在接下来的步骤中进行显示。

创建资源:

Kubectl create -f mysql_deployment.yaml

第3步:创建持久卷

apiVersion: v1
kind: PersistentVolume
metadata:
  name: mysql-pv-volume
  labels:
    type: local
spec:
  storageClassName: manual
  capacity:
    storage: 20Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/data"

这将创建一个持久卷,我们将使用它来附加到容器,以确保Pod重启时的数据安全。该持久卷具有ReadWriteOne访问模式,拥有20GB的存储空间,存放路径是/ mnt/data,我们所有的数据都将保存在该路径中。

创建以下资源:

Kubectl create -f persistence_volume.yaml

第4步:创建持久卷声明

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pv-claim
spec:
  storageClassName: manual
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi

该声明从上面创建的“持久卷”中声明20GB,并具有与上面的“持久卷”相同的访问模式。

创建以下资源:

Kubectl create -f pvClaim.yaml

步骤5:测试MySQL数据库

kubectl run -it --rm --image=mysql:5.6 --restart=Never mysql-client -- mysql -h mysql -ppassword

此命令在运行MySQL的集群中创建一个新的Pod,并连接到MySQL服务器。如果连接成功,则说明你的MySQL数据库已启动并正在运行。

Waiting for pod default/mysql-client-274442439-zyp6i to be running, status is Pending, pod ready: false
If you don't see a command prompt, try pressing enter.

mysql>

以上完整代码存放在这个位置:https://github.com/zarakM/mysql-k8.git

总结

  • 有状态应用程序是存储用户会话状态的应用程序,保存的数据称为应用程序状态。
  • StatefulSet是一个Kubernetes资源对象,用于管理有状态应用程序,并提供有关Pod顺序和唯一性的保证。
  • 通过删除StatefulSet,不会删除StatefulSet中的pod。相反如果删除,你必须将有状态应用程序副本数量缩小为0。
  • Kubernetes上的数据库部署有一个持久存储卷,只要你的集群正在运行,该存储卷就可以永久存储数据。这意味着它可以抵御pod的破坏,并且创建的任何新pod将能够再次使用该存储卷。
  • 完全托管的数据库是由云提供商管理的数据库。我们不必管理数据库。这些数据库需要额外的费用,但是如果你想专注于应用程序,它们是最佳选择。
  • 你可以通过VM部署数据库。但你将必须处理所有数据库操作,例如扩展,设置和修补。
  • 最后,我们展示了如何在Kubernetes上部署数据库。

译文链接: https://www.magalix.com/blog/kubernetes-and-database

阿里云引领云原生进化 | 云原生生态周报 Vol. 60

alicloudnative阅读(3440)评论(0)

60.png

作者 | 王思宇、汪萌海、李鹏

业界要闻

  1. 阿里云引领云原生进化,智能、互联、可信三位一体

阿里巴巴致力于为数字经济构建智能、互联、信任三位一体的创新基础设施,引领云原生进化新阶段。反观阿里云容器服务团队近期在 AI、边缘、机密计算三个领域的开源新动态,与智能、互联、信任的方向一一对应。

  1. Chaos Mesh 项目加入 CNCF sandbox

Chaos Mesh提供针对Kubernetes上复杂系统的故障注入方法,并涵盖了Pod,网络,文件系统甚至内核中的故障。

  1. 阿里云在 KubeCon 2020 峰会上展示什么大杀器?

KubeCon 2020 中国站,阿里云容器服务负责人易立会在《云原生,数字经济技术创新基石》的演讲中,分享阿里云原生如何助力数字技术抗“疫”,阐述阿里云对云原生操作系统的思考,同时详解阿里云 ACK Pro、ASM、ACR EE、ACK@Edge 四款企业级容器新品。

上游重要进展

  1. make cadvisor metrics set configurable in kubelet

Kubelet 支持可配置的 cadvisor metrics set。

  1. Pod resource metrics

为 Pod resource 增加更通用的 metrics 统计。

  1. Add cronjob controller v2

新增 CronJob 控制器 v2 版本。

  1. Do not create StatefulSet pods when PVC is being deleted

StatefulSet 在判断 PVC处于 terminating 状态时不创建 Pod。

  1. 解读 Knative 0.16.0 版本特性

Knative 0.16.0 版本已于近期发布,针对 Knative v0.16.0 版本对这些新功能特性进行解读,让你快速对新版本特性有所深入了解。从 Knative 0.16.0 开始,K8s 最小支持版本为 1.16。

开源项目推荐

  1. Nova

Nova 帮助用户扫描集群已安装的所有 helm chart,然后与所有已知的 Helm 仓库做交叉验证。如果发现了版本可更新、或者当前版本处于 deprecated 状态,会通知用户处理。

  1. K8STARS

K8STARS 是便于将 tars 服务运行在 Kubernetes 中的方案,支持原有 tars 服务平滑迁移到k8s等容器平台。

本周阅读推荐

  1. 《一图看懂阿里云 @KubeCon 2020(含 PPT 下载)》

27 场演讲、37 位专家、780 分钟干货分享,阿里云话题丰富度位列第一。

  1. 《How we migrated Dropbox from Nginx to Envoy》

本文介绍了 Dropbox 是如何从 nginx 迁移到 envoy。

  1. 《Kubernetes RBAC 101: Authentication》

Kubernetes RBAC 认证过程的分析介绍。

  1. 《验证 Kubernetes YAML 的最佳实践和策略》

验证 Kubernetes YAML 的最佳实践和策略,文中比较了六种不同的社区工具对 YAML 的校验和使用方式。

  1. 《Kubernetes 中 Informer 的使用》

Kubernetes 中 Informer 的使用,本文简单介绍了一个基础 informer 的构成和运行方式。

首届云原生微服务大会即将召开

首届 2020 云原生微服务大会将于 8 月 18-19 日在线上召开。本次大会聚焦微服务架构前沿发展和业界最佳实践,重点探讨云原生语境下微服务的挑战和技术趋势,特邀全球微服务领域权威的先行者通过主题演讲、案例分享来深度探讨微服务架构在业界的最佳实践和新机遇,帮助企业技术决策者、架构师、开发者们迎接云原生时代的到来。

点击即可了解详情:https://developer.aliyun.com/topic/microservices2020#/

阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的公众号。”

云原生语境下,如何重新解读微服务?

alicloudnative阅读(6305)评论(0)

头图.png

最近,O’Reilly 公布了一份关于企业微服务市场现状的数据调研。报告显示,在访问了全球 1,502 名软件工程师、系统和技术架构师、工程师以及决策者后,有 77% 的组织反馈采用了微服务,其中 92% 的组织成功使用了微服务。

1.png

如果以这份报告为依据,微服务在企业的普及率已接近八成。看起来,企业对微服务的兴趣可能已经接近顶峰。云原生的基础设施从设计上保证了它是微服务部署的最佳平台,但是也对现有的微服务框架带来了新的挑战,在云原生大行其道的今天:

  • 我们对微服务还应该继续投入精力关注吗?
  • 云原生和微服务之间的关系是什么?
  • 随着 Serviece Mesh 等技术的不断成熟,微服务的体系和思想会产生怎样的演化?
  • Spring Cloud、Dubbo 还会继续作为微服务开发框架的继续流行下去吗?
  • 容器、Kubernetes、ServiceMesh、Serverless 这些云原生时代的主角,会如何助力下一代微服务架构为业务发展赋能?

这些问题值得每一位技术从业人员去思考,并发现由此带来的企业数字化转型升级新挑战、新机遇。也许有同学会说:“上个阶段微服务架构的问题都还没解决,又来了个‘云原生时代的微服务’,我这从哪儿开始学起啊?”

来,从这儿开始!

2.png

2020 云原生微服务大会

为推动云原生下的微服务技术发展和实践交流,由阿里云主办的首届“云原生微服务大会”将于 2020 年 8 月 18-19 日在线上召开。本次大会聚焦微服务架构前沿发展和业界最佳实践,重点探讨云原生语境下微服务的挑战和技术趋势,帮助企业技术决策者、架构师、开发者们迎接云原生时代的到来。

点击活动官网预约大会直播:https://developer.aliyun.com/topic/microservices2020#/

25 位全球专家共同解读云原生语境下的微服务定义

我们一直在强调微服务带来的好处,但另一方面,随着业务规模越来越大,拆分的服务实例越来越多,传统的微服务架构中关于服务之间的交互,服务发现、监控、容错性、日志收集和服务熔断等的处理也越来越困难。今天,以容器、服务网格、微服务、Serverless 为代表的云原生技术,带来一种全新的方式来构建应用,也使这些挑战有了可解的办法。

3.png
2020 云原生微服务大会嘉宾(部分)

8 月 18 日 – 19 日的 2020 云原生微服务大会,我们将特邀微软云首席软件工程师白海石,前Red Hat首席架构师、istio in action 作者、solo.io Field CTO Christian Posta,Spring 布道师 Josh Long,阿里云资深技术专家 & CNCF TOC 李响,南京大学软件工程教授 & 微服务方向专家张贺等 25 位全球微服务领域先行者和权威技术专家,深度探讨微服务架构在云原生时代的发展趋势、业界最佳实践和创新应用案例,一定会让你转变思维,重新审视微服务的思想、核心技术和落地路径。

5 大专场聚焦下一代微服务核心技术和实践

主论坛:08/18 09:00-12:00

云原生语境下,微服务也被赋予了新的意义,支持新的应用范式,承载新的计算价值。主论坛邀请多位技术领袖深度探讨云原生趋势下,微服务技术的实践和演进方向。

微服务开源专场:08/18 14:00-16:30

在微服务架构的落地和演进的过程中,微服务开源项目日益繁荣并不断赋能开发者。本论坛将聚焦微服务领域热门开源技术的落地实践,与开发者探讨微服务架构开源发展及未来趋势。

云原生架构专场:08/18 16:30-19:00

云时代下,企业需要新技术架构,使之更好地利用云计算优势,让业务更敏捷、成本更低、可伸缩性更强,而云原生架构的应用意义正在于此。本论坛将专注探讨云原生架构落地时面临的挑战与解决方案。

前端全栈专场:08/19 14:00-16:30

伴随着云+端、Serverless 等技术的发展,势必给前端带来更大的场景与机会,前端即将进入黄金时代。本专场将邀请行业专家深入探讨前端全栈实践问题及趋势。

超大规模实践专场:08/19 16:30-19:00

当前云原生微服务化落地的场景多样,行业已有很多生产环境下的实战案例,本专场将邀请来自掌门教育、爱奇艺、携程、中国工商银行的行业专家,在云原生微服务视角下探讨超大规模场景下的实践经验。

点击链接:https://developer.aliyun.com/topic/microservices2020#/,登录活动官网 ,即可预约 2020 云原生微服务大会在线直播,查看完整精彩内容,还有更多有奖互动环节等你参与!

阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的公众号。”

阿里云引领云原生进化,智能、互联、可信三位一体

alicloudnative阅读(4702)评论(0)

头图.jpg

云原生技术不但可以最大化云的弹性,帮助企业实现降本提效,而且还有着更多创新的想象空间。云原生将和 AI、边缘计算、机密计算等新技术相结合,进入新的进化阶段,为数字经济构建智能、互联、信任三位一体的创新基础设施。

首届 KubeCon 2020 线上峰会圆满结束,阿里云作为 CNCF 最重要的云原生布道伙伴,此次携 37 位云原生专家与广大开发者分享了 27 场演讲,云原生话题丰富度在本场活动中位居首位。作为峰会的压轴主题演讲,CNCF 理事会成员、阿里云容器服务负责人易立发表演讲《云原生,数字经济技术创新基石》 ,重点介绍了阿里云如何通过开源云原生技术与开放云原生产品,帮助企业提升面向疫情的应变能力,拥抱数字经济发展的新机遇。与此同时,与大家分享了阿里云对云原生技术普惠和云原生操作系统的思考,并详解阿里云 ACK Pro、ASM、ACR EE、ACK@Edge 等四款企业级容器新品。

相关文章推荐:

疫情当前,云原生为数字经济按下快进键

2020 年,疫情突发之后,政府、企业和学校对在线协作的需求猛增。 “上班用钉钉,上学云课堂,出门健康码,订菜送到家”成了我们日常生活的一部分,数字经济发展势头空前高涨。这背后是一系列云计算、云原生技术支撑的业务创新,云原生正在打通数字化落地的“最后一公里”

钉钉扛住了有史以来最大的流量洪峰。春节后第一天复工,钉钉瞬间迎来了远程办公流量高峰:阿里云 2 小时内支撑了钉钉业务 1 万台云主机的扩容需求。基于云服务器和容器化的应用部署方案,让应用发布扩容效率大大提升,为全国用户提供线上工作的流畅体验。

希沃课堂顺利积累超过 30 万教师开设 200 万节课程。面对指数级增长的流量,希沃课堂通过容器服务 ACK 高效管理神龙裸金属服务器和 Serverless 弹性容器实例,整个平台兼具高性能、高弹性、低成本、免维护的优势。整体业务性能提升 30%,运维成本降低 50%,给全国教师和学生提供了更好服务。

支付宝 3 天实现三省精准防控全覆盖。支付宝加速研发全国统一的疫情防控健康信息码,短短 3 天时间,浙江、四川、海南三省陆续实现健康码全覆盖。云原生大数据平台提供了强大的数据统一、汇集和计算能力。基于云原生应用架构的码引擎系统支持了业务需求的快速迭代,具备弹性、韧性和安全的特点,平稳支撑每日亿次调用,成为广大市民日常息息相关的“健康通行证”。

盒马全程保障疫情期间居民日常供应。这背后是盒马整个数字化的供应链体系发挥了重要作用。基于阿里云边缘容器服务 ACK@Edge 底座,盒马团队快速构建了人、货、场数字化全链路融合,云、边、端一体化协同的天眼 AI 系统。结合了云原生技术体系良好的资源调度和应用管理能力,与边缘计算就近访问,实时处理的优势,轻松实现全方位的降本提效,门店计算资源成本节省 50%,新店开服效率提升 70%。

三位一体 阿里云打下数字时代新基建的“底色”

云原生架构与技术一定是开放的,需要全行业共同定义与建设。阿里巴巴作为云原生领域的先行者、实践者,基于自身累积多年的最佳实践,持续对社区赋能,为企业提供普惠的云原生产品服务,与开发者共建云原生生态,帮助更多用户分享时代技术红利。

阿里巴巴致力于为数字经济构建智能、互联、信任三位一体的创新基础设施,引领云原生进化新阶段。反观阿里云容器服务团队近期在 AI、边缘、机密计算三个领域的开源新动态,与智能、互联、信任的方向一一对应。

3.png

1. AI-智能

企业在 IT 转型的大潮中对数字化和智能化的诉求越来越强烈,最突出的需求是如何能快速、精准地从海量业务数据中挖掘出新的商业机会和模式创新,才能更好应对多变、不确定性的业务挑战。

阿里云提供云原生 AI 解决方案从底层异构计算资源,到上层计算框架进行全栈优化。主要特性有统一资源管理、高效共享隔离、统一调度器架构、分布式数据缓存、全生命周期赋能。同时阿里云也将这些成果分享到社区,目前已有来自苹果、IBM、微博等贡献者和我们在开源社区合作共建。

4.jpg

2. 边缘-互联

阿里云发布边缘容器服务 ACK@Edge,短短一年内,已经应用于音视频直播、云游戏、工业互联网、交通物流、城市大脑等应用场景中,并服务于盒马、优酷、阿里视频云和众多互联网、新零售企业。近期,阿里巴巴正式对外宣布将其核心能力开源,并向社区贡献完整的云原生边缘计算项目——OpenYurt。它深度挖掘了“边缘计算+云原生落地实施”诉求。

Kubernetes 有强大的容器编排、资源调度能力,但在边缘 / IoT 场景中,对低功耗、异构资源适配、云边网络协同等方面有独特的需求。OpenYurt 主打“云边一体化”概念,通过对原生 Kubernetes 进行扩展的方式支持边缘计算场景需求。未来,OpenYurt 将采用开源社区开发模式,逐步将产品完整能力开源,并持续推动 K8s 上游社区兼顾边缘计算的需求。

5.jpg

3. 机密计算-信任

随着数字经济的发展,企业的数据资产成为新的石油。大量的数据需要在云端进行交换、处理。如何保障数据的安全、隐私、可信成为了企业上云的最大挑战。我们需要用技术手段,建立数字化信任以保护数据,帮助企业创建可信任的商业合作关系,促进业务增长。

基于 Intel SGX 等加密计算技术,阿里云为云上客户提供了可信的执行环境。但可信应用开发和使用门槛都很高,需要用户对现有应用进行重构,处理大量的底层技术细节,让这项技术落地非常困难。

Inclavare-Containers 是阿里巴巴开源的,业界第一个面向机密计算的容器运行时,只需对传统应用少量修改即可运行在可信执行环境中,极大提高了可信应用的开发、交付效率。目前已经提供了对蚂蚁金服的 Occlum LibOS 支持,此外,得益于和 Intel 的紧密合作,Inclavare-Containers 会在近期支持 Graphene。通过云原生技术普及数字化信任,将帮助企业更加安全、简单地处理、融合、分享数据资产。目前,机密计算容器已经在蚂蚁区块链、钉钉等业务场景中得到应用。

阿里云容器服务连续两年国内唯一进入Gartner《公有云容器服务竞争格局》报告;在Forrester首个企业级公共云容器平台报告中,阿里云容器服务容器服务位列Strong Performer, 中国第一。

此外,阿里云提供了国内最丰富的云原生产品家族,覆盖八大类别 20 余款产品,涵盖底层基础设施、数据智能、分布式应用等,可以满足不同行业场景的需求,帮助企业客户更加简单高效地利用云原生技术。

6.png

十年云原生实践经验,带给阿里巴巴的不止有全球最大规模成功落地的云原生样板间,还有对云原生技术进化趋势的精准把控。智能、互联、信任三位一体的创新基础设施,将成为数字时代新基建的“底色”,阿里巴巴将持续以自身成功经验回馈广大用户,始终以前瞻性视角引领云原生进化,帮助企业找到数字化转型“最短路径”。

除此之外,阿里巴巴近期推出了《云原生架构白皮书》,是国内第一本全方位介绍云原生架构从规划到落地实践的指导书。其中有很多实操性的技术内容和极具借鉴意义的案例参考。希望每一位阅读本书的同学,能够有所收获,成为云原生技术的受益者和创造者。<关注阿里巴巴云原生公众号,回复 白皮书 即可下载本书>

去年,CNCF 与 阿里云联合发布了《云原生技术公开课》已经成为了 Kubernetes 开发者的一门“必修课”。今天,阿里云再次集结多位具有丰富云原生实践经验的技术专家,正式推出《云原生实践公开课》。课程内容由浅入深,专注讲解“ 落地实践”。还为学习者打造了真实、可操作的实验场景,方便验证学习成果,也为之后的实践应用打下坚实基础。课程已经正式上线,欢迎大家观看。点击即可免费观看《云原生实践公开课》

阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的公众号。”