Istio

最近在了解service mesh相关，从而了解到了Istio。简述一下这两个概念，接下来有时间会继续整理相关技术文档分享。 首先，什么是Service Mesh？ Service Mesh，服务网格，在现在微服务流行的趋势下， 服务越来越多，用 术语服务网格来描述组成此类应用程序的微服务网络及其之间的交互的情况再形象不过。随着服务网格的大小和复杂性的增长，它变得越来越难以理解和管理。它的要求可以包括发现，负载平衡，故障恢复，指标和监视。服务网格通常还具有更复杂的操作要求，例如A / B测试，速率限制，访问控制和端到端身份验证等。 什么是Istio？ Istio， 一个开源 服务网格 平台，它可以控制 微服务 之间数据的共享方式。其附带的 API 可以将 Istio 集成 到任何日志记录平台、遥测或策略系统中。在设计上，Istio 可以在多种环境中运行：企业本地、云托管、 Kubernetes 容器 ，或 虚拟机 上运行的服务等。 Istio 的架构分为数据平面和控制平面两部分。在数据平面中，通过在环境中部署 sidecar 代理，即可为服务添加 Istio 支持。该 sidecar 代理与微服务并存，用于将请求路由给其他代理，或从其他代理那路由请求。这些代理共同构成了一个网格网络，可拦截微服务之间的网络通信。控制平面则负责管理和配置代理来路由流量。此外，控制平面还可配置组件

Istio 组件常用端口 端口 协议 使用者 描述 8060 HTTP Citadel GRPC 服务器 8080 HTTP Citadel agent SDS service 监控 9090 HTTP Prometheus Prometheus 9091 HTTP Mixer 策略/遥测 9876 HTTP Citadel, Citadel agent ControlZ 用户界面 9901 GRPC Galley 网格配置协议 15000 TCP Envoy Envoy 管理端口 (commands/diagnostics) 15001 TCP Envoy Envoy 传出 15006 TCP Envoy Envoy 传入 15004 HTTP Mixer, Pilot 策略/遥测 - mTLS 15010 HTTP Pilot Pilot service - XDS pilot - 发现 15011 TCP Pilot Pilot service - mTLS - Proxy - 发现 15014 HTTP Citadel, Citadel agent, Galley, Mixer, Pilot, Sidecar Injector 控制平面监控 15020 HTTP Ingress Gateway Pilot 健康检查 15029 HTTP Kiali Kiali 用户界面

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 阿里妹导读：随着容器技术的快速发展和广泛应用，毫无疑问云原生技术是未来发展的必然趋势。作为国内最早布局容器技术的阿里云，无论在技术还是产品上，都取得了极大的成果。阿里云资深技术专家易立通过阿里云容器服务，分享容器技术落地的最佳实践，希望能够帮助同学们更好地理解容器技术和云原生理念，合理地设计上云架构，充分发挥云的价值。 没有集装箱，就没有全球化。——《经济学人》 什么是容器？ 容器的英语是 Container，它的意思是集装箱。我们知道，经济全球化的基础就是现代运输体系，而其核心正是集装箱。集装箱的出现实现了物流运输的标准化，自动化，大大降低了运输的成本，使得整合全球的供应链变为可能。这就是著名经济学人谈到的“没有集装箱，就没有全球化”。 集装箱背后的标准化、模块化的理念也在推进建筑业的供应链变革。在最近，疫情爆发之后。10 天 10 夜，在武汉火神山，一个可以容纳上千床位的专科医院平地而起，在抗疫过程中发挥的重要作用。整个医院都是采用集装箱板房吊装。模块化的病房设计，预置了空调、消杀、上下水等设施，极大加速了施工速度。 容器的通俗理解 软件集装箱 ”容器技术“ 也在重塑整个软件供应链。容器作为一种轻量化的操作系统虚拟化技术，和和传统的物理机、虚拟化技术和使用方式有什么不同呢

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 在过去几年中，微服务成为了业界技术热点，大量的互联网公司都在使用微服务架构，也有很多传统企业开始实践互联网技术转型，基本上也是以微服务和容器为核心。本文将主要介绍微服务架构的概述以及云原生环境下的 Service Mesh 和传统微服务应用的区别。 微服务架构概述 微服务架构可谓是当前软件开发领域的技术热点，在各种博客、社交媒体和会议演讲上的出镜率非常之高，无论是做基础架构还是做业务系统的工程师，对微服务都相当关注，而这个现象与热度到目前为止，已经持续了近 5 年之久。 尤其是近些年来，微服务架构逐渐发展成熟，从最初的星星之火到现在的大规模落地与实践，几乎已经成为分布式环境下的首选架构。微服务成为时下技术热点，大量互联网公司都在做微服务架构的落地和推广。同时，也有很多传统企业基于微服务和容器，在做互联网技术转型。 而在这个技术转型中，国内有一个趋势，以 Spring Cloud 与 Dubbo 为代表的微服务开发框架非常普及和受欢迎。然而软件开发没有银弹，基于这些传统微服务框架构建的应用系统在享受其优势的同时，痛点也越加明显。这些痛点包括但不限于以下几点： 侵入性强。 想要集成 SDK 的能力，除了需要添加相关依赖，往往还需要在业务代码中增加一部分的代码、或注解、或配置

