mesh

简介： 由阿里云主办的首届“云原生微服务大会”将于 2020 年 8 月 18-19 日在线上召开。本次大会聚焦微服务架构前沿发展和业界最佳实践，重点探讨云原生语境下微服务的挑战和技术趋势，帮助企业技术决策者、架构师、开发者们迎接云原生时代的到来。 最近，O’Reilly 公布了一份关于企业微服务市场现状的数据调研。报告显示，在访问了全球 1,502 名软件工程师、系统和技术架构师、工程师以及决策者后，有 77％ 的组织反馈采用了微服务，其中 92％ 的组织成功使用了微服务。 如果以这份报告为依据，微服务在企业的普及率已接近八成。看起来，企业对微服务的兴趣可能已经接近顶峰。 云原生的基础设施从设计上保证了它是微服务部署的最佳平台，但是也对现有的微服务框架带来了新的挑战 ，在云原生大行其道的今天： 我们对微服务还应该继续投入精力关注吗？ 云原生和微服务之间的关系是什么？ 随着 Serviece Mesh 等技术的不断成熟，微服务的体系和思想会产生怎样的演化？ Spring Cloud、Dubbo 还会继续作为微服务开发框架的继续流行下去吗？ 容器、Kubernetes、ServiceMesh、Serverless 这些云原生时代的主角，会如何助力下一代微服务架构为业务发展赋能？ 这些问题值得每一位技术从业人员去思考，并发现由此带来的企业数字化转型升级新挑战、新机遇。也许有同学会说：

微软近期开源了一个新的名为 Open Service Mesh [1] 的项目并准备 捐赠给 CNCF [2] 。 基本介绍  Open Service Mesh (OSM) is a lightweight, extensible, Cloud Native service mesh that allows users to uniformly manage, secure, and get out-of-the-box observability features for highly dynamic microservice environments. ” Open Service Mesh（OSM）是一个轻量级，可扩展的云原生服务网格，它使用户能够统一管理，保护和获得针对高度动态微服务环境的开箱即用的可观察性功能。 OSM 在 Kubernetes 上运行基于 Envoy 的控制平面，可以使用 SMI API 进行配置。它通过以 sidecar 的形式注入 Envoy 代理来工作。 控制面负责持续配置代理，以配置策略和路由规则等都保持最新。代理主要负责执行访问控制的规则，路由控制，采集 metrics 等。（这和目前我们常见到的 Service Mesh 方案基本都一样的） 显著特性 基于 Service Mesh Interface (SMI) 的实现，主要包括

KubeSphere v3.0 发布是 KubeSphere 社区最重要的里程碑，v3.0 刚刚 GA 发布了两个多月，就受到了来自合作伙伴、用户、贡献者等多方面的高度认可。例如， KubeSphere 上架 AWS Quickstart 深度集成 Amazon EKS，还与 AWS、Cisco、Intel 等国际巨头厂商发布了联合解决方案；KubeSphere 在头部互联网和金融行业也有了更多的用户落地实践，比如 中通基于 KubeSphere 构建了大规模的 ZKE 容器平台 ， 微众银行基于 KubeSphere 打造了一站式云原生机器学习平台 Prophecis ， 遥望网络使用 KubeSphere 支撑了 “双十一” 活动完成了 13.2 亿规模的交易 ；开源社区贡献者数量的增长也迎来了新的一轮井喷，几个核心开源项目的贡献者总数已经超过了 100 人。 KubeSphere 之所以能够如此快速发展，得益于开源社区带来的天然优势，以及社区里长期活跃的用户、贡献者积极参与社区，帮助推动产品和社区快速成长， 我们坚持认为 KubeSphere 开源社区的每一位用户和贡献者朋友都是 KubeSphere 生态中的重要组成部分 。为了跟社区朋友们零距离交流，12 月 19 日，KubeSphere 社区联合 CNCF 将在北京举办一场年度的云原生 Meetup，

Photo @ Julien Riedel 文 | 尘央 引言 本文以一张云进化历史图开场，来谈谈云原生时代消息中间件的演进路线，但本文绝对不是“开局一张图，内容全靠编”。 从虚拟化技术诞生以来，IaaS/PaaS/SaaS 概念陆续被提了出来，各种容器技术层出不穷。到 2015 年， Cloud Native 概念应运而生，一时间，各种云厂商，云服务以及云应用都加上了“云原生”前缀。 我们也一直在思考，传统的消息中间件需要做些什么才能加上云原生这个修饰词，这也是本文探讨的主题：传统的消息中间件如何持续进化为云原生的消息服务。 云原生消息服务 什么是云原生 首先来谈谈什么是云原生，云原生是一个天然适用于云计算的架构理念，实践云原生技术理念的应用可以最大化享受云计算的技术红利，包括弹性伸缩、按量付费、无厂商绑定、高 SLA 等。 应用在实践云原生技术理念时一般会遵循四个要素： 采取 DevOps 领域的最佳实践来管理研发和运维流程。 通过 CICD 工具链做到应用的快速迭代和持续交付。 采取微服务架构。 采取容器及相关技术进行应用的托管。 消息服务作为应用的通信基础设施，是微服务架构应用的核心依赖，也是实践云原生的核心设计理念的关键技术，通过消息服务能够让用户很容易架构出分布式的、高性能的、弹性的、鲁棒的应用程序。消息服务在云原生的重要性也导致其极可能成为应用实践云原生的阻塞点

