Envoy

哪种服务网格最适合你的企业?近年来，Kubernetes服务网格框架数量增加迅速，使得这成为一个棘手的问题。 下面将介绍9种较受欢迎的用以支撑微服务开发的服务网格框架，每种方案都给出了其适用场景。 什么是服务网格 服务网格近年来有很高的话题度，背后的原因是什么? 微服务已经成为一种灵活快速的开发方式。然而，随着微服务数量成倍数地增长，开发团队开始遇到了部署和扩展性上的问题。 容器和Kubernetes这样的容器编排系统 ，将运行时和服务一起打包进镜像，调度容器到合适的节点，运行容器。这个方案可以解决开发团队遇到的不少问题。然而，在这个操作流程中仍存在短板：如何管理服务间的通信。 在采用服务网格的场景下，以一种和应用代码解耦的方式，增强了应用间统一的网络通信能力。服务网格扩展了集群的管理能力，增强可观测性、服务发现、负载均衡、IT运维监控及应用故障恢复等功能。 服务网格概览 服务网格一直有很高的热度。正如Linkerd的作者William Morgan所提到的：“服务网格本质上无非就是和应用捆绑在一起的用户空间代理。” 此说法相当简洁，他还补充道，“如果你能透过噪音看清本质，服务网格能给你带来实实在在的重要价值。” Envoy是许多服务网格框架的核心组件，是一个通用的开源代理，常被用于Pod内的sidecar以拦截流量。也有服务网格使用另外的代理方案。 若论具体服务网格方案的普及程度

喜欢就关注我们吧！ Kuma 1.0 GA 现已发布，包含了 70 多种新功能和改进。Kuma 是一个现代的通用服务网格控制平面，基于 Envoy 搭建，Envoy 是一个为云原生应用设计的强大的代理软件。 Kuma 高效的数据平面和先进的控制平面，极大地降低了各团队使用的难度，可以在包括 Kubernetes、虚拟机、容器、裸机和传统环境在内的任意平台上运行，以落实整个组织中的云原生体验。 此版本主要更新内容包括有： 多区域 自动生成“区域”资源，简化了多区域部署。 本地感知的负载平衡可减少多区域延迟并降低出口成本。 通过新的 "Ingress"DP 类型将入口数据平面代理自动同步到全局 CP。 Services & Policies 增加了对显式外部服务的支持。 增加了对新的“服务”资源的支持，该资源将每个“kuma.io/service”分组为多个数据平面代理。 添加了对 Kafka 协议的支持。 “网格”资源中的可配置 pass-through 控制功能。 性能 在关键任务 SLA-enforced 的企业环境中进行了生产中的实战测试。 在 Kuma 中运行成千上万的服务时，整体性能有了显着提高（〜5 倍）。 资源内部缓存的改进，以更好地支持高数据平面代理负载。 使用大量资源运行时，提高了 CLI 和 GUI 的总体可伸缩性。 安全

前言 在上一篇，已经用Envoy工具统一发布了Deploy项目代码。本篇我们来看看如何用nginx实现负载均衡 负载均衡器IP 192.168.10.11 【高可用架构】系列链接： 待部署的架构介绍 演示 配置应用服务器 首先，需要将上一篇部署的两台应用服务器，都能够单独访问 配置192.168.10.12、192.168.10.18上nginx的config # vi /etc/nginx/config.d/dev.deploy.goods.conf server { listen 80; server_name dev.deploy.goods; index index.html index.htm index.php; location / { rewrite ^/(.*)$ /index.php/$1 last; try_files $uri $uri/ /index.php?$query_string; } location ~ (.+\.php)(.*)$ { root "/var/www/Deploy/public"; fastcgi_split_path_info ^(.+\.php)(.+)$; fastcgi_pass unix:/var/run/php-fpm/php7-fpm.sock; fastcgi_index index.php; include

Istio 1.8 是 Istio 在 2020 年发布的最后一个版本，按照 Istio 社区在 今年初设定的目标 继续推进，该版本主要有以下更新： 支持使用 Helm 3 进行安装和升级 正式移除了 Mixer 新增了 Istio DNS proxy，透明地拦截应用程序的 DNS 查询，实现智能应答 新增了 WorkloadGroup 以简化对虚拟机的引入 WorkloadGroup 是一个新的 API 对象，旨在与虚拟机等非 Kubernetes 工作负载一起使用，模仿现有的用于 Kubernetes 工作负载的 sidecar 注入和部署规范模型来引导 Istio 代理。 安装与升级 Istio 从 1.5 版本开始弃用了 Helm，使用 istioctl manifest 方式安装，后来又改成了 istioctl install ，现在又重新回归了 Helm，Helm 作为 Kubernetes 环境下最常用的应用安装管理组件，此次回归也是倾听用户声音，优化安装体验的的反应吧，不过 Istio Operator 依然将是 Istio 安装的最终形式，从 1.8 版本开始 Istio 支持使用 Helm 进行 in-place 升级和 canary 升级。 增强 Istio 的易用性 istioctl 命令行工具新的了 bug reporting 功能（ istioctl

