开发者学堂课程【2022阿里云云原生中间件开发者大会集锦：OpenSergo 社区建设进展和近期规划】学习笔记，与课程紧密连接，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1053/detail/15293
OpenSergo 社区建设进展和近期规划
内容介绍：
一、背景介绍
二、OpenSergo 进展
三、OpenSergo 里程碑
四、OpenSergo 社区
本课程主要包括 OpenSergo 社区建设进展和近期规划。
一、背景介绍
首先介绍下 OpenSergo 的背景。
1.服务治理会成为企业上云下一阶段诉求
随着企业云原生化进入深水区，企业微服务上云部署之后，微服务治理问题逐步成为企业下一阶段的诉求。
（1）、开源社区反馈
比如之前举办的容器的 workshop 北京站，深圳站有70%到80%的客户对微服治理的这个话题比较感兴趣，是最感兴趣的话题。
然后看一下开源社区的反馈，比如说git HUB上面相关项目的一些反馈，还有就是git HUB 上面一些新兴的这个趋势来看，微服务治理是容器用户，微服务用户最感兴趣的话题。
（2）、成为企业下一阶段的诉求过程
微服务治理问题逐步成为企业下一阶段的诉求。第一阶段是云上部署的机器，通过ecs方式来搬上云，以机器为核心部署起来。第二阶段是云原生部署。用户会把自己的业务做一些云原生化的一些部署，就是容器化的一些部署，然后以容器为核心在云上跑起来，然后接下来就是用户就会对业务做一些微服务化改造，以便更敏捷的开发和迭代，这样的话，以应用为核心，就会在云端部署起来。
接下来，认为下一阶段是服务治理的阶段。用户想要在效率上，在开发效率和维护效率上得到提升，在稳定性上得到提升，这样的话以业务为核心的方式来把整个微服务玩得转。
2. 开源领域服务治理的现状
（1）、方案
然后看一下开源领域服务治理的现状，认为在目前开源领域服务治理是没有一个统一标准的方案的，比如作为一个微服务的使用方，可以再在工作负载上可以选择容器和 ecs，再语言上可以选择JAVA，gorun等等，
再框架上有 spring cloud ,dobbu ,kratos ,kitex ,grpc, dobbu-go 这些方式可以选。在接受服务治理的方式上，可以用 JAVA agent 的方式来做治理，也可以用service mesh的方式来做治理。也有各个语言的 SDK 来接入服务治理的这个体系中来。
（2）、对企业
那对于企业来讲。每套的这种选型都会有不同的抽象和概念。比如double的这个Service 和 spring cloud对应的那个http no point，是完全不同的理解模型。他的服务治理的这个方法和能力也不一样，比如JAVA agent可能就是支持JAVA。Service smash的话就支持多语言一点，Service smash不能侵入到内部的一些信息等等，所以最终导致的这个碎片化的这个结果会让业务开发人员难以理解，服务治理这个整体的概念。在企业内部服务治理就会比较难落地。
（3）、对业务开发者
对业务开发者来说，服务治理带来的这种复杂的理解成本。会让她难落地。另外一点就是企业内部自建在这种服务治理的这个平台，或者自己搞的一些JAVA agent，或者SDK等等，他会要求业务开发者在适当的地方给流量打标等等，比如要做一个全能灰度，需要在网关那边给流量打标，需要在中间的流量路径上面根据一些标记，根据流量的标来做灰度等等，那他就会是必和业务代码耦合。导致这个业务开发同学还要兼顾基础认知的认知成本。
还有一点就是对于业务开发者而言。现有的服务治理平台会限制一些新技术的选型和尝试，比如站在业务开发者的角度，企业内部已经有一套微服务治理平台。现在已经有一个JAVA的微服务的非常好，但是现在想用一套go long来写的微服务，想要运行会go lang写的微服务，比如go lang grpc协议的微服务，那就需要去调研一下内部的微服务治理平台，支持不支持grpc，这样的话这种功能上的限制，就会限制一些新技术的选型和尝试。
（3）、中间件开发者的角度
再接下来就是站在中间件开发者的角度，中间件在企业当中落地，比如作为一个spring cloud或者dubbo的开发者，spring cloud dubbo要在企业当中落地，是必须要和现有的这个微服务里的基础知识来集成，比如和企业内部全链路灰度的平台去集成，这样需要对于一些企业来做一些特定的接入，定制化的开发等。这种定制化的开发第一是有很大的开发成本，第二是后续的维护也会比较麻烦，很难更新的迭代等等，所以新的中间件也会在企业其当中比较难落地。
3. OpenSergo 项目
基于刚刚的这些背景，推出了OpenSergo项目。核心是说，要构建一个开放的面向应用，贴近业务语义的服务体系，标准和参考实现。
（1）、对于业务开发者
对于业务开发者而言，是希望建立一套标准化的服务治理的spec和参考实现。这样的话对于业务开发者而言，写业务的同学能够更容易的把服务治理这个概念和能力，在项目当中落地，并且运用起来。而且现有的框架对接了OpenSergo之后，作为业务开发者，只需要关注应用的逻辑就可以，只需要关心业务的逻辑就可以。除了可以享受服务治理带来的好处以外，只需要关注业务的价值就可以。可以更专注的实现业务价值。另外一点就是无需担心服务治理带来的厂商锁定，原来的话，作为业务开发者，需要关注的是，如果用的是自建的服务治理平台，那他除了这个企业，有的人可能会比较少，如果用的是某个云厂商的服务治理平台，可能更多的是云厂商部署，所以推出了OpenSergo开放的标准，这样就可以跨云跨厂商来部署。
（2）、中间件开发者的角度
可然后接下来是从中间件开发者的角度来讲。从中间件开发者的角度来讲OpenSergo会更容易让中间件在企业当中落地，原来的话，中间件需要对接不同的微服务治理的系统，现在的话只需要对接一套spike就能够做到在各企业落地，中间件可以实现全链路的互通，比如grpc的流量到dubbo之后，除了要做一套协议的互通以外，下午他们之间可以互相认可彼此微服务治理规则，dubbo希望别人调的时候，是按照同AV的方式来调，或者是按照全链路灰度方式来调度。Grpc这边也一定要识别这种规则，不然就会出现流量的错乱，也希望业务开发者和中间件开发者能够参与进来OpenSergo微服务治理标准规则制定。能够使这套标准真正的给业界带来一些力上的提升。
（3）、OpenSergo
OpenSergo而言，希望的是，第一制定标准，建设这个服务治理的这个心智，让业务开发者，让中间件开发者意识到服务治理的这个模型是什么，然后另外一点就是能够让他们减轻各自的负担，包括认知负担和维护负担。然后OpenSergo会兼容多种服务治理方式，比如刚刚提到的JAVA agent，Service smash，还有一些就是各种SDK的模式等等，都会让他们介入到OpenSergo这套体系当中来。能够把现有的一些微服务框架很容易的接入，也能够让新的微服务框架按照OpenSergo的标准模式来治理。
4. OpenSergo 整体蓝图
接下来看一下OpenSergo整体蓝图。OpenSergo这个这边包含三个部分。第一部分就是标准，接下来就是sdk，再接下来就是各个框架和基础设施的集成。
于标准而言，这边最先开始的是流量治理标准，因为不管是全链路灰度，还是telementry优先，图测试其实都是流量治理的内涵，流量治理之后会希望流量防护，服务发现等等这些标准的置地。当然这些标准具体来说，会和对应的开源项目来做一定的这种合作和结合。真正的能够让用户用OpenSergo这个stack来描述自己的微服务架构。OpenSergo为了方便厂商的接入和基层的话，会提供JAVA，go等等语言的SDK，能够让他们集中的去接入。
当然，因为这个标准实际上是一个公开的标准，实际上是一个开放公开的标准，所以用户也可以自己去写一个SDK去接入，这边下载了第三方的sdk的范围。
然后接下来是各个框架的接入和集成，比如目前的话christ，spring cloud，阿里巴巴，cloudwego现在已经接入。Service smash和JAVA agent这种方式还在介入的过程中，所以目前微服务框架作为电路当中的主要参与者，是在积极对接。
另外一点就是整个微服务链路中的这个流量入口就是网关，也在这积极的推进省域网关和csp网关的对接。接下来就是流量入口里面也会有服务发现，配置管理等等，那也会去和注册中心，配置中心，消息队列，数据库，日志缓存等等基础设施去做一些对接。能够让用户按照一个标准化的方式，去管理注册中心，配置中心的这种模式。
然后OpenSergo作为一个标准的实现。有如下几个特征，第一个就是标准化的，会提供一个一致标准的微服务治理模型，这样的话，用户在上云和现有的项目维护的时候，就能够以标准化去维护，能够减轻用户上云维护成本。第二要是开放，支持多语言多框架的这个治理，也支持多种的这种治理模式，比如mesh ,java agent的治理模式等等。也是和业界共建这种开放的服务质量标准，比如哔哩哔哩，cloudwego ，快手，dubbo，dsfa ，shenyu网关等等都有一些合作来共建标准。另外就是希望这个标准能够给业界带来一些价值增量，第一就是减少微服务开发者在微服务里的这些治理负担，给服务开发者屏蔽治理能力上的差异，能够让微服务开发者专注于业务价值。
最后一点就是提供一个全方位全生命周期的服务治理标准。在各个微服的这个基础设施上，比如注册中心，配置中心，消息队列等等，会提供一些标准化的能力抽象。形成一个业务和基础知识之间的这个统一的标准界面。这样的话，就能够提供一个更加云原生化的这种模式。
5. 数据面多样化，控制面标准化
然后整体的趋势来看就是数据面多样化，控制面标准化。OpenSergo这边会提供一些管控面的实现，之间会有一段标准的spec，spec就是一套mesh down实现，具体的要接入这些spec。用Java的方式来接入，也可以用sdk的方式来接入，也可以用service mesh的方式来接入。
功能的话，因为目前聚焦于流量治理领域，所以有开发态的，比如流量契约，服务mock，开发环境隔离等等的一些功能，还有就是测试态进行压测，自动化回归等等。还有发布态的无损上下线，服务预热全链路灰度等等的能力。还有一些高可用范围内的一些离群摘除，限流量级，临近路由，就近路由等等，还有一些安全态的服务之间常见的健全服务，漏洞的防护，配置的健全等等的这些安全态的，这些都是一些常见的流量治理的领域的一些应用。
6. OpenSergo 架构图
OpenSergo在部署的时候的一些模式。
下图中间的话就是OpenSergo标准，标准的话包含流量治理标准，流量防护标准，可观测标准，服务发现标准等等，来作为一个流量标准放在中间，这样的话，对于管控面来讲用这个标准来管控各个微服务，比如说开源这边提供了OpenSergo的dashbaord，能够按照这个spec来治理这些服务，企业当然也可以根据这个标准来自建dashbaord，还有就是kuberntes cr，kuberntes的话，也可以基于kuberntes来做一些CR和crd的一些定义等等，来做一些这样的管控。
对于硬面的数据面而言。通过Java agent来治理这些服务。用Service smash来治理这些服务之外还在积极的推进开源框架的对接 ，Spring cloud阿里巴巴。Kratos，kitex目前都已经对接的差不多了，然后grpc和dubbo之类的这种对接正在推进当中。
二、OpenSergo 进展
OpenSergo进展，管控面上OpenSergo的dashbaord，目前已经开源，然后大家也可以下载使用。在git up下面就能找到，kuberntes cr定义这一块，正在积极推进的过程中。
OpenSergo标准的这一块的话，把数据的源数据标准已经抽象并整理成一种标准文档。但对于流量治理，流量防护，服务发现等等这些标准还正在积极推进当中。当然也会和一些相关的开源项目会有一些合作。比如流量防护就会和knuckles进行标准化的合作。服务发现就会和nacos做一些相关的标准化的合作，数据面对接的话spring cloud阿里巴巴，cratos，kitex等等这些框架我们基本上都已经是对接完成。
然后grpc和dubbo就像上面说的，正在对接的过程当中。
OpenSergo demo
下面就是一些demo的展示的截图，比如目前的话Kratos 和spring-cloud的对接。这是应用列表，
这是应用的一些详情，
然后接口的详情等等。
三、OpenSergo 里程碑
下面这是预计的一些里程碑，OpenSergo这边，分成每个q来划分里程碑，然后每个里程碑下面会有三个部分。分别是spec标准的制定，还有就是数据面的一些建设和管控面的一些建设，比如22年Q2会做一些流量治理的一些规范。Q3的话，会专注于服务发现等等基础设施的一些微服务的一些标准化和数据面建设。第四的话，会集中补足可观测性的一些能力。23年会做一些互联互通的一些尝试，能够让微服务之间提升性的操作过程。
四、OpenSergo 社区
下面看一看OpenSergo社区相关内容，OpenSergo社区的话，目前已经有一个官网，比如OpenSergo Quick Start这边的话，目前展示的是一个英文版的这个quick start，
然后也会有一些中文版的快速开始，能够让能够让您在本地快速的把OpenSergo跑起来。也能够通过各个方式来接入，用不同的框架来接入OpenSergo。
然后我们的开发团队会划分为三个角色。
第一个是 maintainer，也就是对开发团队进行演进和发展作出开发贡献的个人，比如完成了关键模块的设计于开发，持续的投入等等，有影响力等等。就会提升为maintainer。
然后 committer 的话，主要就是第一个就是持续的有hr和pr的贡献，也能够参与hr列表的维护。以及主要会议的讨论。当然参与knuckles也是一个方式。
Contributor 就是对 OpenSergo 有贡献的个人，就是推出pr并且被合并的贡献。
