Sofa

文｜田阳 （花名：烈元） MOSN Maintainer 专一云原生等技术畛域 本文3042字 浏览 10 分钟 1. 背景Service Mesh 被越来越多的公司认可并实际，在理论落地过程中也遇到了不拘一格的问题，同时架构也在继续演进去解决这些问题：有的从初始的 DaemonSet mode 转变为 Sidecar mode，如 Linkerd ；有的从做 CNI 延长到 Service Mesh 场景， 联合 eBPF 应用 DaemonSet mode，如 Cilium ；现在 Istio 也新增了 Ambient Mesh ，反对 DaemonSet mode 作为其主推模式。 不难看出一个演进趋势就是围绕着是否须要 Sidecar 而开展，那么 Service Mesh 的下一站将会是 Sidecarless 吗？本文将对目前的社区趋势做一个简要剖析， 最初也将介绍蚂蚁在这方面的摸索和实际。 2. 社区趋势2.1 CiliumCilium[1] 是目前最火的云原生网络技术之一，基于革命性的内核技术 eBPF，提供、爱护和察看容器工作负载之间的网络连接。 在 6 月份，Cilium 公布了 1.12 版本，其中公布了 Service Mesh 能力、Sidecarless 架构，它提供了两种模式： 通过图表咱们能够发现：针对 L3/L4 的能力，Cilium 应用内核的 eBPF 间接反对；对于 L7 的局部能力，将应用 DaemonSet 部署的 Envoy 来反对。Cilium 认为大部分能力都不须要 L7 的参加，通过 eBPF 就能满足，所以 Cilium 也称本人为内核级服务网格。 ...

RPC全称 remote procedure call，即近程过程调用。借助 RPC 能够做到像本地调用一样调用近程服务。二者能够通过不同的协定进行数据传输，如Bolt协定，RESTful协定，Dubbo协定，H2c协定，HTTP协定。 SofaRpc在sofaBoot的根底上，将服务部署在多个服务器上，供不同服务器上的办法互相调用。 区别 注解形式服务公布 @SofaService(interfaceType = AnnotationService.class, bindings = { @SofaServiceBinding(bindingType = "bolt") })@Componentpublic class AnnotationServiceImpl implements AnnotationService { @Override public String sayAnnotation(String stirng) { return stirng; }}服务援用 @Componentpublic class AnnotationClientImpl { @SofaReference(interfaceType = AnnotationService.class, binding = @SofaReferenceBinding(bindingType = "bolt")) private AnnotationService annotationService; public String sayClientAnnotation(String str) { String result = annotationService.sayAnnotation(str); return result; }}同一服务公布多种协定同一服务注册多个注册核心 通信协议反对Bolt协定，RESTful协定，Dubbo协定，H2c协定，HTTP协定。同步，异步，回调，单向。 同步：在同步的调用形式下，客户端发动调用后会期待服务端返回后果再进行后续的操作。这是 SOFARPC 的默认调用形式，无需进行任何设置。 异步：异步调用的形式下，客户端发动调用后不会等到服务端的后果，继续执行前面的业务逻辑。服务端返回的后果会被 SOFARPC 缓存，当客户端须要后果的时候，再被动调用 API 获取。如果须要将一个服务设置为异步的调用形式，在对应的应用形式下设置 type 属性即可。 ...