针对腾讯、百度、阿里、京东等100+家互联网公司，对其技术方向进行调查和研究 从18年开始，各大厂商都陆续把底层业务从KVM、Vmware等底层架构开始逐步迁移到Docker+K8s体系中来，而且80%大中型企业的关键业务中更多的云化将是接下来的重中之重，因为很多企业已经意识到容器以及其他云原生的应用不仅会带来技术模式的改变，甚至带来运营模式和商业模式颠覆性的变化。这个变化将会加速企业的竞争，对企业产生极大的冲击，进而也对企业中的IT人产生极大的冲击。当然，这种冲击也会是极大的机遇。 由浅入深吃透容器云、微服务 Kubernetes 在帮助你掌握K8s容器编排平台的架构、核心组件、工作模型等，实现在K8.上运行云原生或传统应用程序。 Docker Docker是一个开放源代码软件项目，让应用程序部署在软件容器下的工作可以自动化进行，借此在Linux操作系统上，提供一一个额外的软件抽象层，以及操作系统层虚拟化的自动管理机制。 Ceph Ceph是一种为优秀的性能、可靠性和可扩展性而设计的统一的、分布式文件系统。其能够在维护POSIX兼容性的同时加入了复制和 容错功能。 Envoy+lstio Envoy代理配置精讲，涉及Listener、Route、 Cluster、 Endpoin和xDS API等。lstio部分主 要讲述其控制平面相关组件及工作机制，涉及包括流量管理，策略

Envoy为什么能战胜Ngnix——线程模型分析篇 导读：随着Service Mesh在最近一年的流行，Envoy 作为其中很关键的组件，也开始被广大技术人员熟悉。作者是Envoy的开发者之一，本文详细说明了Envoy的线程模型，对于理解Envoy如何工作非常有帮助。内容较为深入，建议细细品读。 关于Envoy的基础技术文档目前相当少。为了改善这一点，我正在计划做一系列关于Envoy各个子系统的文章。 这是第一篇文章，请让我知道你的想法以及你希望涵盖的其他主题。最常见的问题之一是对Envoy使用的线程模型进行描述。 本文将介绍Envoy如何将连接映射到线程，以及Envoy内部使用的线程本地存储（TLS）系统，正是因为该系统的存在才可以保证Envoy以高度并行的方式运行并且保证高性能。 线程概述 图1：线程概述 Envoy使用三种不同类型的线程，如图1所示。 Main：此线程可以启动和关闭服务器。负责所有xDS API处理（包括DNS ， 运行状况检查和常规集群管理 ）， 运行时 ，统计刷新，管理和一般进程管理（信号， 热启动等）。 在这个线程上发生的一切都是异步的和“非阻塞的”。通常，主线程负责所有不需要消耗大量CPU就可以完成的关键功能。 这可以保证大多数管理代码都是以单线程运行的。 Worker：默认情况下，Envoy为系统中的每个硬件线程生成一个工作线程。（可以通过-

1，istio 概念 1.2 istio 是什么？ 使用云平台可以为组织提供丰富的好处。然而，不可否认的是，采用云可能会给 DevOps 团队带来压力。开发人员必须使用微服务已满足应用的可移植性，同时运营商管理了极其庞大的混合和多云部署。istio允许你连接、保护、控制和观测服务。 在较高的层次上，istio 有助于降低这些部署的复杂性，并减轻开发团队的压力。它是一个完全开源的服务网络，可以透明地分层到现有的分布式应用程序上。它也是一个平台，包括允许它集成到任何日志记录平台、遥测或策略系统的API。istio 的多样化功能集使您能够成功高效地运行分布式微服务架构，并提供保护、连接和监控微服务的统一方法。 1.3 什么是服务网络？ 在从单位应用程序向分布式微服务架构的转型过程中，开发人员和运维人员面临诸多挑战，使用 istio 可以解决这些问题。 服务网路（Service Mesh）这个术语通常用于描述构成这些应用程序的微服务网路以及应用之间的交互。随着规模和复杂性的增长，服务网路越来越难以理解和管理。它的需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及通常更加复杂的运维需求，例如 A/B 测试、金丝雀发布、限流、访问控制和端到端认证等。 istio 提供了一个完整的解决方案，通过为服务网络提供行为洞察和操作控制来满足微服务应用程序的多样化需求。 1.4 为什么要使用

