Istio

Istio 1.5 是一个具有重大变革的版本。长久以来，面对社区对 Istio 的性能和易用性的诟病，Istio 团队终于正视自身的问题，在当前版本中彻底推翻了原有控制平面的架构，完成了重建。正如 Simplified Istio 文中所说： 复杂是万恶之源，让我们停止焦虑，爱上单体。 Istio 1.5 回归单体，无论架构和使用方式都发生了巨大变化。因此笔者决定对 1.5 的变化内容做深入解读，以便开发者可以更好的理解和学习新版本，为使用和升级提供参考。 参考： 官方文档， https://istio.io/zh/docs/ 概念 安装 任务 运维 参考 示例 特性介绍， https://www.servicemesher.com/blog/istio-1-5-explanation/ 架构调整 这部分主要分析 Istio 1.5 在架构上的调整，这也是该版本最核心的变化。主要包括重建了控制平面，将原有的多个组件整合为一个单体结构 istiod ；同时废弃了被诟病已久的 Mixer 组件。还对是否向后兼容的部分也做了说明，如果你要从 1.4.x 版本升级到 1.5 必须知道这些变化。 重建控制平面 官方使用的是重建（Restructuring）而不是重构（Refactoring）一词，可见其变化之大。在 Istio 1.5 中，控制平面将使用新的部署模式

目前以Kubernetes为基础构建的容器生态逐渐完善，这其中 Kubernetes、Istio、Knative 三个独立项目被越来越多的人提及，并且已经开始尝试大规模落地实践，它们恰好构成了容器云的未来拼图。今天与大家一起分享下，这三个项目究竟解决了什么问题，为什么它们能够一鸣惊人。 随着微服务理念不断深入人心，越来越多的企业把自己的应用逐步由单体转变成微服务架构，Container容器技术的出现恰恰加速了这个转移过程，因为它有效地解决了N多服务的快速部署问题。但是随着服务数目的增多，越来越多的企业希望能够把相关服务有效地“聚合”在一起，方便统一部署与管理。Kubenretes的出现恰恰解决了大规模微服务编排部署所带来的挑战，让整个行业意识到PaaS的落地可以成为现实。 当随着微服务体系下的服务数目越来越多，服务运维成为必然要解决的问题，于是Istio出现了，基于网络代理与控制相分离的实现策略，允许对服务控制策略进行有效合理的管控。 到这里似乎到了很美好的阶段： 微服务 ：解决应用内聚、臃肿的问题。 Container ：解决服务运行环境统一，和部署问题。 Kubernetes ：解决大量微服务有效“聚合”部署问题。 Istio ：解决服务上线面临的一系列治理问题。 这个阶段乍一看来，构建容器云似乎有了一个完整的链路和解决方式，一切都将变得那么“完美”。

用于Istio中的流量管理的核心组件是 Pilot ，它管理和配置在特定Istio服务网格中部署的所有Envoy代理实例。它允许您指定要用于在Envoy代理之间路由流量的规则，以及配置故障恢复功能（如超时，重试和断路器）。它还维护网格中所有服务的规范模型，并使用它来让Envoys通过其发现服务了解网格中的其他实例。 每个Envoy实例根据从Pilot获取的信息以及对其负载平衡池中其他实例的定期运行状况检查来维护 负载平衡信息 ，从而允许它在遵循其指定的路由规则的同时智能地在目标实例之间分配流量。 交通管理的好处 使用Istio的流量管理模型实质上解耦了流量和基础架构扩展，让运营商通过Pilot指定他们希望流量遵循的规则，而不是哪些特定的pod / VM应该接收流量 - 飞行员和智能Envoy代理负责其余的工作。因此，例如，您可以通过Pilot指定您希望特定服务的5％流量转到金丝雀版本，而不管金丝雀部署的大小，或根据请求的内容将流量发送到特定版本。 用Istio进行交通管理 将流量从这样的基础设施扩展中分离，允许Istio提供存在于应用程序代码之外的各种流量管理功能。除了用于A / B测试，逐步推出和金丝雀版本的动态 请求路由之外 ，它还使用超时，重试和断路器处理 故障恢复 ，最后使用 故障注入 来测试跨服务的故障恢复策略的兼容性。这些功能都是通过服务网格上部署的Envoy