2 月 24 日，MOSN 举办了 2022 年首次的社区会议。 MOSN 社区在会议上提出了新一年的 Roadmap，社区成员分享了 MOSN 在不同场景着落地实际的教训，以及大家一起大开脑洞，探讨了更多咱们能够发明的可能性。 MOSN 社区 RoadmapMOSN 在 2022 年次要的指标是公布 MOSN 1.0，以及开源一个新的开箱即用的产品。同时推动 MOE （ MOSN 2.0 架构）演进，对接更多的生态组件。 随着 MOSN 的落地用户越来越多，稳定性建设也是往年的重点倒退方向，让大家用得释怀。 社区会议分享嘉宾来自探探科技、阿里云、去哪儿网的用户，在本次会议中都踊跃分享了本人的应用案例，供大家借鉴参考。 探探科技谢正尧同学具体地列出了 MOSN 落地过程中遇到的问题和踩到的坑，给 MOSN 的后续优化提供了很好的思路。 有不少坑咱们都曾经安顿上了日程，MOSN 的开发者都赶在填坑的路上。 阿里云沐沂同学列出了新财年的布局，和大家分享了边缘的跨集群服务发现场景的租户拆分，以及新的部署模式。 去哪儿网佳龙同学比拟关注 Roadmap 中的 GC 方面，心愿能够引入一些高性能的网络框架，对性能优化方面有更多的需要。 以及很期待 MOSN 社区的 holmes，心愿能够解决查问题时的难题。 QA 回顾1.Q：MOE 的落地场景、最佳实际的博客有哪些？ A：具体内容咱们会在 Service Mesh Summit 2022 首届服务网格峰会进行分享。往年会有更多的落地场景，在尝试替换接入层网关，也会试点上线的，能够期待一下！ 2.Q：我可不可以了解为——如果 MOE 在 Envoy 被接管后，能够通过 Go 代码去写一个 filter，让它跑在 Envoy 上，之后我的数据链间接用 Envoy 就能够？ ...

sofa-jraft在同程游览中的实际同程艺龙作为对 raft 钻研较早的公司，早在14年算法的 paper 刚公布的时候，便曾经对其进行了调研，同时也与 paxos 、zab 等算法进行了具体的比照，并在公司外部的计数器、任务调度元信息存储等场景进行试点。不过晚期对于 raft 的尝试较多的是在 cs++ 技术栈试水，在 java 技术栈里却很少有波及。近期刚好有基于 etcd 的老我的项目因为须要自定义的数据结构须要重构，原有的 etcd 无奈在底层数据结构层面满足需要，因而决定采纳 java 技术栈联合开源我的项目 sofa-jraft 进行底层数据存储的开发，以期解决多节点数据强统一的问题。本文假如读者对 raft 及强统一的概念曾经有了较深的了解，具体介绍了公司外部如何应用 jraft 的进行老零碎的革新以及应用过程中遇到的工程问题，心愿其余对 raft 有趣味的同学能够一起探讨。 一、背景公司外部本来存在一个零碎 mdb (metadata database)，go 语言编写，用于治理所有的实例元数据信息，元数据的内容就是一个 map。该组件提供对元数据增删改查的接口，并且应用 go 语言编写，在检索数据时引入了 k8s selector 的包，应用 k8s selector 的解析规定筛选特定标签的元数据信息。数据长久化则是实用了强统一组件 etcd 进行存储，key 为元数据的 id，保障惟一，value 为具体的元信息，蕴含各个标签以及对应的值。 该零碎大体架构如图-1所示: 图-1：原来的架构该架构的弊病: 每隔一段时间须要去拉取 etcd 的全量数据，放心单次申请数据量太大的状况，对数据id进行了 hash 分片，顺次获取每个分片下个 key，再通过 key 去获取 value，导致 etcd 的查问频率十分高非 id 查问条件的一致性查问，和下面的问题一样，也须要做拉取全量数据的操作更新删除操作也是一样，须要拉取全量数据再操作剖析以上问题能够发现，应用 etcd 作为强统一存储，但 etcd 是基于 KV 存储的组件，并且解析组件 mdb 和 etcd 是拆散的，在须要保证数据最新的状况下，必须得去 etcd 拿最新的数据到本地再进行操作。而 etcd 基于 KV，就得拿到 etcd 的全量数据都给拉到本地后再做操作。 ...