京东云开发者社区在3月底于北京举行了以“Cloud Native时代的应用之路与开源创新”为主题的技术沙龙，现场多位技术大咖与开发者们面对面就Cloud Native进行了深入交流，探讨涉及 容器、开源数据库 等诸多技术层面的问题。 现场有超百位开发者热情参与了交流与互动，尤其对 容器、微服务、Serverless 等技术应用与开源创新十分关注。想必这些探讨也将为云计算、架构等相关领域的从业者们提供借鉴与新思路，十分值得广大开发者们认真学习与总结！ 我们将整理后的视频及内容资料在这里分享给大家，没能到场的小伙伴可以通过这些资料来学习和了解课程内容。 ## 沙龙内容概要 沙龙活动重点聚焦云原生时代下，容器、微服务、Serverless以及数据库等技术应用与开源创新，同时高度结合京东云在Cloud Native以及开源领域的核心技术与一系列成功实践为开发者们进行答疑解惑！ 以下是沙龙 第二部分 分享的全部内容，希望能给各位开发者带来帮助： ## 云原生与微服务架构 —— 京东云专家架构师 王碧波—— （建议在Wi-Fi环境下观看） https://v.qq.com/x/page/t0856s6qgbg.html?start=undefined 01微服务架构概述 第一部分聊完容器相关内容，王碧波作为本场沙龙的第二位分享嘉宾，为开发者们现场带来了主题为“云原生与微服务架构”的技术演讲

作者 | 王夕宁 阿里巴巴高级技术专家 参与阿里巴巴云原生文末留言互动，即有机会获得赠书福利！ 在服务网格技术使用之前，为了更快更灵活地进行业务创新, 我们常常会把现有应用进行现代化改造, 把单体应用程序分拆为分布式的微服务架构。通常来说, 在微服务架构模式的变迁过程中, 最初都是面向代码库的模式。 对这些微服务治理的实现, 往往是以代码库的方式把这些服务治理的逻辑构建在应用程序本身中，这些代码库中包括了流量管理、熔断、重试、客户端负载均衡、安全以及可观测性等这样的一些功能。这些代码库随着功能的不断增强, 版本也随之变更，因为版本不同导致的冲突问题处处可见。此外，库的版本一旦变更，即使你的应用逻辑并没有任何变化，整个应用也要随之全部变更。由此可见, 随着应用的增长和团队数量的增加，跨服务一致地使用这些服务治理功能会变得非常复杂。 服务治理的能力 Sidecar 化 通过把这些服务治理的能力 Sidecar 化，就能够把服务治理的能力与应用程序本身进行了解耦，可以较好地支持多种编程语言、同时这些 Sidecar 能力不需要依赖于某种特定技术框架。这就是我们常说的面向 Sidecar proxy 的架构模式。 随着这些 Sidecar 代理功能的增强，原本需要在代码库中实现的服务治理功能被抽象化为一个个通用组件, 并被逐渐地下沉到代理中。这些服务治理能力的标准化、统一化

简介： 在正常生产环境中使用k8s部署业务后能正常运行还不够，我们需要很多附加的东西来满足日常的需求。比如日志、监控、告警等。这一篇给大家分享一下我们生产环境中的日志集中解决方案。当然不敢说是最好的，分享出来供大家参考。 在正常环境中有几类日志我们比较关心： 1、k8s中的ingress日志。比如traefik，里面记录的从公网域名访问进来的访问记录，类似nginx的access.log 2、istio中envoy边车日志。如果启用了istio那么这个日志也是需要的，每次程序被调用时都会有一个记录。 3、k8s中的事件日志。里面就有容器健康检查失败重新部署，或者pod新建、删除等事件。kubectl describe pods中的Events:内容 4、业务程序运行时产生的业务日志。比如java中常用的log4j套件输出的日志和kubectl logs命令查看的日志。这个和输出方式有关。 实现方式 这里日志收集的方式是采用elk模式，如果大家感兴趣还有loki的模式。当然这次分享是基于elk的。首先要部署的还是es集群，这里我们使用的是虚拟机部署方式非容器化。理由es是公共的组件可以对接所有的产品业务线，单独拿出来部署可以给别的产品线输出集中化日志存储方案。平时维护量还是比较少的，当然我们的es集群每15分钟大概800万条记录规模并不是特别大， 不过以后出现瓶颈横向扩容也不是问题