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 的连接池能力。能够看到一个协定解决的流程简直是贯通了各种模块，实现一个协定扩大老本还是比拟高的。 ...

摘要： 蚂蚁金服开源也不只是 SOFA 中间件框架，未来会开源更多的东西，包括 AI 方面的一些技术，也希望整个社区能够多关注蚂蚁金服在开源上面未来的举措。本文转载自微信公众号：Linux中国，原作者：王兴宇 近日，技术媒体Linux中国的创始人王兴宇对蚂蚁金服SOFA开源负责人鲁直，就SOFA 5、ServiceMesh、Serverless、Seata等技术内容进行了探讨，以下为专访文章。 虽然我和鲁直在微信上已经联系很久了，但这还是第一次见面。交谈中，我了解到鲁直是2009 年加入阿里巴巴工作，已经有十年了。刚开始是在1688.COM 做业务系统，对中间件技术非常感兴趣，也会经常研究各种中间件的实现和功能。后来在 2013年时，为了更深入地学习研究中间件框架，转到了蚂蚁金服中间件团队，从那个时候开始就一直在做 SOFA。 目前鲁直在SOFA的团队主要负责的工作包括几个部分。其中一个主要部分就是 SOFA 开源相关的工作。SOFA 的产品体系非常广，包括已经对外开源的部分、内部整个微服务体系，以及 SOFA 框架等等——而这些开源相关的工作主要是由鲁直负责推动的。 当然，作为技术负责人，鲁直既要带技术团队也要做技术工作。谈及这一点，鲁直说： “我觉得做技术管理，跟普通的管理不太一样，因为技术管理最重要的一个点是除了管理之外，还要保持一定的技术判断力和敏锐度。对一些新技术，包括团队中遇到一些重大的技术问题，你都要有一些方向性的判断。虽然最后不一定是你具体解决的，但是在整个团队的技术攻坚和技术选型上，要一起确立方向。” 我以前也做过十余年的技术管理，我很能够感受这种情况，重大问题技术负责人更要迎难而上。 SOFA 5 落子 Service Mesh就我了解的情况，现在 SOFA 已经发展到了 SOFA5 了。在 SOFA4阶段，主要的任务是将开源体系捋清楚了，然后开始按步骤地开源；到现在发展到了 SOFA5。我想知道从 SOFA4 发展到 SOFA5，是什么让蚂蚁金服中间件团队判断 SOFA4 的阶段性目标已经达成，可以迈进到新的 SOFA5 阶段了呢？ “从整个业界趋势上来讲，SOFA4 的架构相对来说还是偏传统一些，更多是对我们之前的技术框架的整理和梳理。在这个阶段，SOFA 的代码经过了非常多的优化和重构，才达到了对外开源的要求，从而 SOFA 走上了开源核心的模式，逐步分阶段的将各个部分进行了开源。”鲁直讲到，“但是，从我们对业界的整体判断上来说，未来无疑是云的时代，所以说要考虑怎么让所有的业务系统能够提供云的能力，比如说 Serverless。” 接着这个话题，鲁直讲了他对云计算的理解：“一方面云计算肯定要为整个业务的发展提供更加方便的基础资源，可以不用去关心底层的基础设施。Serverless字面的意思就是说‘无服务器’——我不用关心服务器怎么来的，不用关心基础设施，只要关心业务代码就可以了。那反过来对于云服务商来说，经过了这一层抽象，其资源利用率会更高，可以有更多的利润空间，这是一个双赢的局面。对于用户来讲，这种好处是实实在在的，可以更少关注基础设施，只关心代码就可以了。” “我们希望在 SOFA5 的方向上，在这个新的迭代中，去让业务——包括让未来我们开源出来各种功能、各样服务模式——都更多地去关心自己的业务代码，而不用再过多地关心基础设施。”鲁直说， 在 SOFA5 中，一个重要的方向就是 Service Mesh这个方向，这将是 SOFA5 中非常重要的特性。鲁直强调了其对 Service Mesh 技术的看好：“我认为 Service Mesh 是迈向未来往前走的非常关键的一步，让业务不用再关心基础设施。通过 Service Mesh，我们可以将很多技术能力直接放到基础设施里面，而业务可以不用感知到这一层。原来可能需要花几个小时或者更多的时间解决的基础设施问题，现在可以通过 Service Mesh解决掉。” ...