楔子: 以蚂蚁典型的建站场景为例，在接入 Kusion 后，用户侧配置代码缩小到 5.5%，用户面对的 4 个平台通过接入对立代码库而消减，在无其余异样的状况下交付工夫从 2 天下降到 2 小时…… 注：本文是柴树杉在 2021 GIAC 大会上分享的内容。相干 PPT 内容请点击下方自行下载 GIAC 大会 PPT 下载：KCL申明式的云原生配置策略语言 0. 你好GIAC大家好，我是来自蚂蚁的同学，很快乐能在GIAC的编程语言新范式板块和大家分享《KCL配置策略语言》。KCL语言是蚂蚁外部的Kusion解决方案中针对云原生基础设施配置代码化自研的DSL语言，目前曾经在建站场景等一些场景开始小范畴推广试用。 咱们先看一下简略的KCL代码： schema GIACInvitation[name: str]: Name: str = name Topic: str = "分享主题" Company?: str = None Type: str = "分享嘉宾" Address: str = "深圳"invitation = GIACInvitation("姓名") { Topic: "KCL配置策略语言" Company: "蚂蚁团体"}这个例子代码先通过 schema 定义了一个 GIACInvitation 构造体：该构造体有一个 str 类型的 name 参数，同时还有一组标注了类型和默认值的属性。而后通过申明式的语法结构了GIACInvitation 的实例 invitation。 这个例子尽管简略，然而蕴含了 KCL 最重要的 schema 语言构造。从例子能够看出 KCL 尝试通过申明式的语法、动态类型查看个性来改良配置代码的编写和保护工作。这也是设计 KCL 语言的初衷，咱们心愿通过编程畛域成熟的技术实践来解决云原生畛域的配置代码化的问题。 ...

蚂蚁团体运维着可能是寰球最大的 K8s 集群：K8s 官网以 5k node 作为 K8s 规模化的高峰，而蚂蚁团体事实上运维着规模达到 10k node 规模的 K8s 集群。一个形象的比喻就是，如果官网以及跟着官网的 K8s 使用者能设想到的 K8s 的集群规模是泰山，那么蚂蚁团体在官网的解决方案之上曾经实现了一个珠穆朗玛峰，引领了 K8s 规模化技术的晋升。 这个量级的差别，不仅仅是量的差别，更是 K8s 治理保护的质的晋升。能保护有如此微小挑战巨量规模的 K8s 集群，其背地起因是蚂蚁团体付出了远大于 K8s 官网的优化致力。 所谓万丈高楼平地起，本文着重探讨下蚂蚁团体的在 K8s 的基石 --- etcd 层面做出的高可用建设工作：只有 etcd 这个基石稳当了，K8s 这栋高楼大厦才放弃稳定性，有 tidb 大佬黄东旭朋友圈佐证【图片已获黄总受权】。 面临的挑战etcd 首先是 K8s 集群的 KV 数据库。 从数据库的角度来看，K8s 整体集群架构各个角色如下： etcd 集群的数据库kube-apiserver etcd 的 API 接口代理、数据缓存层kubelet 数据的生产者和消费者kube-controller-manager 数据的消费者和生产者kube-scheduler 数据的消费者和生产者etcd 实质是一个 KV 数据库，存储了 K8s 本身资源 、用户自定义的 CRD 以及 K8s 零碎的 event 等数据。每种数据的一致性和数据安全性要求不统一，如 event 数据的安全性小于 K8s 本身的资源数据以及 CRD 数据。 ...