作者 | 张羽辰（同昭）阿里云交付专家 导读 ：如今，几乎所有的事情都离不开软件，当你开车时，脚踩上油门，实际上是车载计算机通过力度感应等计算输出功率，最终来控制油门，你从未想过这会是某个工程师的代码。 当我们谈论架构时，我们到底在谈论什么？ 面向对象编程？函数式？模块化设计？微服务？这些词汇貌似都和架构这个 buzzword 有点关系，的确我们这个领域充满了很多难以理解的词汇，这些词汇从英语翻译到中文已经丧失了部分上下文，再随着上下文的改变使得意义彻底扭曲，比如：引擎、框架、架构、应用、系统……诚然大家都或多或少对这些词语达成共识，在工作中使用这些词汇进行沟通，某时就是指“我们都懂的那个东西”，但是在我深入的想聊聊架构或者说软件架构时，的确不得不问自己这个问题，我们到底是谈论什么？ 事实上，架构这个词根据上下文所确定的范围较为固定，建筑学上的架构指代房屋结构、整体设计、组合构成等，而这些 high-level 设计往往并不需要全面了解底层，就像使用 RestTemplate 进行 WebService 调用时，我们也不关心 socket 是在四层连接的一样， 因为细节被隐藏了 。 但是，建筑学上的架构与软件架构却又极大的不同之处，问题出现在“软件”这个词上，按照 software 的词解，ware 是指产品一样的东西，而 soft 则强调易变，这是与 hardware 所对应的

一分钟速览资讯 ☁ 云计算报告 ① CNCF 2019 年度调查重磅报告发布 <推荐> ☁ 业界新闻 ② GitHub 宣布正式收购 npm ③ 受疫情影响，一系列 IT 活动已经取消和推迟 ☁ 程序员专区 ④ Kubernetes1.18 版本发 布 <推荐> ⑤ Spring Boot 2.3.0.M1发布 ⑥ Istio 1.5 正式 发布 云计算报告 01 CNCF 2019 年度调查报告发布，84%受访者已经在应用容器 报告中包含了几条重要信息： Cloud Native 社区项目在生产环境中应用成为新常态，超过 50% 的 Cloud Native 项目在生产中应用； Service Mesh 真正进入生产实践，超过 18% 的受访者表示已经在生产环境中使用 Service Mesh； Serverless 技术正逐渐成为主流，超过 40% 的受访者表示在使用 Serverless 技术； 容器在生产环境中的使用显著提升，相比于 2018 年的 73% 上升到了 84%； 越来越多的应用开始通过 CI/CD 工具自动发布。 报告pdf下载↓↓ 业界新闻 02 GitHub 宣布正式收购 npm npm 自十年前发布以来，经过发展目前已经是最流行的 javascript 包管理工具。 收购以后，Github 承诺会对 npm 的安全性、注册表基础架构提供增强； 在商业上

