开发者学堂课程【OpenSergo 即将发布 v1alpha1，定义微服务治理标准：OpenSergo 即将发布 v1alpha1,定义标准服务治理】学习笔记，与课程紧密连接，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1081/detail/15898
OpenSergo 即将发布 v1alpha1,定义标准服务治理
内容介绍：
一、从微服务治理到OpenSergo
二、OpenSergo流量路由、流控降级与容错v1alpha1标准介绍
三、Sentinel、SCA、Kratos即将全面支持OpenSergo标准
四、展望与总结
一、从微服务治理到 OpenSergo
（1）微服务架构中的新四大件
今天分享的一个主题是OpenSergo即将发布v1alpha1,定义标准服务治理。
首先是从微服务治理到OpenSergo。回顾软件技术的发展，从单体的应用逐渐演进到分布式应用，随着微服务理念的兴起，其实也让大规模、高并发、低延迟的分布式应用成为可能。
但其实都知道，微服务架构其实是一把双刃剑。然后随着微服务架构的复杂化，其实在大规模之下，再小的问题他都会牵一发而动全身，因此。
随着微服务架构的增长，如果不对微服务进行恰当的治理，其实微服务架构带来的效率稳定性相关的问题可能会远大于服务本身带来的一个价格红利。看一下传统的微服务治理的大家的认知
其实说传统微服务架构中，常常将服务调用中的各个角色分为四大块内容，也就是可以成为原来的一个微服务的四大件，可以看到是有服务提供者，服务消费者，注册中心以及监控。
但是随着分布式服务架构的不断演进，带来的诸多复杂的稳定性与易用性的问题。然后在这个过程中，其实单一的监控已经无法满足架构的演进。在现代微服务架构中，其实是需要一些手段来对复杂的微服务架构进行恰当的治理，微服务治理就是通过向流量控制、异常流量调度、数据库治理等技术手段来减少甚至避免发布中出现的一些问题来和管理大规模应用过程中遇到的一些稳定性的问题。微服务治理对微服务领域的中的组件进行恰当的治理。
来保证一个稳定性以及效率的一个问题来解决微服务架构规模复杂变大带来的一些效率与稳定性的问题。服务提供者、服务消费者、注册中心、服务治理。它构成了现代微服架构中的重要的几环，也就是微服务架构中的新四大件。其实可以看到，这个微服务治理的核心作用其实就是治理微服务领域中的各个组件来保证一个稳定性跟效率，还有成本的问题。
（2）微服务治理重要性
可以看到，随着微服务的一个深化，微服务治理是微服务发展过程中的一个必经之路，微服务架构越是复杂，对微服务自己的一个诉求也是刚需。
在企业内部往往存在着不同的语言不同通信协议的微服务。而这些异构化的架构也会导致在这里微服务的过程中业务开发者或者架构师，他们没有办法用统一的方式来对所有的服务进行管控，进行治理。同时，这类异构的架构其实会衍生出更加多的一些痛点。跟业界公司拜访客户的时候，其实都有跟他们交流服务治理，发现企业界对服务治理的能力和边界其实没有一个明确的认识，而不同的企业往往给出服务治理的定义，或者说他们服务治理的概念，其实都是不一致的。在交流过程中其实也发现就是说。
对于微服务治理这个概念的交流以及相关是概念的交流，就会造成很高的一个理解和沟通的成本，更不用说微服务治理能力的一个实施，那第二个就是说开源的微服务框架其实是非常多的，由于服务治理缺乏一些标准化的一些约定，举个例子，定义spring cloud的微服务接口跟double中定义的一些接口，它就没办法做到互通。没有办法进行统一的治理。
总而言之，就是的开发者没有办法通过统一的配置方式来对不同的架构、不同的语言的服务进行统一的治理把控。在这些过程中，其实总结来说就是说目前缺少真正面向业务，能够减轻认知负担的一个抽象与标准，以体校的稳定性为目的，以业务为核心的一套微服务治理的标准。开发者真正想要的可能就是一套简单的或者说指定服务间调用关系和配置规则的一套标准。
但是目前的现状，对业务的开发者来说，他们如果要探索微服务架构的实施，或者说实现微服务治理的能力，不仅需要了解不同微服务架构的一个部署架构，也需要了解不同服务治理方式的一个概念和能力的区别。在这个过程中，其实对认知的成本是非常高的。关于这些痛点的探索的过程中，其实也逐渐认识到一个标准的重要性。
(3)OpenSergo定位
因此OpenSergo在这样的过程中诞生的。
它的定位就是一套开放的、通用的、面向分布式应用，覆盖全链路异构化生态的一个服务治理标准，同时会提供一系列的参考实现。希望无论是针对spring cloud或者说double的服务链路，对其配置流量，比如说灰度隔离的一个规则，还是说针对一个go的rpc的服务进行流量控制。
又或者说是希望针对服务访问数据库进行自动熔断，都希望可以利用OpenSergo的标准来统一的进行配置。而使用者无需关注框架不同的声明式API以及其中互不兼容的一些配置格式的问题。因此这一块OpenSergo有四块，首先就是一个标准化，会基于业界服务治理的场景与实现来抽象成一套通用的、标准的、统一的服务协议以及YAML CRD标准配置进行管控，来降低用户上云同时进行微服务治理的维护的成本。
第二块其实想OpenSergo能够做到足够的通用，或者说面向全链路必须要实现全链路生态覆盖，因为对服务治理的使用都是端到端的，从最开始的流量入口到网关，到微服务，甚至到的数据层、存储层，比如像数据库或者说缓存，从服务发现到服务配置，在这每一个环节中，OpenSergo都会针对这些应用链路上的每一环进行抽象。针对其中的场景进行一个完整的覆盖。
然后同时实施的微服务，无论是Java的，甚至是go语言，Note.js，Rust或者说是其他的语言，无论是传统的微服务，还是说Mesh的架构，都希望可以用同一套标准的规范进行接入，来进行统一的服务治理，从而降低服务治理的维护的一个成本。最后一块也是保障OpenSergo的一个新鲜或者说活力的一个关键的一个点，它是一个开放的，通用的一个协议或者说标准。因此面向社区，多家社区共同合作。希望通过业界共建的方式来做到一套开放的标准。
（4）贯穿微服务领域的OpenSergo
其实大家应该知道，就是说希望用一套统一的标准来贯穿整个微服务领域，来做到统一的服务治理。
OpenSergo的标准其实是基于微服务治理中相关领域的一个实践与场景的抽象。可以看到，它覆盖了服务员数据，流量治理、服务容错、数据库缓存治理、服务注册发现、配置治理等十几个关键的领域，同时它覆盖了完整的生命周期，从开发态到测试态到发布态再到运行态。
都希望可以利用OpenSergo Spec中定义的一个CRD标准来进行统一的配置。
对用户来说，无需关注个框架不同的声明式API以及互不兼容的一个配置格式的一个问题。会实现各个生态的一个集成接入保证。
二、OpenSergo 流量路由、流控降级与容错 v1alpha1标准介绍
（1）OpenSergo项目结构
介绍完OpenSergo 的一个领域之后，其实下面就是说来介绍一下今天的重点，就是OpenSergo 的项目结构以及它的Spec的一个内容。
首先来简单讲一下OpenSergo的一个项目结构。它有以下几个部分组成，首先就是一个统一的服务协议与CRD标准。
然后在这个标准，其实是面向各个场景来定义了一系列的统一的一个标准，比如说的服务流量这里应该怎么做、还有Spec的一个标准，在服务标准往下，提供了一系列的OpenSergo的SDK以及标准SDK来对接生态中的个个组件。
OpenSergo多语言SDK这一块，其实是希望以一个统一的标准CRD对接模块来供他下层的这框架组件来进行对接，然后再往下，其实看到就是OpenSergo的一个开源生态。或者说是OpenSergo的一个数据面，其实是它是可以对接OpenSergo的Spec的一个框架组件，对任何一块内容都可以通过OpenSergo的标准的方式来进行统一的治理。以微服务这一块为例，无论是spring cloud或者说double其实都可以通过OpenSergo这套规范，无需关心下面靠的是spring cloud或者说double，它们都会实现统一的一个能力。
（2）统一的标准方式对完整的服务链路实现治理能力
下面一块就是想表达的一个完整的场景。就是说流量从客户端进入到网关之后，无论网关是nginx或者说envoy或者说是微服务网关，然后以及再往下的的微服务应用，是Java的spring cloud或者说是double或者说是do语言的go语言的甚至也可以通过send card的方式来支持。
以一种统一的一套配置协议来定义的服务治理的一个规则可以面向多源异构化的架构也可以做到全链路生态的一个覆盖。
举个例子，当下面无论跑的是什么，只需要配置一套全灰度的规则，当流量进入到网关的时候，他会有网关的一套路由的一个规范，然后进入到微服务之后，无论微服里面跑的是什么样的一个架构，它都会遵循OpenSergo的一个标准进行一个流量路由，甚至当流量流转到数据层的redis或者说mysql的时候，同样他会遵循的规范来进行一个流量路由，从而实现端到端的一个全链路灰度的一个能力。这边是全链路灰度为例。
无论是全链路灰度也好，还是流量控制，甚至限流降级。这一切都是希望通过这一套完整的规范来支持。讲了这么多概念，其实会以标准来统一的来介绍一下。
（3）OpenSergo流量路由Spec
首先讲一下就是一个流量路由的一个Spec
对这个产品进行抽象，其首先抽象出来的就是一个TrafficLabelRule，另一个WorkloadLabelRule。
讲规则大家可能不太好理解，今天就讲一个简单的场景，比如说要进行一个灰度发布，需要对新版本进行灰度的时候，通常会有一个单独的环境，或者说是单独的一个部署集将单独的部署集可以打上一个标签，就是一个WorkloadLabelRule，通过这样的一个CRD。
然后就可以将的灰度gray my App这个应用打上一个灰度的一个标签，当然无论这个应用是Java还是说多语言的。都可以对他通过统一的方式给他打上一个标签。
然后下面一个就是定义的TrafficLabelRule，就是说定义的一个流量的一个路由的规则，下面可以针对就是说。假设现在需要将内部测试用户的一个流量灰度到新版本的主页上。假设测试用户的UID是12345，同时UID是位于header中的一个X-Id-user的这样一个header中，只需要配置路由标准即可。
他就是灰度的一个流量，然后他会映射到灰度的一个部署集上面，那同时向这些，如果maxuser的ID是666或者888等其他不符合流量规则的这样的一个流量，它其实就是没有标签，这样的话就会映射到一个默认的一个路由的一个部署集上。
在具体的流量路由的过程中，刚才谈的都是一个场景跟概念或者说是标准，这个具体路由过程中，只要是接入OpenSergo的微服务框架，无论是Java的spring cloud或者说double，或者说mash的一个policy中，只要他实现了OpenSergo的标准，并且进行上述的一个规则的配置，那么就能识别到流量的一个标签，从而将带有gree标签的流量会流转到gree标签中的一个实例分组中，如果当前的实例是没有gree分组的话，即使没有带有这个标签，那么就会默认到没有标签的一个实例上。
当然这块规范后续版本的标准中会继续提供，就是说一些未达标产品的一些兜底的一个配置方案，然后其整体来说，社区还是在不断完善流量路由的相关标准，并且与各个社区来合作共建，希望让更多的一个组件框架来支持OpenSergo的标准，从而实现统一的流量路由的一个管控。
（4）OpenSergo流控降级与容错Spec
在服务治理中比较重要的一环，就是流控降级与容错。在这个过程中，以流量为切入点，通过流控降级、流量平滑、自适应过载保护等手段来保证服务的稳定性。
那在OpenSergo中，结合框架的一个时间场景，对流控降级与容错，抽象出了这样一个标准CRD一个容错治理规则，会有以下三个部分组成，首先是Target针对什么样的一个请求。Strategy容错，或者说控制策略，比如说流控、熔断、并发以及自身的过载保护等等。还有一个就是FallbackAction触发后的一个Fallback的行为，比如说是返回错误。或者说状态之类的。
那么右边就是一套标准CRD的一套。实现就是说无论是Java还是go应用，还说max，或者说是HPV，或者是HTC，都可以用这一套统一的一个容错CRD来给微服务架构中的每一环来配置容错治理，来保证服务质量的稳定性。同样也是只要的框架适配OpenSergo就可以通过统一的方式来进行流控降级等治理。针对路径资源名首先是配置一个流控规则，然后这个流控规则它其实是可以看到就是说全局的QBS不超过10QBS。并且统计窗口每秒钟。同时可以看到也配置了一个容错降级的一个规则。
可以看一下这里面的一些值。策略其实就是一个流量半调用的一个控制，可以看到它其实是一个熔断保护的一个能力，然后这边是出发的一个阈值是60%，其整体这个规则的一个语义，在30秒内，最大的archie超过500毫秒，并且请求个数达到五的时候，请求超过500毫秒的比例达到60%，且请求个数超过五的时候，会进行自动的一个触发熔断，然后同时熔断的一个时长为五秒，对这个for规则配置了一个流量控制的一个限流的一个规则，以及一个自动熔断的一个规则，这就是一个这样简单的一个CR
三、Sentinel、SCA、Kratos 即将全面支持 OpenSergo 标准
第三块就是Sentinel、SCA、Kratos即将全面支持OpenSergo标准，其中是有流量路由以及刚才介绍的流控降级与容错的一个标准。
然后讲了这么多，其实可以理解为OpenSergo提供了一系列的标准，然后只要的框架去实现，去适配OpenSergo的标准的话，就能用一种规范在无论什么框架中，无论什么样的架构中，都可以通过同一套规范去实现一个流量制定的一个标准。那这块的实现，其实就是说无论是CRD也好，或者说是OpenSergo的控制台的一个配置也好。
通过标准的方式下发到一个controller中，然后controller会映射成不同的规则下发给SDK，从而实现这样的一个流量治理的一个能力。
下面会详细介绍一下，比如说流量路由，然后在这个过程中，如果的标签结合不同的语义，他就可以做到不同的场景，如果是自定义的标，像刚才gree这些其实可以实现的标签路由，那如果他是版本的标题，就可以实现的金丝雀发布，那同理AZ标它其实就是一个做到一个同AZ优先的一个能力。
也就是说可以基于刚才提到一个CR的一个流量路由的一个标准，配合上不同的语义，就可以在不同的产品中实现不同的一个微服务治理能力，当然这些都后续会在规范中体现出来，就是一个场景
第二会介绍一下流量路由，右上角其实刚才提到的一个流量路由的一个OpenSergo的一个SPec，然后再往下就是一个控制台的一个配置，然后就可以实现。等到左边，其实通过SDK的方式，无论通过什么方式的一个微服务，只要实现OpenSergo的SPec，它就可以用统一的方式来治理。
然后右边就是一个实现，就是说刚header-X-user-ID等于12345的时候，流量是去往灰度的，否则是去往一个正常环境。场景更加复杂化，即使是全链路灰度这种能力，也可以通过SPec来实现
其实就是。就通过流量路由加上一个流量染色，甚至是加上数据流量路由的一个SPec，其实就可以实现流量在客户端到网关到微服务，甚至到数据库表。他都可以实现一个端到端的一个全链路灰度的能力。
关于流量控制也提一下，就是说可以从它的场景有非常多。这种控制相当于安全气囊。当超出系统服务能力以外的请求。他都会被拒绝，然后拒绝的具体逻辑可以让用户来自定义，比如返回指定内容，或者说跳转页面之类的，然后就可以用右上角的这一套 OpenSergo 的一个 SPec来实现。当然它也可以通过OpenSergo的一个控制台的一个配置来做解决一个流量控制的能力。
四、总结与展望
为了让异构的微服务能够用统一的服务协议与配置方式进行治理，为了让更多的微服务能够互联互通。
一起来塑造，更加云原生的微服务是OpenSergo在建立之初就树立了一个长期的一个发展目标。在标准化的建设掌握OpenSergo会联合更更加多的开源社区跟企业，会在会在流量治理，以及后面有提到的数据库治理、服务发现、缓存治理、配置治理等更加多的领域层面上来标准化的微服务治理能力。
可以让所有的企业能够用一套通用语言来描述跟治理自己的微服务架构，让业务的开发同学可以更加专注于业务的核心价值，微服务框架也能够被客户轻松地采用，这就是想要做到的一个能力。同时在生态的建设上OpenSergo社区将逐渐从。从网关到微服务、RPC到数据库到缓存到服务发现、服务配置。异步。调度，分布式调度等等微服务的一个分布式链路中的每一环的生态，会通过与各个社区的合作。让各个主流框架都可以借助统一的OpenSergo的spec来实现与定义微服务治理的能力，可以让开发者无需关注各个框架、各个协议的概念跟实现的差异，来降低开发者跨语言、跨框架协议层面的服务治理的一个把控成本。OpenSergo目前将会与持续与阿里巴巴、double Carlos santana以及cloud we go等社区进行合作。希望能将标准落到各个框架中。
在这个过程中，也非常欢迎更多的开源社区跟企业可以加入到OpenSergo的一个标准生态的共建。然后在这个过程中，其实在控制面的建设上，希望联合社区一起打造一个OpenSergo的一个控制台，来作为统一的服务治理的一个控制面。那也希望通过中立的，通用的，开放的一个OpenSergo的一个标准协议，让所有的微服务框架，所有的通讯协议都可以被同一套微服治理，然后从而实现真正的一个全链路，多语言，多写意，标准化的一个治理的一个互通。在这个过程中，可以详细提一下的，就在20年七月份这一块重点会围绕的是流量治理这一块领域，会推出的流量染色、流量路由、流控价值、系统过载保护等标准的Spark建设。
然后在九月份会推出流控服务协议、数据库治理、插件配置治理相关的一个Spec。同时社区生态的支持也会同步进行，比如像这里主要在阿里巴巴、double以及cloud we go以及更多的服务框架以及微服务流量相关的一些社区的一个知识。
然后在九月份这块，因为有涉及到数字相关的，所以会尝试跟Druid、APISIX以及网关等进行合作，那在这个过程中希望控制台也可以做到，就是可以通过统一的一个CRD的一个配置，来实现的一个流量以及各个层面的治理。
然后在这个过程中，其实OpenSergo一开始其实他就是一个社区项目，是通过APISIX2.0的一个协议开源的。所以也正在跟各个社区进行合作，希望大家一起来把标准跟标准的设计跟实现来一起完善。当然目前提出第一版本，后面会持续的迭代和完善，希望大家一起可以将OpenSergo spec进行推进跟落地到更多的微服务生态中，后续也会按照开源的方式。
在OpenSergo服务治理标准的制定以及发展上，会通过公开、透明、民主的方式来制定标准，推动实施，在社区中也会通过，邮件列表或者是社区双周会的等机制来确保社区协作方式的一个来共建标准实现。
这个过程也非常欢迎大家一起来通过这些形式来参与跟贡献。最后就是欢迎大家加入一个OpenSergo的一个社区。
在这个过程中，其实欢迎大家体验OpenSergo微服务治理标准的一个企业级的产品MICE，在这个过程中MICE服务治理是全面支持OpenSergo的一个标准。
提供了服务治理、流控降级等核心能力，在服务治理中，其实有做到的一个特性就是一个零业务侵入，然后同时开发、测试、运维等全生命周期的覆盖。
最后微服务治理企业版，它不仅提供了更加全面的微服务治理能力，还提供了流量防护的能力。同时它的价格其实跟流量防护那个产品是一致的。可以说是一样的价格提供了更加多的一个能力，那同时如近期也上线微服务治理企业版的一个资源包，购买资源包的话，会省的更多。