开篇这篇文章是基于SOFA Meetup合肥站的分享总结，次要针对于注册核心的定位以及性能介绍，通过对蚂蚁注册核心发展史的剖析，率领大家理解，蚂蚁的注册核心是如何一步一步演变为当初的规模和个性的。 更多深刻的技术细节，欢送大家退出到SOFA和SOFARegistry的社区中，探寻后果。 注册核心是什么服务发现 & 服务注册注册核心简略来说，是为了解决分布式场景下，服务之间相互发现的问题。 如下图所示，服务A想要调用服务B的时候，须要晓得B的地址在哪里，如何解决这个问题？ 一般来说，分为两个点： 服务发现能够有一个中心化的组件或者说是存储，它承载了所有服务的地址，同时提供进去一个可供查问和订阅的能力，服务的生产方能够通过和这个中心化的存储交互，获取服务提供方的地址列表。服务注册：同样是上文中中心化的组件，然而，这个时候的服务信息能够有两种措施 服务连贯注册核心，同时上报本身的服务以及元数据（也是明天本文讲述的重点）有一个集中的管制面（control plane）将用户定义的服务和IP的映射写入注册核心，例如AWS的CloudMap调用流程如上图所示，就是目前一种支流的注册核心模式，SOFARegistry和Nacos都是这种模式。 服务A，服务B通过SDK或者REST将本身的服务信息上报给注册核心服务A须要调用服务B的时候，就对注册核心发动申请，拉取和服务B相干的服务IP列表以及信息在获取到服务B的列表之后，就能够通过本身定义的负载平衡算法拜访服务B心跳心跳是注册核心用于解决服务不可用时，及时拉出服务升高影响的默认形式，如下图所示 服务B的一个节点断网或是hang住，引发心跳超时；或是宕机、断链间接引发心跳失败注册核心把问题节点从本身的存储中拉出（这里拉出依据具体实现：有的是间接删除，有的是标记为不衰弱）服务A收到注册核心的告诉，获取到服务B最新的列表DUBBO 注册核心上面通过DUBBO的例子，咱们来看一下注册核心是如何应用的，以及流程 首先，DUBBO在2.7和3.0中的配置略有不同，然而都是简略易懂的，这里都放上来 DUBBO-2.7 DUBBO-3.0 在RPC客户端只须要配置一个注册核心的地址即可，地址中蕴含了根底三元素 protocol（协定类型）比方，zookeeperhostport基于此，dubbo的注册流程如下图所示 服务的生产方通过DUBBO客户端向注册核心（Registry）发动注册行为（register）服务的生产方通过DUBBO客户端订阅信息（subscribe）注册核心通过告诉的形式，下发服务列表给服务生产方注册核心的实质通过前文的解说，以及DUBBO组件的具体例子，咱们大略能够演绎注册核心的实质 “存储” + “可运维” 一方面，注册核心须要存储能力去记录服务的信息，比方利用列表另一方面，注册核心在实际过程中，须要提供必须的运维伎俩，比方敞开某一服务流量蚂蚁注册核心编年史史前时代史前时代的蚂蚁是相当长远的架构，过后所有的服务部署在同一台物理机上或者JVM上，服务之间不存在有跨机器调用的场景，这里略过不表 硬负载时代起初，为了解决利用之间的耦合带来的部署难，运维难问题，咱们对服务进行了拆分，拆分后的服务，遇到了一个问题，就是如何解决服务之间的调用关系，这个时候，蚂蚁用了两种硬负载 F5 或是 LVS。 通过简略的4层代理，咱们能够把服务部署在代理的前面，服务与服务之间通过代理相互拜访，达到了跨机调用的目标 第一代注册核心 -- 硬负载到软负载的演变通过硬负载拜访的形式，一方面解决了服务之间相互调用的问题，部署架构也简略易懂；另一方面，在业务快速增长之后，却带来了肯定的问题： 单点的问题（所有调用都走F5的话，F5一旦挂了，很多服务会不可用）容量问题（F5承载的流量太高，自身会到一个性能瓶颈）这个时候，蚂蚁引进了阿里团体的一款产品叫ConfigServer，作为注册核心进行应用，这个注册核心的架构就和结尾提到的架构很像了，服务之间能够通过IP间接拜访，而升高了对负载平衡产品的强依赖，缩小了单点危险。 第二代注册核心 -- ScaleUp？ScaleOut？It's a problem然而，问题还在继续，那就是注册核心，自身是一个单点，那么，他就会持续遇到上文中所说的两个问题 单点危险（注册核心自身是单机利用）容量瓶颈（单台注册核心的连接数和存储数据的容量是无限的）解决的形式有两种 scale-up（淘宝）：通过减少机器的配置，来加强容量以及扛链接能力；同时，通过主-备这样的架构，来保障可用性scale-out（蚂蚁）：通过分片机制，将数据和链接均匀分布在多个节点上，做到程度拓展；通过分片之后的备份，做到高可用蚂蚁和淘宝走了两条不同的路，也推动了蚂蚁前面演进出一套独立的生态系统 蚂蚁的演进架构如下，产生了两种不同的利用节点 session节点，专门用来抗链接应用，自身无状态能够疾速扩大，单机对资源的占用很小data节点，专门用来存储数据，通过分片的形式升高单个节点的存储量，管制资源占用第五代注册核心 -- Meta节点的诞生下面的架构曾经很合乎目前支流的分布式架构了，然而在运维过程中，产生了一系列问题，比方 所有data都是分布式的，data之间的服务发现须要通过启动时给定一个配置文件，这样就和规范运维脱钩data节点的高低线须要去及时批改配置文件，否则集群重启会受到影响分布式存储一致性问题，每次迭代公布，须要锁定paas平台，避免节点变动带来的不统一所有这些问题的产生，咱们发现能够引入一个元数据管理核心（Meta）节点来，解决对data和session治理的问题，data和session通过4层负载或是7层负载对meta拜访即可. 比照业界的解决方案，都有相似的模型，比方HDFS的Name Node、Kafka依赖于ZK，Oceanbase依赖于RootServer 或者 配置核心Apollo依赖于Euraka。 Meta节点的呈现，缓解了手工运维注册核心的瓶颈，然而，仍然没有从根本上解决问题，那么问题在哪里？详见下文剖析。 第六代注册核心 -- 面向运维的注册核心上文说道，Meta节点的呈现，承接了Data以及Session之间服务发现的问题，然而，丛云未测来讲，还是有很多问题解决不了，比方 Data节点的公布在数据量大的前提下，仍然是个痛点Session节点的新加节点上，可能很久都没有流量等等，对于这些问题，在SOFARegistry5.x的根底上，咱们疾速迭代了6.0版本，次要是面向运维的注册核心。 Data节点公布难的问题，说到底是一个影响范畴的问题，如何管制繁多data节点公布或者挂掉对数据的影响面，是解决问题的根源，这里咱们采纳了两个措施 改良数据存储算法（consistent-hash -> hash-slot）利用级服务发现存储算法的演进之前咱们应用了一致性hash的算法，如下图所示，每一个节点承载一部分数据，通过是存储进行hash运算，算出存储内容的hash值，再计算出hash值落在哪一个data所负责的存储区间，来存储数据。 当data节点宕机或者重启时，由下一个data节点接管宕机节点的数据以及数据的拜访反对。 这样依赖，数据迁徙的粒度只能以单个data节点所存储的数据为单位，在数据量较大（单节点8G）的状况下，对数据的重建有肯定的影响，而且，在data间断宕机的状况下，可能存在数据失落或是不统一的场景。 改良后的算法，咱们参考了Redis Cluster的算法机制，应用hash slot进行数据分片 这样，在data公布过程中，能够控制数据的迁徙以slot为单位（单个data节点多个slot，可配置） 同时，为了解决迁徙或是宕机期间，数据写入不统一的场景，咱们引入了数据回放的弥补机制，data在promotion为slot的master之后，会被动地去和所有的session实现一次数据比对/校验，增量同步新增数据 利用级服务发现利用级服务发现是为了解决数据存储量大的问题，因为篇幅起因，这里略过不表 开源SOFARegistry从我的项目晚期就开始了开源的过程，与目前支流的注册核心的比照如下 ...