“它由Product backlog开始，经过sprint会议从Prdouct backlog挑选出一些优先级最高的故事（story）形成迭代的sprint backlog（一个sprint一般为1个月）。在sprint中会进行每日站会，迭代结束时会进行演示和回顾会议。” 了解敏捷的朋友都知道backlog和spring是待办事项和冲刺的意思，但在使用Choerodon实践敏捷开发的时候这些敏捷术语对应的系统功能是哪些呢？为了解决大家在使用Choerodon时的困扰，整理了以下Choerodon功能与敏捷术语的对应表，以便大家进一步了解Choerodon的具体功能。 功能 敏捷术语 说明 问题 史诗(Epic) 非常大型的故事，可以横跨多个迭代周期。史诗故事在战术层面上使用前必须分解为一个个相关的用户故事。 故事（Story） 用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：1. 角色：谁要使用这个功能。2. 活动：需要完成什么样的功能。3. 商业价值：为什么需要这个功能，这个功能带来什么样的价值。 任务（Task） 是完成需求的过程性的工作。在迭代计划会议中，将纳入迭代的Story指派给具体成员，并分解成一个或多个Task，填写“预计工时”。 子任务 子任务通常是故事的具体拆分，拆分出的子任务将交给具体的开发、业务等人员处理，属于具体的任务交付

网关（Gateway），简单地说就是请求的入口。如果你接触过微服务，应该经常听到“网关”这个词。 虽然 API 网关并不是微服务所独有的，但它的流行是在微服务兴起之后才开始的。那么到底什么是 API 网关呢？ 基本概念 API 网关是位于客户端和它所依赖的服务之间的一层。有时称为“反向代理”，它们充当从客户端到其服务的单一入口点。 API 网关就像一座大楼的服务台：转接电话，访客登记，快递收发等。 如果你曾经用过第三方 API，你可能就是在跟网关通信，而网关又与服务的内部API 通信。 网关的好处后面会讨论，主要是让服务提供方向外部公开 API 的一部分，并集中处理版本管理、安全、本地化等工作。 API 网关最常见的用途是请求路由。大致过程如下： 客户端向网关发起请求 网关处理这些请求并转发到相关服务 服务向网关发送响应 网关处理响应并发送到客户端 这里的 客户端 可以是各种身份。上面流程提到的原始实现中，客户端是 API 的消费者，但是 API 网关也可以向客户端暴露内部 API。对许多 web 应用来说，客户端就是单页应用（SPA），但也可以是web应用的后端服务器、手机原生应用，甚至是智能电视、媒体播放器和 IoT 设备等。 服务 通常是你的应用控制的内部服务，比如数据库或微服务。网关也可以位于客户端和第三方 API 之间。这样你的用户就可以用统一的方式访问第三方数据了。

