Knative

提到天气预报服务，我们第一反应是很简单的一个服务啊，目前网上有大把的天气预报 API 可以直接使用，有必要去使用 Knative 搞一套吗？杀鸡用牛刀？先不要着急，我们先看一下实际的几个场景需求： 场景需求1：根据当地历年的天气信息，预测明年大致的高温到来的时间 场景需求2：近来天气多变，如果明天下雨，能否在早上上班前，给我一个带伞提醒通知 场景需求3：领导发话：最近经济不景气，公司财务紧张，那个服务器，你们提供天气、路况等服务的那几个小程序一起用吧，但要保证正常提供服务。 从上面的需求，我们其实发现，要做好一个天气预报的服务，也面临内忧（资源紧缺）外患（需求增加），并不是那么简单的。不过现在更不要着急，我们可以使用 Knative 帮你解决上面的问题。 关键词 ：天气查询、表格存储，通道服务，事件通知 场景需求 首先我们来描述一下我们要做的天气服务场景需求： 1. 提供对外的天气预报 RESTful API 根据城市、日期查询（支持未来 3 天）国内城市天气信息 不限制查询次数，支持较大并发查询（1000） 2. 天气订阅提醒 订阅国内城市天气信息，根据实际订阅城市区域，提醒明天下雨带伞 使用钉钉进行通知 整体架构 有了需求，那我们就开始如何基于 Knative 实现天气服务。我们先看一下整体架构： 通过 CronJob 事件源，每隔 3个 小时定时发送定时事件

提到天气预报服务，我们第一反应是很简单的一个服务啊，目前网上有大把的天气预报 API 可以直接使用，有必要去使用 Knative 搞一套吗？杀鸡用牛刀？先不要着急，我们先看一下实际的几个场景需求： 场景需求1：根据当地历年的天气信息，预测明年大致的高温到来的时间 场景需求2：近来天气多变，如果明天下雨，能否在早上上班前，给我一个带伞提醒通知 场景需求3：领导发话：最近经济不景气，公司财务紧张，那个服务器，你们提供天气、路况等服务的那几个小程序一起用吧，但要保证正常提供服务。 从上面的需求，我们其实发现，要做好一个天气预报的服务，也面临内忧（资源紧缺）外患（需求增加），并不是那么简单的。不过现在更不要着急，我们可以使用 Knative 帮你解决上面的问题。 关键词 ：天气查询、表格存储，通道服务，事件通知 场景需求 首先我们来描述一下我们要做的天气服务场景需求： 1. 提供对外的天气预报 RESTful API 根据城市、日期查询（支持未来 3 天）国内城市天气信息 不限制查询次数，支持较大并发查询（1000） 2. 天气订阅提醒 订阅国内城市天气信息，根据实际订阅城市区域，提醒明天下雨带伞 使用钉钉进行通知 整体架构 有了需求，那我们就开始如何基于 Knative 实现天气服务。我们先看一下整体架构： 通过 CronJob 事件源，每隔 3个 小时定时发送定时事件

作者| 阿里云智能事业群技术专家牛秋霖（冬岛） 导读 ：从头开发一个Serverless引擎并不是一件容易的事情，今天咱们就从Knative的健康检查说起。通过健康检查这一个点来看看Serverless模式和传统的模式都有哪些不同，以及Knative针对Serverless场景都做了什么思考。 Knative Serving 模块的核心原理如下图所示，图中的 Route 可以理解成是 Istio Gateway 的角色。 当缩容到零时进来的流量就会指到 Activator 上面； 当 Pod 数不为零时流量就会指到对应的 Pod 上面，此时流量不经过 Activator； 其中 Autoscaler 模块根据请求的 Metrics 信息实时动态的扩缩容。 Knative 的 Pod 是由两个 Container 组成的：Queue-Proxy 和业务容器 user-container。架构如下： 咱们以 http1 为例进行说明：业务流量首先进入 Istio Gateway，然后会转发到 Queue-Proxy 的 8012 端口，Queue-Proxy 8012 再把请求转发到 user-container 的监听端口，至此一个业务请求的服务就算完成了。 粗略的介绍原理基本就是上面这样，现在咱们对几个细节进行深入的剖析看看其内部机制： 为什么要引入 Queue-Proxy？