作者简介：冯泳（花名鹿惊），资深技术专家，领有西北工业大学计算机科学博士学位，在高性能计算，大数据和云计算畛域领有十多年的设计开发教训，专一于调度，资源和利用治理畛域。也深度参加相干开源我的项目的开发和商业化，例如 OpenStack, Mesos, Swarm, Kubernetes, Spark 等，曾在 IBM 领导过相干的开发团队。前言在云计算畛域如果还有人没听过 Kubernetes，就如同有人不晓得重庆火锅必须有辣椒。Kubernetes 曾经像手机上的 Android，笔记本上的 Windows 一样成为治理数据中心事实上的规范平台了。围绕着 Kubernetes，开源社区构建了丰盛的技术生态，无论是 CI/CD、监控运维，还是利用框架、平安反入侵，用户都能找到适宜本人的我的项目和产品。可是，一旦将场景扩大到多集群、混合云环境时，用户可能依赖的开源技术就比比皆是，而且往往都不够成熟、全面。 为了让开发者、用户在多集群和混合环境下也能像在单个 Kubernetes 集群平台上一样，应用本人相熟的开源我的项目和产品轻松开发性能，RedHat 和蚂蚁、阿里云独特发动并开源了 OCM（Open Cluster Management）旨在解决多集群、混合环境下资源、利用、配置、策略等对象的生命周期治理问题。目前，OCM 已向 CNCF TOC 提交 Sandbox 级别我的项目的孵化申请。 我的项目官网：https://open-cluster-management.io/ 多集群治理倒退历史让咱们把工夫拉回到几年前，当业界关注/争执的焦点还在 Kubernetes 是否生产级可用的时候，就呈现了最早一批登陆“多集群联邦“技术的玩家。它们大都是体量上远超均匀水准的 Kubernetes 实际先驱，从最早 Redhat、谷歌入场做了 KubeFed v1 的尝试，再到起初携手 IBM 吸取经验又推出 KubeFed v2。除了这些大型企业在生产实践 Kuberentes 的场景中摸索多集群联邦技术，在商业市场上，各个厂商基于 Kubernetes 包装的服务产品也大多经验了从单集群产品服务到多集群状态、混合云场景进化的过程。其实，无论是企业本身还是商业用户都有共性的需要，聚焦在以下几个方面： 多地区问题：当集群须要在异构基础设施上或者横跨更广地区进行部署 Kubernetes 集群依赖 etcd 作为数据长久层，而 etcd 作为分布式系统对系统中各个成员之间的网络提早上有要求，对成员的数量也有一些限度，尽管在提早可能容忍的状况下能够通过调整心跳等参数适配，然而不能满足跨国跨洲的全球性部署需要，也不能保障规模化场景下可用区的数量，于是为了让 etcd 至多能够稳固运行，个别会按地区将 etcd 布局为多个集群。此外，以业务可用和安全性为前提，混合云架构越来越多地被用户承受。逾越云服务提供商很难部署繁多 etcd 集群，随之对应的，Kubernetes 集群也被决裂为多个。当集群的数量逐步增多，管理员疲于应答时，天然就须要一个聚合的管控零碎同时治理协调多个集群。 规模性问题：当单集群规模性遇到瓶颈 诚然，Kubernetes 开源版本有着显著的规模性瓶颈，然而更蹩脚是，咱们很难真正量化 Kubernetes 的规模。社区一开始提供了 kubemark 套件去验证集群的性能，可是事实很骨感，kubemark 所做的事件基于局限于在不同节点数量下重复对 Workload 进行扩缩容调度。可是实际中造成 Kubernetes 性能瓶颈的起因简单、场景泛滥，kubemark 很难全面主观形容多集群的规模性，只能作为十分粗粒度下的参考计划。起初社区反对以规模性信封来多维度掂量集群容量，再之后有了更高级的集群压测套件 perf-tests。当用户更清晰地意识到规模性的问题之后，就能够依据理论场景（比方 IDC 规模、网络拓扑等）提前布局好多个 Kubernetes 集群的散布，多集群联邦的需要也随之浮出水面。 ...