**2019新春支付宝红包技术大揭秘在线峰会将于03-07日开始，点击这里报名届时即可参与大牛互动。**SOFAScalable Open Financial Architecture 是蚂蚁金服自主研发的金融级分布式中间件，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。SOFATracer 是一个用于分布式系统调用跟踪的组件，通过统一的 TraceId 将调用链路中的各种网络调用情况以日志的方式记录下来，以达到透视化网络调用的目的，这些链路数据可用于故障的快速发现，服务治理等。本文为《剖析 | SOFATracer 框架》第二篇。《剖析 | SOFATracer 框架》系列由 SOFA 团队和源码爱好者们出品，项目代号：<SOFA:TracerLab/>，目前领取已经完成，感谢大家的参与。SOFATracer：https://github.com/alipay/sof…0、前言在《蚂蚁金服分布式链路跟踪组件 SOFATracer 总览|剖析》一文中已经对 SOFATracer 进行了概要性的介绍。从对 SOFATracer 的定义可以了解到，SOFATracer 作为一个分布式系统调用跟踪的组件，是通过统一的 TraceId 将调用链路中的各种网络调用情况以数据上报的方式记录下来，以达到透视化网络调用的目的。本篇将针对SOFATracer的数据上报方式进行详细分析，以帮助大家更好的理解 SOFATracer 在数据上报方面的扩展。1、Reporter 整体模型本节将对 SOFATracer 的 Report 模型进行整体介绍，主要包括两个部分：1、Reporter 的接口设计及实现；2、数据上报流程。1.1、Reporter 的接口设计及实现数据上报是 SofaTracer 基于 OpenTracing Tracer 接口扩展实现出来的功能；Reporter 实例作为 SofaTracer 的属性存在，在构造 SofaTracer 实例时，会初始化 Reporter 实例。1.1.1、Reporter 接口设计Reporter 接口是 SOFATracer 中对于数据上报的顶层抽象，核心接口方法定义如下：//获取 Reporter 实例类型String getReporterType();//输出 spanvoidreport(SofaTracerSpan span);//关闭输出 span 的能力void close(); Reporter 接口的设计中除了核心的上报功能外，还提供了获取 Reporter 类型的能力，这个是因为 SOFATracer 目前提供的埋点机制方案需要依赖这个实现。1.1.2、Reporter 接口实现Reporter 的类体系结构如下：Reporter 的实现类有两个，SofaTracerCompositeDigestReporterImpl 和 DiskReporterImpl ：SofaTracerCompositeDigestReporterImpl：组合摘要日志上报实现，上报时会遍历当前 SofaTracerCompositeDigestReporterImpl 中所有的 Reporter ，逐一执行 report 操作；可供外部用户扩展使用。DiskReporterImpl：数据落磁盘的核心实现类，也是目前 SOFATracer 中默认使用的上报器。1.2、数据上报流程分析数据上报实际都是由不同的链路组件发起，关于插件扩展机制及埋点方式不是本篇范畴，就不展开了。这里直接来看数据上报的入口。在 Opentracing 规范中提到，Span#finish 方法是 span 生命周期的最后一个执行方法，也就意味着一个 span 跨度即将结束。那么当一个 span 即将结束时，也是当前 span 具有最完整状态的时候。所以在 SOFATracer 中，数据上报的入口就是 Span#finish 方法，这里贴一小段代码：//SofaTracerSpan#finish@Overridepublic void finish(long endTime) { this.setEndTime(endTime);//关键记录:report spanthis.sofaTracer.reportSpan(this);SpanExtensionFactory.logStoppedSpan(this);}在 finish 方法中，通过 SofaTracer#reportSpan 将当前 span 进行了上报处理。以这个为入口，整个数据上报的调用链路如下图所示：整个上报调用流程其实并不是很难，这里留两个问题：如何构造 clientRportor 和 serverReporter 的，依据是什么？摘要日志和统计日志是怎么落盘的？第一个问题会在插件埋点解析篇中给出答案；第二个问题下面来看。2、日志落盘前面已经提到，SOFATracer 本身提供了两种上报模式，一种是落到磁盘，另外一种是上报到zipkin。在实现细节上，SOFATracer 没有将这两种策略分开以提供独立的功能支持，而是将两种上报方式组合在了一起，然后再通过配置参数来控制是否进行具体的上报逻辑，具体参考下图：本节将来剖析下日志落盘的实现细节。日志落盘又分为摘要日志落盘 和 统计日志落盘；摘要日志是每一次调用均会落地磁盘的日志；统计日志是每隔一定时间间隔进行统计输出的日志。2.1、摘要日志落盘摘要日志落盘是基于 Disruptor 高性能无锁循环队列实现的。SOFATracer 中，AsyncCommonDigestAppenderManager 类对 disruptor 进行了封装，用于处理外部组件的 Tracer 摘要日志打印。关于 Disruptor 的原理及其自身的事件模型此处不展开分析，有兴趣的同学可以自行查阅相关资料。这里直接看下 SOFATracer 中是如何使用 Disruptor 的。2.1.1、消息事件模型SOFATracer 使用了两种不同的事件模型，一种是 SOFATracer 内部使用的 StringEvent，一种是外部扩展使用的 SofaTacerSpanEvent。详见：SofaTracerSpanEvent & StringEvent 。2.1.2、Consumer 消费者Consumer 是 AsyncCommonDigestAppenderManager 的内部类；实现了 EventHandler 接口，这个 Consumer 作为消费者存在，监听事件，然后通过 TraceAppender 将 span 数据 flush 到磁盘。详见：AsyncCommonDigestAppenderManager2.1.3、Disruptor 的初始化Disruptor 的构建：在 AsyncCommonDigestAppenderManager 的构造函数中完成的。//构建disruptor，使用的是 ProducerType.MULTI//等待策略是 BlockingWaitStrategy，考虑到的是CPU的使用率和一致性disruptor = new Disruptor<SofaTracerSpanEvent>(new SofaTracerSpanEventFactory(), realQueueSize, threadFactory, ProducerType.MULTI, new BlockingWaitStrategy());异常处理：如果在消费的过程中发生异常，SOFATracer 将会通过自定义的 ConsumerExceptionHandler 异常处理器把异常信息打到 tracer-self.log 中。对于打印相关的参数条件设定，比如是否允许丢弃消息、是否记录丢失日志的数量、是否记录丢失日志的 TraceId 和 RpcId、丢失日志的数量达到某阈值进行一次日志输出等。2.1.4、启动 DisruptorDisruptor 的启动委托给了 AsyncCommonDigestAppenderManager#start 方法来执行。public void start(final String workerName) {this.threadFactory.setWorkName(workerName); this.ringBuffer = this.disruptor.start();}查看调用栈，看下 SOFATracer 中具体是在哪里调用这个 start 的：CommonTracerManager : 这里面持有了 AsyncCommonDigestAppenderManager 类的一个单例对象，并且在 static 静态代码块中调用了 start 方法；这个用来输出普通中间件日志。SofaTracerDigestReporterAsyncManager：这里类里面也是持有了AsyncCommonDigestAppenderManager 类的一个单例对像，并且提供了getSofaTracerDigestReporterAsyncManager 方法来获取该单例，在这个方法中调用了 start 方法；该对象用来输出摘要日志。2.1.5、发布事件发布事件，也就意味着当前需要产生一个 span 记录，这个过程也是在 finish 方法的调用栈中，也就是上图中DiskReporterImpl#digestReport 这个方法。AsyncCommonDigestAppenderManager asyncDigestManager = SofaTracerDigestReporterAsyncManager.getSofaTracerDigestReporterAsyncManager();// …asyncDigestManager.append(span);// …这里将 span 数据 append 到环形缓冲区，根据 AsyncCommonDigestAppenderManager 的初始化属性，如果允许丢弃，则使用 tryNext 尝试申请序列，申请不到抛出异常；否则使用 next() 阻塞模式申请序列。下面是一个简易的模拟图：2.1.6、小结摘要日志的落盘依赖于 Disruptor 的事件模型，当 span#finish 方法执行时，触发 SofaTracer 的 report 行为；report 最终会将当前 span 数据放入 Disruptor 队列中去，发布一个 SofaTracerSpanEvent 事件。Disruptor 的消费者 EventHandler 实现类 Consumer 会监听当前队列事件，然后在回调函数 onEvent 中将 span 数据刷新到磁盘中。2.2、统计日志落盘实现统计日志的作用是为了监控统计使用，其记录了当前跨度的调用次数、执行结果等数据。统计日志是每隔一定时间间隔进行统计输出的日志，因此很容易想到是使用定期任务来执行的。这里同样来跟踪下统计日志打印的方法调用过程。2.2.1、统计日志的调用链路AbstractSofaTracerStatisticReporter 的 doReportStat 方法是个抽象方法，那这里又是与插件扩展部分联系在一块的：可以看到 AbstractSofaTracerStatisticReporter 的实现类均是在 SOFATracer plugins 包下，也就是说统计日志打印需要由不同的扩展插件来定义实现。但是实际上不同的插件在重写 doReportStat 方法时也并非是直接将 span 数据 flush 到磁盘的，而是将 SofaTracerSpan 转换成 StatMapKey 然后塞到了 AbstractSofaTracerStatisticReporter 中的一个 map 结构对象中。具体细节详见：AbstractSofaTracerStatisticReporter#addStat。2.2.2、统计日志的打印模型前面提到，统计日志的落盘具有一定的周期性，因此在统计日志落盘的设计上，SOFATracer 没有像摘要日志落盘那样依赖于 Disruptor 来实现。下面先通过一张简单的结构图来看下摘要日志的工作模型：xxxxxStatReporter : 插件扩展方实现的统计日志 Reporter 类，重写了 doStatReport 和 print 两个方法。AbstractSofaTracerStatisticReporter ： 用于扩展的抽象类，xxxxxStatReporter 就是该类的子类；AbstractSofaTracerStatisticReporter 在其构造函数中，通过 SofaTracerStatisticReporterCycleTimesManager 将当前 statReporter 注册到 SofaTracerStatisticReporterManager 中，统一存放在 statReporters 集合中。SofaTracerStatisticReporterManager ： 统计日志 reporter 管理器，所有插件扩展的 reporter 都会被注册到这个manager 类里面来。其内部类 StatReporterPrinter 实现了runnable 接口，并在 run 方法中遍历 statReporters，逐一调用 print 方法将数据刷到磁盘中。SofaTracerStatisticReporterManager 在构造函数中初始化了任务执行的周期、ScheduledExecutorService 实例初始化，并且将 StatReporterPrinter 提交到定时任务线程池中，从而实现了周期性输出统计日志的功能。3、上报 Zipkin前面对 SOFATracer 中的数据落盘进行了分析，最后再来看下 SOFATracer 中是如何把数据上报至 zipkin 的。3.1.1、上报 zipkin 的流程接着上面的分析，SOFATracer 中的数据上报策略是以组合的形式共存的，这里可以结合 第2节的第一张图 来看。这里先给出 zipkin 上报的流程，然后再结合流程展开分析：在SofaTracer#reportSpan 中有一个方法是 invokeReportListeners；该方法的作用就是遍历当前所有的SpanReportListener 实现类，逐一回调 SpanReportListener 的 onSpanReport 方法。ZipkinSofaTracerSpanRemoteReporter 是 sofa-tracer-zipkin-plugin 插件中提供的一个实现了 SpanReportListener 接口的类，并在 onSpanReport 回调函数中通过 zipkin2.reporter.AsyncReporter 实例对象将 span 数据上报至 zipkin。虽然 SOFATracer 和 zipkin 均是基于 OpenTracing 规范，但是在具体实现上 SOFATracer 做了很多扩展，因此需要通过一个 ZipkinV2SpanAdapter 将 SofaTracerSpan 适配成 zipkin2.Span。zipkin2.reporter.AsyncReporter 是 zipkin 提供的一个数据上报抽象类，默认实现是 BoundedAsyncReporter，其内部通过一个守护线程 flushThread，一直循环调用 BoundedAsyncReporter 的 flush 方法，将内存中的 span 信息上报给 zipkin。3.1.2、对非 SpringBoot 应用的上报支持上报 zipkin 的能力做过一次改动，主要是对于在非SpringBoot应用(也就是Spring工程)的支持，具体参考 issue:建议不用spring boot也可以使用sofa-tracer并且上报zipkin 。对于 SpringBoot 工程来说，引入 tracer-sofa-boot-starter 之后，自动配置类 SofaTracerAutoConfiguration 会将当前所有 SpanReportListener 类型的 bean 实例保存到 SpanReportListenerHolder 的 List 对象中。而SpanReportListener 类型的 Bean 会在 ZipkinSofaTracerAutoConfiguration 自动配置类中注入到当前 Ioc 容器中。这样 invokeReportListeners 被调用时，就可以拿到 zipkin 的上报类，从而就可以实现上报。对于非 SpringBoot 应用的上报支持，本质上是需要实例化 ZipkinSofaTracerSpanRemoteReporter 对象，并将此对象放在 SpanReportListenerHolder 的 List 对象中。所以 SOFATracer 在 zipkin 插件中提供了一个ZipkinReportRegisterBean，并通过实现 Spring 提供的 bean 生命周期接口 InitializingBean，在ZipkinReportRegisterBean 初始化之后构建一个 ZipkinSofaTracerSpanRemoteReporter 实例，并交给SpanReportListenerHolder 类管理。3.1.3、Zipkin 上报案例及展示关于 SpringBoot 工程使用 zipkin 上报案例请参考：上报数据到 zipkin关于 spring 应用中使用 zipkin 上报插件请参考：tracer-zipkin-plugin-demoServices 展示链路依赖展示4、总结4.1、SOFATracer 在数据上报模型上的考虑了解或者使用过 SOFATracer 的同学应该知道， SOFATracer 目前并没有提供数据采集器和 UI 展示的功能；主要有两个方面的考虑：SOFATracer 作为 SOFA 体系中一个非常轻量的组件，意在将 span 数据以日志的方式落到磁盘，以便于用户能够更加灵活的来处理这些数据UI 展示方面，SOFATracer 本身基于 OpenTracing 规范实现，在模型上与开源的一些产品可以实现无缝对接，在一定程度上可以弥补本身在链路可视化方面的不足。因此在上报模型上，SOFATracer 提供了日志输出和外部上报的扩展，方便接入方能够足够灵活的方式来处理上报的数据。4.2、文章小结通过本文大家对 SOFATracer 数据上报功能应该有了一个大体的了解，对于内部的实现细节，由于篇幅和文章阅读性等原因，不宜贴过多代码，希望有兴趣的同学可以直接阅读源码，对其中的一些细节进行了解。数据上报作为 SOFATracer 核心扩展能力之一，虽不同的上报途径对应不同的上报模型，但是整体结构上还是比较清晰的，所以理解起来不是很难。 文中提到的链接：Disruptor ：https://github.com/LMAX-Excha…SofaTracerSpanEvent：https://github.com/alipay/sof…StringEvent：https://github.com/alipay/sof…AsyncCommonDigestAppenderManager：https://github.com/alipay/sof…[AbstractSofaTracerStatisticReporter#addStat]：https://github.com/alipay/sof…issue:建议不用spring boot也可以使用sofa-tracer并且上报zipkin：https://github.com/alipay/sof…上报数据到 zipkin：https://www.sofastack.tech/so…tracer-zipkin-plugin-demo：https://github.com/glmapper/t…点击阅读更多，查看更多详情 ...