作者 | 元毅 阿里云智能事业群高级开发工程师 在 Istio 中提供了一个 Bookinfo 的示例，用于演示微服务之间的调用，那么如何在 Knative 中部署这个示例呢？本文将会给大家介绍一下在 Knative 中部署 Bookinfo 微服务以及查看调用链追踪信息。 背景 Bookinfo 这个示例应用由 4 个微服务组成。 Bookinfo 应用架构图如下： productpage 微服务: 调用 details 微服务和 reviews 微服务来生成页面 details 微服务: 包含图书的详细信息 reviews 微服务: 提供图书的评论功能，也可以调用 rating 微服务给图书评分 ratings 微服务: 提供图书的评分功能 另外 reviews 微服务目前有 3 个版本: v1 不会调用 ratings 微服务 v2 调用 ratings 微服务，并将评分显示 1~5 个黑色星星 v3 调用 ratings 微服务，并将每个评分显示为 1~5 个红色星星 准备 已部署 Knative。可参考： 阿里云容器服务部署 Knative 已开启链路追踪 Tracing Analysis服务，可参考： 在Knative 上实现 Tracing 分布式追踪 部署 首先开启 Istio Sidecar 注入，我们在 default 命名空间打上 istio

作者 | 汤志敏 阿里云容器服务开发负责人 Kubernetes 是云原生时代的基础设施、云上的分布式操作系统。 9 月 26 日云栖大会容器专场，在《拐点已至，云原生引领数字化转型升级》的演讲中，容器服务开发负责人汤志敏表示：“阿里云容器服务已经拥有国内最大规模的公共云容器集群，据各大国际评测机构显示，其市场份额和产品综合能力中国内第一。 本次容器服务 ACK2.0 在规模、性能和弹性能力上全面升级，支持单集群万节点、90% 原生性能的安全沙箱容器、分钟级千节点弹性。此外，容器服务已经在全球 20 个地域部署，推出云原生混合云 2.0 架构和 ACK @Edge ，打造安全智能的无边界云计算。 本文根据演讲内容整理，关注阿里巴巴云原生公众号，回复“ 云原生 ”获得本文 PPT。 K8s，云原生时代的重要生产力 在早期，K8s 上跑的应用多是无状态的应用，而现在越来越多的企业核心业务、数据智能业务和创新业务也跑在 K8s 之上。以阿里云自身的云产品举例，包括企业级分布式应用服务 EDAS、微服务引擎 MSE、智能数据管理平台 Dataphin、数据湖分析 Data Lake Analytics 也部署在容器服务 ACK 之上。 如今，阿里云实时计算产品也推出了云原生实时计算 Flink 版本，让 Flink 可以部署在用户的 K8s 集群之上，让在线业务和流计算共享一个 K8s

提到天气预报服务，我们第一反应是很简单的一个服务啊，目前网上有大把的天气预报 API 可以直接使用，有必要去使用 Knative 搞一套吗？杀鸡用牛刀？先不要着急，我们先看一下实际的几个场景需求： 场景需求 1：根据当地历年的天气信息，预测明年大致的高温到来的时间 场景需求 2：近来天气多变，如果明天下雨，能否在早上上班前，给我一个带伞提醒通知 场景需求 3：领导发话“最近经济不景气，公司财务紧张，那个服务器，你们提供天气、路况等服务的那几个小程序一起用吧，但要保证正常提供服务”。 从上面的需求，我们其实发现，要做好一个天气预报的服务，也面临内忧（资源紧缺）外患（需求增加），并不是那么简单的。不过现在更不要着急，我们可以使用 Knative 帮你解决上面的问题。 关键词 ：天气查询、表格存储，通道服务，事件通知 场景需求 首先我们来描述一下我们要做的天气服务场景需求： 1. 提供对外的天气预报 RESTful API 根据城市、日期查询（支持未来 3 天）国内城市天气信息 不限制查询次数，支持较大并发查询（1000） 2. 天气提醒 订阅国内城市天气信息，根据实际订阅城市区域，提醒明天下雨带伞 使用钉钉进行通知 整体架构 有了需求，那我们就开始如何基于 Knative 实现天气服务。我们先看一下整体架构： 通过 CronJob 事件源，每隔 3 个小时定时发送定时事件

作者 | 汤志敏 阿里云容器服务开发负责人 Kubernetes 是云原生时代的基础设施、云上的分布式操作系统。 9 月 26 日云栖大会容器专场，在《拐点已至，云原生引领数字化转型升级》的演讲中，容器服务开发负责人汤志敏表示：“阿里云容器服务已经拥有国内最大规模的公共云容器集群，据各大国际评测机构显示，其市场份额和产品综合能力中国内第一。 本次容器服务 ACK2.0 在规模、性能和弹性能力上全面升级，支持单集群万节点、90% 原生性能的安全沙箱容器、分钟级千节点弹性。此外，容器服务已经在全球 20 个地域部署，推出云原生混合云 2.0 架构和 ACK @Edge ，打造安全智能的无边界云计算。 本文根据演讲内容整理，关注阿里巴巴云原生公众号，回复“ 云原生 ”获得本文 PPT。 K8s，云原生时代的重要生产力 在早期，K8s 上跑的应用多是无状态的应用，而现在越来越多的企业核心业务、数据智能业务和创新业务也跑在 K8s 之上。以阿里云自身的云产品举例，包括企业级分布式应用服务 EDAS、微服务引擎 MSE、智能数据管理平台 Dataphin、数据湖分析 Data Lake Analytics 也部署在容器服务 ACK 之上。 如今，阿里云实时计算产品也推出了云原生实时计算 Flink 版本，让 Flink 可以部署在用户的 K8s 集群之上，让在线业务和流计算共享一个 K8s