在刚刚过去的 2019 年里，阿里巴巴云原生公众号共发布了 270 篇文章，累计阅读 40 多万，文章内容涵盖阿里云原生实践、云原生生态新闻到 K8s 入门等。 这个春节假期，我们整理了三个最受欢迎的文章榜单， 包含系列文章、爆款文章和事件文章三类。 <a name="2MH8H"></a> 最受欢迎系列文章 Top 2 <a name="0ApGL"></a> 《Go 开发关键技术指南系列》 本系列文章从问题本身出发，不局限于 Go 语言，探讨服务器中常常遇到的问题，最后回到 Go 如何解决这些问题，为大家提供 Go 开发的关键技术指南。 本系列共有 4 篇： 为什么你要选择 Go？ (内含超全知识大图） Go 面向失败编程 带着服务器编程金刚经走进 2020 年 敢问路在何方？ <a name="x97ws"></a> 《从零开始入门 K8s》 由阿里云与 CNCF 共同开发的《CNCF x Alibaba 云原生技术公开课》（视频课程）第一期已更新完毕。为了让大家有更好的学习体验，我们把视频课程转为图文，并请讲师重新编辑成文章，在阿里巴巴云原生公众号以“从零入门 K8s” 为系列进行每周连载。本系列已发布图文版课程文章 21 篇，期待给正在学习 Kubernetes 的同学提供一些参考。 关注“阿里巴巴云原生”公众号，回复关键词“入门”，即可下载《CNCF x Alibaba

背景 有 外文 指出，2020 年 Service Mesh 技术将有以下三大发展： 快速增长的服务网格需求； Istio 很难被打败，很可能成为服务网格技术的事实标准； 出现更多的服务网格用例，WebAssembly 将带来新的可能。 针对 Service Mesh 技术，ServiceMesher 社区治理委员会成员在 2020 新年伊始发表了他们各自的看法，并邀请云原生与服务网格领域业界大牛抒发各自的见解，汇总成文，希望能给读者们带来一些思考和启发。 正文 宋净超（蚂蚁金服） 用一句话概括 Service Mesh 近几年的发展——道阻且长，行则将至。这几年来我一直在探寻云原生之道，从容器、Kubernetes 再到 Service Mesh，从底层的基础设施到越来越趋向于业务层面，Service Mesh 肯定不是云原生的终极形式，其复杂性依然很高，且业界标准也尚未形成，它的发展也远没有同期的 Kubernetes 那么顺利，但是很多人都已意识到了服务网格价值，现在它正在远离最初市场宣传时的喧嚣，走向真正的落地。 罗广明（百度） 据了解，2020 年的 Kubecon EU 的提案中，很少有涉及服务网格落地场景，由此来看，服务网格技术离大规模生产落地还有很远的路要走。当前 Istio 架构体现出来的性能问题迟迟没有得到优化，使用原生的 Istio 大规模上生产还不太靠谱

作者 | 徐迪、陈俊、敖小剑、宋进超 业界要闻 Apache Flink 1.10.0 发布 作为 Flink 社区迄今为止规模最大的一次版本升级，Flink 1.10 容纳了超过 200 位贡献者对超过 1200 个 issue 的开发实现，包含对 Flink 作业的整体性能及稳定性的显著优化、对原生 Kubernetes 的初步集成（beta 版本）以及对 Python 支持（PyFlink）的重大优化。 Linkerd 2.7 发布 此版本以安全为主题，主要更新亮点包括增加了将 Linkerd 的交叉 TLS 基础与外部证书发行商（如 Vault、cert-manager）集成的支持，改进了 GitOps 工作流，并使其易于自动轮换 TLS 凭据；还改进了 dashboard 的性能，提高了 Helm 图表的可用性。 上游重要进展 Kubernets 1.18 分支本周二正式创建了，code freeze 在 3 月 5 号； graduate PodTopologySpread to beta feature gate PodTopologySpread 升级到 beta 版本。 Provide OIDC discovery for service account token issuer 引入了新的 token issuer，符合 OIDC(OpenID Connect)

简介：为了共同抵抗疫情，众多企事业单位开始 SOHO 办公（也叫线上办公），以有效降低人员接触导致的交叉感染风险，这是互联网时代给予疫情防御战线的一份礼物。与此同时，这类新型的办公方式也给企事业单位的数据安全保护带来了更多挑战，阿里云数据安全专家建议从五个方面着手，提升企业数据安全保护能力，并提供免费咨询服务。 病毒肆掠，疫情严峻。为了共同抵抗疫情，众多企事业单位开始 SOHO 办公（也叫线上办公），员工尽量在家远程办公，通过钉钉、手机和邮箱等方式完成业务沟通，以有效降低人员接触导致的交叉感染风险，这是互联网时代给予疫情防御战线的一份礼物。 与此同时，这类新型的办公方式也给企事业单位的数据安全保护带来了更多挑战，主要体现在以下几个方面： 需要将部分前期仅在内网可访问的数据权限开放到互联网； 员工使用缺乏安全管控的家庭终端接入到公司内部系统中（特别是日常使用固定终端的办公人员）； 数据访问源分布广泛（白名单访问控制方式极易失效）； 截屏、拍照、录像等数据窃取方式缺乏监管。 <a name="aJRIF"></a> 云上企业如何在 SOHO 办公场景下有效实现敏感数据的保护呢？ 阿里云数据安全专家建议从以下五个方面着手，提升企业数据安全保护能力： <a name="fSfLt"></a> 01 控制接入 SOHO 办公方式无可避免的需要将前期仅在内网可访问的数据权限开放到互联网