大家好，关于lay网站源码分享很多朋友都还不太明白，不过没关系，因为今天小编就来为大家分享关于网站开源源码的知识点，相信应该可以解决大家的一些困惑和问题，如果碰巧可以解决您的问题，还望关注下本站哦，希望对各位有所帮助！
服务网格的2021，“稳”字当先。不管是原生社区发展，还是行业实践落地，都以“稳定”为第一要义。少了前几年大跃进式的架构演进、功能更迭，多了更务实、更落地的行业探索与实践，2021年的服务网格正从当年那个狂奔的“少年”、“流量明星”，成长为真正的“实力派”，逐步进入成熟期，被更多行业、企业和标准化组织所接纳。本文将从社区进展、实践落地、行业标准、技术生态等角度回顾服务网格的2021，帮助读者了解过去一年服务网格的整体进展，为企业选型、落地服务网格提供一些参考。
本文是“2021InfoQ年度技术盘点与展望”系列文章之一。
社区进展：稳定务实
2021年，Istio社区如约每三个月推出一个版本：1.9，1.10，1.11，1.12。稳定的版本发布周期显示出Istio社区发展进入常态化，也为企业选择合适的版本提供了便利。总的来说，2021年Istio社区没有发布特别重大的架构调整或者创新能力，更多在接入性、运维性、API等方面提供更好的原生支持：
1.9——更好用的虚拟机集成（Beta）、请求分类（Beta）、KubernetesServiceAPI支持（Alpha）、与外部授权系统的整合（Experimental）等。其中虚拟机集成延续了1.8版本引入智能DNS（解决跨环境服务名解析问题）后虚拟机接入的体验持续优化，进一步增强服务网格纳管非容器环境的能力。1.10——Kubernetes资源发现选择器、稳定的修订版标签、Sidecar网络变化等。其中Kubernetes资源发现选择器可以限制Istiod从Kubernetes接收和处理的配置集，配合SidecarCRD/API资源，进一步优化了Istiod到Envoy的配置量。1.11——CNI插件（Beta）、外部控制平面（Beta）、网关注入、对修订和标签部署的更新、支持Kubernetes多集群服务（实验性）。其中CNI插件为用户提供了Kubernetes环境下替代istio-init容器的方案（不需要更高Kubernetes权限）；外部控制平面可以为用户提供部署在管控集群的网格控制面；对修订和标签部署的更新可以让用户灰度进行Istio自身的部署、升级，降低Istio自身的运维风险。1.12——WebAssemblyAPI、遥测API、KubernetesGatewayAPI。其中增加了WasmPlugin作为WebAssemblyAPI，改善Istio使用WebAssembly进行插件扩展的体验。
纵观2021年Istio社区发布的四个版本，不难看出：
没有发布特别重大的架构调整、创新能力：企业在Istio版本选择上没有特别的门槛。接入易用性提升：增加虚拟机、CNI插件、WebAssembly等方面支持的内容，为更多复杂的业务部署环境、更苛刻的容器环境、更多语言的扩展需求提供原生能力支持。运维性提升：稳定的修订版标签、外部控制平面等，为Istio自身运维、多集群管控提供更好的原生支持。API标准化：包括WebAssemblyAPI、KubernetesGatewayAPI、KubernetesServiceAPI支持等，不管是Istio自身API的标准化，还是对Kubernetes标准API的支持，Istio社区在API标准化方面持续努力中。
实践落地：行业延展
服务网格技术最早起源于大型互联网公司（Google、IBM、Twitter/Buoyant），服务网格技术早期的应用落地也多为互联网公司：互联网大厂凭借其技术方面的深厚功力与持续投入，在最近几年已经完成了服务网格从初期探索到大规模生产应用的跨越；中小型互联网公司也紧跟大厂步伐，顺应云原生技术浪潮，完成了服务网格“初体验”。2021年，更多行业的企业开始尝试落地服务网格。
企业诉求
以大规模、高稳定、强安全著称的金融行业为例，2021年国内多家大型国有银行、头部股份制银行、头部券商的基础架构团队都开始引进服务网格技术，进行技术研究、平台搭建、业务试用。这里结合我们在2021年服务过的多家金融行业头部企业，及其他公开的技术资料，总结了金融行业企业对服务网格技术的典型诉求。
1.落地零门槛
在微服务2020年度复盘一文中，我们提出“平滑落地支撑”是企业落地服务网格的两大关键要素之一。在金融行业，这一点尤为明显。服务网格落地零门槛，是企业的核心诉求之一。
我们归纳了服务网格支撑企业落地需要具备的“三要素”：通信协议，注册中心，部署环境。
通信协议：服务网格能支持的服务通信协议，常见的如HTTP、gRPC、Dubbo等，另外也有具备行业属性的私有RPC协议；注册中心：服务网格能纳管的注册中心，包括常见的Eureka、Consul、Nacos、Zookeeper以及Kubernetes（ETCD）；部署环境：服务网格能支持的业务部署环境，除了天然云原生的Kubernetes+Docker外，对于遗留系统所在的虚拟机、物理机，也需要同等对待。
在满足“三要素”后，服务网格才能达到业务落地的“及格线”。
此外我们发现，金融行业还存在着更多“拦路虎”：
严格的环境管控：部署平台（容器、虚拟机、物理机）与基础平台（微服务、中间件）分属不同团队，又由于企业职责划分、金融合规要求等因素，服务网格的落地受到了诸如网络环境、管理权限、金融规范等更多限制；复杂的存量系统：头部金融行业企业大多已具备了比较完整的分布式体系，但也存在不少复杂、异构的外采、遗留系统，由于多开发语言、多通信协议、无法修改代码、没有注册发现机制等因素，不少系统无法纳管在已有体系中，成为企业分布式体系的“孤岛”。
2.架构场景匹配
与传统微服务框架侧重覆盖服务治理能力的业务场景不同，服务网格重点解决企业的架构场景问题。除了要实现云原生体系下微服务纳管与治理能力外，还需要覆盖异构应用统一治理、遗留系统迁移等架构场景需求，真正意义上解决企业微服务化后存在的整体性问题。
我们归纳了金融行业企业在架构场景方面的典型诉求如下：
多集群、多机房业务的纳管：包括提供正常的服务发现、调用、治理、跨区域容灾等；现有单体、微服务架构，向云原生服务网格架构长期、平滑、稳定迁移演进：以业务无感知方式，从现有架构逐步灰度方式演进到服务网格架构，迁移过程服务互通、可治理、可观测，并保证高SLA。
核心价值
在初步完成服务网格认知后，企业用户往往会发出灵魂拷问：为什么要上服务网格？服务网格有什么价值？
一般来说，通识的服务网格核心价值“标准答案”是：
业务无需感知微服务组件：微服务架构支撑、网络通信、治理等相关能力下沉到基础设施层，业务部门无需投入专人开发与维护，可以有效降低微服务架构下研发与维护成本；支持多开发语言、框架：服务网格天然不限制开发语言、开发框架，提供多语言服务治理能力；框架升级零成本：支持框架热升级，降低中间件和技术框架客户端、SDK升级成本；微服务体系统一纳管、演进：将存量微服务集群、遗留系统、外购系统微服务体系统一管理、演进。
对于企业内部不同团队，服务网格价值侧重会有所不同：
基础架构/平台研发团队：更看重服务网格覆盖的架构场景多开发语言、框架无关，可以纳管各种业务应用接入；框架升级零成本，无需业务重启或感知；微服务体系统一纳管、演进，可以将已有微服务集群、遗留系统、外购系统等“一把抓”，统一管理与演进；业务研发团队：更看重服务网格覆盖的业务场景一键接入微服务治理全套治理、监控能力，如熔断、限流、降级、容错、故障注入、指标监控、链路追踪等；遗留、外购系统可以纳入统一治理，具备同等治理、监控能力，与其他业务微服务互联互通；无需感知微服务组件，业务研发者不再需要学习、研究和维护微服务相关技术与框架。
面临挑战
即使Istio版本趋于稳定，众多互联网公司也已经顺利完成服务网格落地，更多行业企业落地服务网格依旧面临挑战。
1.技术面：零门槛接入不易
从技术角度分析，实现“零门槛”面临三大挑战：
通信协议扩展——作为企业落地服务网格的“三要素”之首，实现通信协议的代理、解析、治理、可观测等全套能力是一个浩大的工程，特别是对于那些设计上远离HTTP、gRPC等通用协议的私有RPC协议（在金融行业特别常见），需要有巧妙且完整的扩展机制加以实现。自定义插件扩展——大部分研发者无法直接编写EnvoyC++的扩展代码，Envoy原生提供的Lua语言扩展能力薄弱，被社区寄以厚望的WASM（WebAssembly）性能方面距离生产落地尚存不小差距，需要有真正好用且生产可用的Envoy自定义插件扩展机制。虚拟机/物理机环境纳管——即使Istio社区一直在改善服务网格的虚拟机/物理机环境纳管体验，各类公有云厂商也提供了相应“残血版”能力，但部署在非容器的业务始终像是“二等公民”一样——很难得到与容器化环境部署业务对等且同等的服务网格能力，需要有更完整、更兼容的非容器环境Sidecar管理、流量拦截等落地方案。
2.场景面：复杂场景覆盖不易
金融行业企业业务往往在各类环境、规范约束下部署运维，再加上业务系统本身的庞杂，存量、遗留、外采系统的组合存在，服务网格落地金融行业天然存在场景覆盖挑战：
业务的多集群、多机房部署，跨集群、跨机房调用的互联互通、统一治理、异常灾备，各类高可用保障等等，都需要服务网格系统具备适应能力；业务架构的平滑演进，从现有的单体、微服务架构，逐步迁移到云原生服务网格架构，包含微服务框架、服务网格等“跨代”技术栈的长期共存、服务发现、互访、治理、观测，需要真正意义上实现业务架构迁移场景的能力适应与高SLA保障。
行业标准：扬帆起航
服务网格技术在社区进展、实践落地等方面逐步稳定后，相应的行业标准与标准平台也水到渠成，开始扬帆起航。
信通院标准
2021年7月，由中国信息通信研究院主办的2021年可信云大会上，《服务网格技术能力要求》标准正式发布，阿里、网易、字节、Flomesh四家企业通过了首批测评，获得了服务网格最高级别评估。有趣的是，首批通过的四家企业可以说是云计算大厂、老牌互联网公司、新晋互联网公司、技术型创业公司的典型代表，这也侧面反映出各类企业对推进服务网格技术标准和落地的重视。
标准平台
在2021年，云计算厂商提供服务网格标准平台逐步完善与成熟，企业可以按需选择标准平台，或与厂商共建方式落地服务网格。
不同厂商提供标准平台类型上略有差异：
原生Istio资源+公有云基础设施+生态集成：侧重对原生Istio的兼容及与公有云现有生态集成；原生Istio平台化+私有化部署+三方集成：基于Istio扩展与增强，屏蔽原生Istio复杂性，侧重对微服务体系的统一管控、治理，以及对企业私有化环境的适应与兼容、集成；自研服务网格部分体系或全体系：不受限与Istio等开源社区，对开源服务网格的弱项针对性加强。
不同平台都有各自的适用场景和强弱项，企业可以结合自身情况自行选择。
技术生态：百家争鸣
服务网格在2021年进入稳定期，服务网格技术生态也在这一年百花齐放百家争鸣。
开源项目
在2021年，一大批Istio相关的优秀项目开源，围绕易用性、扩展性、运维性等方面增强Istio：
Slime：基于Istio的智能服务网格管理器，为Istio增加了一个无侵入管理平面。2021年1月由网易开源。GetMesh：Istio集成和命令行管理工具，可用于Istio多版本管理。2021年2月由Tetrate开源。Aeraki：管理Istio的任何七层负载，提供对服务网格多协议扩展支持。2021年3月由腾讯开源。Layotto：云原生应用运行时，可作为Istio的数据平面。2021年6月由蚂蚁开源。HangoGateway：基于Envoy和Istio构建的API网关，天然兼容Istio，提供原生高性能和富代理能力。2021年8月由网易开源。
众多服务网格生态开源项目的出现，侧面印证了服务网格领域的勃勃生机。
多运行时
与服务网格将微服务治理能力下沉到基础设施层（Sidecar）的思想类似，多运行时（Multi-Runtime）在2020年由BilginIbryam提出，其对Sidecar模式的各种形态进行了总结和升华。多运行时自身特点可以归纳如下：
能力：提供相较服务网格更宽广的分布式能力，如中间件代理、消息pub/sub等；部署：可以跟业务1：1（per-pod）或1：N（per-node）对应，按需部署在多种环境下，且进行组件组合；交互：与应用通过标准API进行通信，不强调业务无侵入，应用内会有承载标准API的SDK。
比较典型的多运行时开源框架是由微软开源的Dapr（DistributedApplicationRuntime），其在2021年迎来了标志性的1.0版本，并且进入CNCFSandbox进行孵化，目前仍在高速发展中。
从落地实践角度，多运行时在2021年展现了不错的潜力和发展态势：
理念先进，可能是分布式架构的未来趋势；大厂主导，社区发展迅速，已有多家大厂入局探索；整体成熟度还不高，在点对点服务通信治理、能力完整度、API稳定性等方面尚存不足；可以与服务网格等已有技术进行生态整合，补齐短板。
eBPF
eBPF技术的出现使得在Linux内核编程并运行沙盒程序成为可能，而且无需更改内核源代码或加载内核模块。这就使得开发者可以从内核出发增强系统的可观察性、优化网络及其安全性。在服务网格领域，eBPF可以用于Sidecar网络加速，并且可以从底层观测内核消息队列、任务队列、网络包信息、网络连接等更深层次的信息。
在2021年，Cilium（eBPF开源框架）提出了用eBPF替代Sidecar实现内核级服务网格（数据面代理）的构想，以解决独立Sidecar带来的部署资源消耗、延时性能损耗等问题，实现真正意义上流量治理、观测能力下沉到基础设施层。不过，Cilium的这一大胆构想很快就收到了来自“传统”服务网格阵营的“反击”，理由包括eBPF实现服务代理能力的诸多限制、操作复杂、协议处理复杂度高、内核版本有依赖等等。
不论如何，eBPF技术融入服务网格生态已经是一个新趋势，即使无法真正实现Sidecar的完美替代，eBPF同样可以作为Sidecar的有力补充，使两者在流量链路上水乳交融。
Proxyless
服务网格在诞生之初就以独立SidecarProxy负责流量的代理、治理、观测，服务网格实现框架也都默认以独立Proxy方式来组织数据平面能力，并与应用进程内的传统微服务框架划清界限，各谈利弊，似乎Proxy模式就是服务网格数据平面的标准模式。在2021年，应用进程内框架与独立SidecarProxy间的“次元壁”被打破，Proxyless理念被越来越多提及。
WHYProxyless（本质上是针对服务网格独立SidecarProxy模式的“弊”而来）：
性能问题：独立Proxy带来的额外部署资源开销和延时性能开销；流量拦截：独立Proxy的流量拦截大多需要配合IPTables等技术，需要管理权限，逻辑复杂，排障不易；治理粒度：独立Proxy在应用进程外工作，且无状态，无法对应用进程内的程序、方法进行治理与观测。
WHATProxyless（能提供对各类分布式场景的能力补充）：
服务网格优化：在应用内提供细粒度治理、监控以及流量拦截能力；多运行时操作：在应用内提供标准SDK，为业务提供对基础设施资源操作接口；能力继续下沉：在操作系统内核实现流量的处理、治理、观测。
HOWProxyless（几种常见实现方式）：
框架/SDK：经典用法，回到过去；无侵入Agent：无侵入方式实现业务代码增强，原理可以参考我们之前从服务框架到服务网格，网易轻舟双引擎多模式服务治理演进实践一文中“服务框架：无侵入Agent服务治理”部分介绍；原生RPC支持：新版本gRPC直接提供治理功能，并支持了直接对接控制平面的标准xDS协议；eBPF：在Linux内核对流量进行处理、治理、观测。
从架构演进层面考量，Proxyless有“逆流”发展的嫌疑。不过，从务实落地角度来看，Proxyless为Proxy带来的能力补充，或许可以更好地帮助企业完成从传统架构到云原生架构的逐步迁移落地。
未来展望
针对服务网格2021的复盘到这里告一段落，对于服务网格的未来，我们充满信心。在本文的最后，给出我们对服务网格的未来展望：
零门槛
随着服务网格技术的逐步精进成熟，以及越来越多行业的落地经验积累，技术面和场景面所面临的挑战终将被克服，服务网格落地门槛逐步会趋于零。
标准化
服务网格的技术能力和场景覆盖得以高度抽象化和通用化，服务网格平台/产品也会随之高度标准化，企业选择服务网格平台/产品会更加容易。
全面统一
以Envoy、Istio为代表的服务网格技术会助力实现相关软件领域的统一，如更多的L7流量代理会以Envoy为核心构建，数据平面与控制平面之间会以xDS协议交互等。企业架构师想实现的分布式体系全局统一治理将不再是奢望。
生态融合：Proxyless+Proxy+eBPF+多运行时
服务网格不同生态间不会是对立关系，最终会“务实”地形成“合力”，彼此共赢：在流量链路上的Proxyless->Proxy->eBPF协作，能力互补；多运行时下存在的能力短板可以融合服务网格的成熟能力，加速自身发展。
参考资料（特别感谢服务网格领域的诸多实践者与分享者）：
从服务框架到服务网格，网易轻舟双引擎多模式服务治理演进实践：https://www.infoq.cn/article/KNp1ibj40vS8IIZCizMW
解读微服务的2020：框架在左网格在右，云原生时代的微服务路在何方：https://www.infoq.cn/article/4Zog2lMBqKjAeMTc8Add
云原生时代的流量入口：EnvoyGateway：https://www.infoq.cn/article/SF5sl4IlUtUxuED3Musl
Istio1.9发布——重点改善Istio的Day2操作：https://mp.weixin.qq.com/s/E7iwBF6hhPm5aTukTlTCMg
Istio1.10发布及官网改版：https://mp.weixin.qq.com/s/Lq6zF90FR-ohT9ON-88Z_Q
Istio1.11发布：https://mp.weixin.qq.com/s/QkLUFOCQz2AWt2En-G-VQg
Istio1.12发布：https://mp.weixin.qq.com/s/Q52IQrXxxHEn2c8rkAVTgA
基于gRPC和Istio的无Sidecar代理的服务网格：https://mp.weixin.qq.com/s/aYwo2criOotqNp8lD39QAA
都2021年了，对于服务网格，社区到底在讨论什么：https://mp.weixin.qq.com/s/ZDDC4YAebbdws8Md9zCrqQ
Daprv1.0展望：从servicemesh到云原生：https://skyao.io/talk/202103-dapr-from-servicemesh-to-cloudnative
告别Sidecar——使用EBPF解锁内核级服务网格：https://mp.weixin.qq.com/s/W9NySdKnxuQ6S917QQn3PA
译文：服务网格将使用eBPF？是的，但Envoy代理将继续存在：https://mp.weixin.qq.com/s/iZYXPec7Lh0fhflA42d8gA
作者介绍：
裴斐，网易数帆高级技术专家、资深架构师。10余年企业级平台架构和开发经验，目前主要负责网易数帆轻舟微服务团队，专注于企业微服务架构及云原生技术的研究与落地工作。带领团队完成轻舟服务网格、微服务框架、API网关等多个项目在网易集团落地及商业化产品输出，并主导建设了Slime、Hango等多个云原生开源项目。
关于本次lay网站源码分享和网站开源源码的问题分享到这里就结束了，如果解决了您的问题，我们非常高兴。