前言 Knative Eventing v0.9 版本已经于 9 月 18 号正式发布。本次发布 Eventing 中相关功能更新并不多。本篇文章带你简单了解这些功能新特性。 新特性 Broker/Trigger 优化 Broker 中的 Ingress Pod 以及 Filter Pod新增 liveness 和 readiness 配置：在之前未配置 liveness 和 readiness 的情况下，如果里面的 HTTP 服务挂掉下， Pod仍然还在运行中，需要手动删除Pod才能重新恢复服务，这样既需要人工介入又不能第一时间恢复服务。通过新增 liveness 和 readiness 配置，能很好的解决这类问题。 Broker Pod 支持向 config-observability ConfigMap 配置的后端发送 metrics 指标 Broker 以及 InMemoryChannel 订阅的请求超时时间从1分钟调整到15分钟。针对有些大的镜像服务冷启动时间比较长的情况下，1分钟的超时时间明显不合适，所以再新版本在将这个超时时间调整到15分钟。（个人认为该超时时间设计成可配置的更好） ApiServerSource 优化 过滤增强：支持通过label标签、apiVersion 和 kind 进行事件过滤。 支持事件数量统计功能。 CronJobSource 优化

短网址顾名思义就是使用比较短的网址代替很长的网址。维基百科上面的解释是这样的： 短网址又称网址缩短、缩短网址、URL 缩短等，指的是一种互联网上的技术与服务，此服务可以提供一个非常短小的 URL 以代替原来的可能较长的URL，将长的 URL 位址缩短。用户访问缩短后的 URL 时通常将会重定向到原来的长 URL <a name="f19742d4"></a> 起源 虽然现在互联网已经非常发达了，但还是有很多场景会对用户输入的内容有长度限制。比如 ： 微薄、Twitter 长度不能超过 140 个字 一些早期的 BBS 文章单行的长度不能超过 78 字符等场景 运营商短信的长度不能超过 70 个字 而现在很多媒体、电商平台的内容大多都是多人协作通过比较复杂的系统、框架生成的，链接长度几十个甚至上百字符都是很平常的事情，所以如果在上述的几个场景中传播链接使用短网址服务就是一个必然的结果。比如下面这些短信截图你应该不会陌生：<br /> <a name="3dbf0c11"></a> 应用场景 短网址服务的最初本意就是缩短长 url，方便传播。但其实短网址服务还能做很多其他的事情。比如下面这些： 访问次数的限制，比如只能访问 1 次，第二次访问的时候就拒绝服务 时间的限制，比如只能在一周内提供访问服务，超过一周就拒绝服务 根据访问者的地域的限制 通过密码访问 访问量统计

作者：心贵、进超、元毅、心水、衷源、洗兵 业界要闻 Kubernetes v1.16 发布 在这次发布中值得关注的一些特性和 Feature: CRD 正式进入 GA 阶段； Admission Webhook 正式进入 GA 阶段； CSI 和 Volume 的一系列增强和修复。 蚂蚁金服开源 ElasticDL 项目 9 月 11 日，蚂蚁金服在 2019 谷歌开发者大会上海站上开源了 ElasticDL 项目，这是业界首个基于 TensorFlow 实现弹性深度学习的开源系统。ElasticDL 实现了容错和弹性调度的分布式深度学习，可以极大提升集群的总体利用率，同时显著减少用户提交作业之后等待作业启动的时间（pending time）。 Oracle 宣布永久免费一部分云计算服务 Oracle CEO Larry Ellison 在 OpenWorld 大会上宣布推出了 Oracle Cloud Free Tier ，大小型公司和组织、开发人员、学生和教育工作者都可以构建、学习和探索 Oracle 自治数据库和 Oracle 云基础架构的全部功能。 这次推出的 Oracle Cloud Free Tier（免费套餐计划）共有两个组成部分，分别是免费试用计划和永久性免费云服务。 上游重要进展 Kubernetes 项目 修复 API Server 访问 Webhook