01 引言-TLS 1.3 协定及 SM 算法说起 TLS，大家肯定不会生疏，TLS 能够说是整个互联网安全的基石，保障着咱们的通信数据的平安。自从 2014 年 Heartbleed 破绽被发现以来，网络安全受人关注的水平越来越高，出于更平安更快捷的需要，TLS 1.3 协定也随之被提出，其相应的 RFC 于 2018 年正式公布。随着网络安全越来越受到重视，平安策略也逐渐回升到国家策略的高度，国家明码局在 2010 年底颁布了我国自主研制的“椭圆曲线公钥明码算法”（SM2 算法），并随后陆续公布了国密算法 SM1-SM9（SM 代表商密的拼音大写）。明天咱们要分享的货色，就和 TLS 1.3 及国密无关。 首先先让大家对这两者之间的关系有一个根本的概念，咱们以一个典型的 TLS 1.2 中的密钥套件为例： 对应到咱们的国密的算法上，则各个算法对应的套件如下： 1、密钥替换算法：ECC-SM2，ECDHE-SM2（这里先不具体开展，只简略介绍一下，国密的密钥替换算法基于以后的椭圆曲线算法设计了两种专门的算法，而对应的曲线则是 SM2 曲线）； 2、数字签名算法：SM2（SM2 既是签名算法的名称，同时在椭圆曲线算法中对应的曲线名也叫 SM2，有的博客文档里也将密钥替换算法称作 SM2，读者请留神不要混同）； 3、对称加密算法：SM4； 4、hash 算法：SM3。 也就是说，国密局针对平安握手各个阶段所须要的算法都出台了一份自主可控的算法。 02 why 国密？why not 国密？先说说为什么要用国密，国密算法作为国密局的主力产品，必定是在很多中央有劣势的，先来总结下国密的典型劣势： 1、更平安：SM2 作为一种 ECC 算法（256 位）的安全性是要高于 2048 位的 RSA 的。同时 SM3 的摘要长度为 256 bit，平安强度也是要高于过后支流的 MD5 算法及 SHA1 算法的。 2、更疾速：在通信过程中，256 位的 SM2 算法相比于 2048 位的 RSA 算法（国密算法在设计时，RSA2048 是支流签名算法，所以这里暂不探讨ECDSA等算法），能够传输更少的数据，也就意味着更少的传输工夫，并且在实践上来说，SM2 签名算法的计算速度是要快过 RSA2048 不少的。 ...