近日 Google 转移 Istio 等重要开源项目商标所有权的事件持续发酵。IBM、Oracle、CNCF 、Tetrate 等相关生态参与者下场开撕，公开指责 Google 违背了开源社区开放治理的原则。 多方质疑 即使你不关注 Istio 或者云原生，本周你可能也听到了一些关于 Google 与 IBM 开撕的消息。 简而言之，原本由 Google 公司持有的 Istio 商标，现在将被一个由 Google、SADA、独立开源维护者和计算机科学学者创建的全新中立机构 Open Usage Commons （OUC）持有。 其目的是减轻许多人对谷歌拥有商标所有权的项目未来的担忧。但目前的问题是，IBM、Oracle 等同行认为， 该组织从资金来源、管理层结构来看，完全由 Google 一家掌握。 也就是说，所谓的商标转移实际上是 Google 自己左手倒右手，借助所谓的 “中立组织” 免去道义层面的指责，反而加强了自己对这些项目的控制。 其中最大的抗议声来自蓝色巨人 IBM。IBM 方面表示，Istio 项目是 Google 的 Istio 和 IBM 的 Amalgam8 项目的合并，IBM 对 Istio 项目的建设投入了大量的资源。 双方曾达成协议，在项目成熟后会贡献给 CNCF ，而 Google 违反了这一协议 。 IBM 云平台副总裁兼首席技术官 Jason R

作者 | 张羽辰（同昭）阿里云交付专家 导读 ：如今，几乎所有的事情都离不开软件，当你开车时，脚踩上油门，实际上是车载计算机通过力度感应等计算输出功率，最终来控制油门，你从未想过这会是某个工程师的代码。 当我们谈论架构时，我们到底在谈论什么？ 面向对象编程？函数式？模块化设计？微服务？这些词汇貌似都和架构这个 buzzword 有点关系，的确我们这个领域充满了很多难以理解的词汇，这些词汇从英语翻译到中文已经丧失了部分上下文，再随着上下文的改变使得意义彻底扭曲，比如：引擎、框架、架构、应用、系统……诚然大家都或多或少对这些词语达成共识，在工作中使用这些词汇进行沟通，某时就是指“我们都懂的那个东西”，但是在我深入的想聊聊架构或者说软件架构时，的确不得不问自己这个问题，我们到底是谈论什么？ 事实上，架构这个词根据上下文所确定的范围较为固定，建筑学上的架构指代房屋结构、整体设计、组合构成等，而这些 high-level 设计往往并不需要全面了解底层，就像使用 RestTemplate 进行 WebService 调用时，我们也不关心 socket 是在四层连接的一样， 因为细节被隐藏了 。 但是，建筑学上的架构与软件架构却又极大的不同之处，问题出现在“软件”这个词上，按照 software 的词解，ware 是指产品一样的东西，而 soft 则强调易变，这是与 hardware 所对应的

本文整理自 ServerlessDay · China 大会 - 《从零到一，Serverless 平台在滴滴内部落地》分享，讲师滴滴弹性云平台负责人张健、滴滴资深前端开发工程师陈钦辉。滴滴 Serverless FT成员来自：滴滴基础平台部、车服技术部、金融事业部、普惠产品技术部。 为什么（前端）要推动建设 Serverless 更快地创建一个服务且免运维：大量的 Node.js 服务，创建服务，需要申请节点、申请机器，对接构建、部署、日志、监控，还要持续运维服。我们希望能更快创建一个服务并且免运维。 更灵活的隔离能力：前端 BFF 接口聚合、微前端等业务场景，需要创建大量的接口服务，快速创建服务的同时，还希望可以以不同粒度灵活进行接口间的隔离。 更低的成本：大量低峰期时间cpu/内存利用率很低，服务不再使用了，资源却仍然占用。 我们的方案 我们调研了业界的 Serverless 方案，最终决定了自己的方案： K8s + Knative + Istio 搭建应用级 Serverless。他的优势是： 社区相对繁荣，未来充满希望。 应用级 Serverless, 和传统通过 Docker 镜像开发，部署相近，现有服务迁移成本低。 应用级 Serverless, 通过 Serverless。 路由，可以灵活控制隔离的粒度。 通过 Serverless 升级研发模式 那有了