Photo @ Julien Riedel 文 | 尘央 引言 本文以一张云进化历史图开场，来谈谈云原生时代消息中间件的演进路线，但本文绝对不是“开局一张图，内容全靠编”。 从虚拟化技术诞生以来，IaaS/PaaS/SaaS 概念陆续被提了出来，各种容器技术层出不穷。到 2015 年， Cloud Native 概念应运而生，一时间，各种云厂商，云服务以及云应用都加上了“云原生”前缀。 我们也一直在思考，传统的消息中间件需要做些什么才能加上云原生这个修饰词，这也是本文探讨的主题：传统的消息中间件如何持续进化为云原生的消息服务。 云原生消息服务 什么是云原生 首先来谈谈什么是云原生，云原生是一个天然适用于云计算的架构理念，实践云原生技术理念的应用可以最大化享受云计算的技术红利，包括弹性伸缩、按量付费、无厂商绑定、高 SLA 等。 应用在实践云原生技术理念时一般会遵循四个要素： 采取 DevOps 领域的最佳实践来管理研发和运维流程。 通过 CICD 工具链做到应用的快速迭代和持续交付。 采取微服务架构。 采取容器及相关技术进行应用的托管。 消息服务作为应用的通信基础设施，是微服务架构应用的核心依赖，也是实践云原生的核心设计理念的关键技术，通过消息服务能够让用户很容易架构出分布式的、高性能的、弹性的、鲁棒的应用程序。消息服务在云原生的重要性也导致其极可能成为应用实践云原生的阻塞点

简介： 本文整理自作者于 2020 年云原生微服务大会上的分享《云原生时代的消息中间件演进》，主要探讨了传统的消息中间件如何持续进化为云原生的消息服务。 作者 | 周礼（不铭） 阿里巴巴集团消息中间件架构师 导读 ：本文整理自作者于 2020 年云原生微服务大会上的分享《云原生时代的消息中间件演进》，主要探讨了传统的消息中间件如何持续进化为云原生的消息服务。 引言 本文以一张云进化历史图开场，来谈谈云原生时代消息中间件的演进路线，但本文绝对不是“开局一张图，内容全靠编”。 从虚拟化技术诞生以来，IaaS / PaaS / SaaS 概念陆续被提了出来，各种容器技术层出不穷。到 2015 年，Cloud Native 概念应运而生，一时间，各种云厂商，云服务以及云应用都加上了“云原生”前缀。 我们也一直在思考，传统的消息中间件需要做些什么才能加上云原生这个修饰词，这也是本文探讨的主题：传统的消息中间件如何持续进化为云原生的消息服务。 云原生消息服务 1. 什么是云原生 首先来谈谈什么是云原生，云原生是一个天然适用于云计算的架构理念，实践云原生技术理念的应用可以最大化享受云计算的技术红利，包括弹性伸缩、按量付费、无厂商绑定、高 SLA 等。 应用在实践云原生技术理念时一般会遵循四个要素： 采取 DevOps 领域的最佳实践来管理研发和运维流程； 通过 CICD

基于目前智慧抄表的趋势判断，自动化远传抄表是LoRa无线远传技术的未来发展方向，即只部署1个基站抄收整个小区内的LoRa水表，再通过运营商的2G/4G网络，水司/水务公司在办公室就能远程抄收水表数据，全自动远传抄表。 故而水表无线抄表，或者说无线抄表就有了以下3点核心需求：可抄到、功耗（使电池长时间待机）、双向交互畅通。 一、可抄到：虽然LoRa在传输距离和穿透力比传统的FSK、GFSK更加优良，但仍然很难实现一个集中器对整个小区的无死角信号接收，这是因为很多厂家在使用lora远传技术时忽略了水表本身结构对无线传输的影响，而只将远距离通信的效果完全寄托于LoRa, 如LORA的甚高频RF无线类型对金属等结构件极其敏感，设计上的稍作改动都会使无线传输效果大打折扣，水表与LoRa或者说水表与无线的组合应该是相辅相成，不应该孤立的看成是两种组件简单的组装，厂家在产品设计初期就应该特别注意。 二、功耗：电池容量是一定的，要想省电而保证模块常年的正常运行，降低LoRa的功耗成为智能水表对LoRa技术的又一要求。 LoRa呼吸/心跳工作方式，即在休眠一段时间后接收打开搜索唤醒信号，如有唤醒信号则正常收发进行抄表或发现无唤醒信号则进入休眠的工作方式。在整个工作方式里，抄表状态下的功耗是不能够节省的，而呼吸状态只产生休眠和接收功耗，显而易见，控制接收功耗是关键

service mesh 的文章都会从网络层的又一个抽象说起，把 service mesh 看做建立在 TCP 层之上的微服务层。我这次换个思路，从 service mesh 的技术根基——网络代理来分析。 说起网络代理，我们会想到翻墙，如果对软件架构比较熟悉的会想到 Nginx 等反向代理软件。其实网络代理的范围比较广，可以肯定的说，有网络访问的地方就会有代理的存在。 Wikipedia 对代理的定义如下： In computer networks, a proxy server is a server (a computer system or an application) that acts as an intermediary for requests from clients seeking resources from other servers. NOTE：代理可以是嵌套的，也就是说通信双方 A、B 中间可以多多层代理，而这些代理的存在有可能对 A、B 是透明的。 简单来说，网络代理可以简单类比成现实生活中的中介，本来需要通信的双方因为各种原因在中间再加上一道关卡。本来双方就能完成的通信，为何非要多此一举呢？那是因为代理可以为整个通信带来更多的功能，比如： 拦截：代理可以选择性拦截传输的网络流量，比如一些公司限制员工在上班的时候不能访问某些游戏或者电商网站