Service Mesh 是当今云原生的要害局部，蚂蚁曾经在生产环境实现了大规模的落地，然而业界整体 Service Mesh 革新水平还不高。其中安稳的进行 Mesh 化革新是能够对已上线的业务进行 Mesh 化革新的前提，在安稳革新过程中，协定的反对又是最根底的局部。MOSN 提供的多协定扩大开发框架旨在升高应用公有协定的场景进行 Mesh 化革新的老本，帮忙业务疾速落地。MOSN 是蚂蚁自研的一款高性能网络代理，次要用于 Service Mesh 的数据面 Sidecar。Service Mesh，是近几年来云原生方向比拟热门的话题，其宗旨就是构建一个基础设施层，用来负责服务之间的通信。次要就是有一个和服务利用独特部署的 Sidecar 来实现各种中间件的根底能力，实现基础设施的标准化、和业务逻辑解耦，做到业务无感知的根底能力疾速演进。目前国内很多公司都开始拥抱 Service Mesh，和蚂蚁单干的一些企业，如中信银行、江西农信等也基于 MOSN 实现了 Mesh 化的革新。 Service Mesh 架构的目标就是为了升高基础设施革新降级对业务造成的影响，然而如何平滑的从传统微服务架构转向 Service Mesh 架构也是一个十分有挑战的工作，这里波及的细节很多，然而无论如何有一个最根底的问题就是咱们在进行灰度 Mesh 化革新的时候，曾经 Mesh 化的节点须要能和没有 Mesh 化的节点维持失常通信。而不同的公司抉择的通信协议都有所不同，这就间接导致在技术选型的时候，抉择的 Sidecar 须要可能反对所应用的协定。一些受到广泛应用的协定可能还会被陆续的反对，而有的协定可能还是公司本人定制的，因而不可避免的是须要基于 Sidecar 的扩大能力，进行二次开发以反对公有的协定。 多协定扩大框架谈到 Service Mesh 的 Sidecar，就不得不提到 Envoy，这是一款被广泛应用的 Service Mesh Sidecar 代理。Envoy 的扩大框架反对开发者进行二次开发扩大，其中 Envoy 目前反对的不少协定就是基于其扩大框架开发实现的。在 Envoy 的扩大框架下，要扩大一个协定能够参考 Envoy 中 HTTP 协定解决的流程，包含 4 层 Filter 实现编解码局部与 Connection Manager 局部，在 Connection Manager 的根底上再实现 7 层的 Filter 用于反对额定的业务扩大、路由的能力、和 Upstream 的连接池能力。能够看到一个协定解决的流程简直是贯通了各种模块，实现一个协定扩大老本还是比拟高的。 ...