开发者学堂课程【基于 OpenSergo 标准构建Spring Cloud Alibaba 流量路由能力 ：基于 OpenSergo 标准构建 Spring Cloud Alibaba 流量路由能力（二）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1213/detail/18213
基于 OpenSergo 标准构建 Spring Cloud Alibaba 流量路由能力
三、opensergo 流量路由 v1alpha1 标准介绍
下面就是这节课的重点，就是 opensergo 的流量路由的 spec 的标准，以及在 Spring cloud alibaba 中的实现，首先是在流量治理的标准化的探索，希望通过右边的 spec 来对流量进行路由，
将流量路由的规则分为两个模块，首先第一部分是 traffirouterrule，目的就是对符合条件的流量进行匹配与路由，第二是 virtualworkloads，对符合条件的 workload 进行划分，看图，对于 x- user- Id；12345的流量路由至 l abel ：gray 的 workload 上面，同时对 deployment：A-gray 以及 B-grey 这两个 deployment，这里可以是java，也可以是 Go 的应用，甚至可以是数据库的实例，或者说数据库的表，它其实是虚拟的，工作复杂的抽象，然后可以对workload 进行标记，比如，label：gray 这样的标记，这样的规则可以有映射关系，将 X-User-id：12345的流量路由至 label：grey 的 workload 中，即 Deployment：A-grey，B-grey 中，从而实现流量路由的能力，看右边，是opensergo 传媒 traffic root 的标准，只需 uplate，就能实现这样的服务，可以把它的 http 的 name 等，培训参数为深圳的的请求，路由至v2版本中，不符合条件的流量，可以将它默认的路由至 target，是 workload 的版本中，
以上是流量路由的场景，表明需要将目标的流量路由至具备相应特征的工作负载中，是这样的规则。在过程应该如何实现，首先需要刚才提到的右边 CRD，然后把 CRD 下发至 opensergo 的 plane，经 gRPC 转化成对应框架里识别的 config，先转换成 opensergo 的 config，然后经过 gRPC 通路下发至对应的 opensergo 中的 SDK 中，框架层通过 low- level config，可以很方便的对接 opensergo，alibaba 也是这么做的。下面是 Spring cloud alibaba 流量路由支持收购的完整的电路，简单做讲解，介绍完之后会进行简单的 demo，
可以看到目前当用户或者在控制台配置或者是 apply YAML，即 CRD 时，API serve 会把配置转换给 opensergo 的控制面，会根据对应 app 以及规则形式下发给 opensergo 的 SD K，SDK 会将 trafficrouterule 的配置转换成 SCA 中所识别的配置类型，能同时把工作负载中的标记也会下发至服务端的 opensergo 的 SDK 中，同时在服务注册时，会把标记给带上，流程结束。
下面进行简单的演示。可以看到下图是 alibaba 的 provider，
provider 是 v1 版本，另是 v2 版本，还有 consume，重新写这个 consume，
consume 重写只需要增加 opensergo 的模块依赖，这个过程是通过对接 opensergo 的 SDK，来监听 opensergo 的控制面的数据，下图是 opensergo 的控制面
是流量路由的 spec，重复使用，对 header，name，location 的值进行使用，然后看 Spring cloud 的 consume，通过 opensergo 的 Java SDK，收到刚才下发的配置，会在 SCA中生效，接下来来简单的验证一下，直接访问没有条件的流量可以看到访问的默认版本 v1，如果访问的是name的xiaoming，地址深圳，可以看到访问的版本是v2，通过这样简单流程就实现了流量路由的能力，name：xiaoming，location：cn-shenzhen 等请求会路由至v2版本，如果没有带条件就会至v1版本。通过简单的 demo，就演示 Spring cloud alibaba 的框架，通过集成 opensergo 的 SDK 就能具备流量路由，并且通过 opensergo 的流量路由的规则下发，就能按照需求来进行流量路由的能力。
展望与总结
一方面会介绍一下 opensergo 近期社区的进展以及 Mse 服务治理的 opensergo 对应的云产品，Mse 服务治理里的发展，然后也会进行简单的 Spring cloud alibaba 后期的在服务治理方面的规划。
首先先同步一下近期的社区的进展，首先 v 1alpha1 spec 发布，覆盖流量路由，流控降级与容错等微服务治理领域。opensergoSDK/operator 已和社区共同设计结构与方案，Java/Go SDK 及 operator 骨架搭建中，目前已具备初步对接能力。最后，cloudWeGo， kitex，krators，Spring cloud Alibaba，APISIX 等社区对接中，opensergo 流控CRD 与 sentinel Go demo 对接，演示完成。目前可以说阿里巴巴的流量路由的 CRD 的功能的 demo 演示完成了。
第二，重新讲一下开源框架通过 opensergo SDK 对接治理标准的方式，是 opensergo 的 SDK 提示在这里提供了订阅配置和获取配置的 API，框架接入 SDK 并且监听接受 opensergo 的标准配置，并且基于收到的配置对接到框架现有层面的流量治理的能力中，同时 openserge operator 作为控制平面，承载由 opensergo K8sCRD 到 low-level config 的转换，以及配置的监听管理与下发到 SDK 的链路 。框架对接的事例比如像 Go 语言的话题，只需要加initopensergo，然后 subscribeconfig 添加 listener 就可以拿到
opensergo的配置，能转化成框架自身已有的能力，从而实现复制品能力的对接。
另外介绍开源框架通过 sentinel 对接流量治理标准实现，sentinel2.0 作为流量治理标准的实现，会自带 opensergo流量治理的对接模块，社区可以直接通过对接 sentinel 或提供 sentinel adapter 快速对接 opensergo 流量治理的标准生态中，同时也可以利用 sentinel 的流量治理与容错的能力来保障稳定性。
最后是 opensergo 的社区展望，目前已经完成流量路由，流控降级的 spec 建设，最近会提出流量染色，数据库治理，离群实力摘除，流控服务协议等能力的 spec，在年底，会提供配置发现，缓存以及服务发现等安全治理等领域的 spec，当然这些都是从微服视角出发的能力，明年可能会面向更多的依赖的组件，分布式任务治理，MQ 治理，日志治理，多语言互通等方面领域的 spec，在社区合作方面近期与阿里巴巴已经完成了柳园路与能力落地，还有更多sentinel，kratos 等，目前都是紧密对接过程中。
最后提一下 opensergo 开放共建，是 spec 与 SDK 的演进其实离不开各个社区与各个企业的共建，可以参与进来建设 opensergo spec 的完善与共建，可以基于企业或者社区或者是微服务治理的场景与最佳实践，可以一起讨论来制定与完善微服务制定的标准，也可以参与到 SDK 的贡献中，opensergo operator 的共建以及各个语言的 opensergo SDK 的贡献，最后是社区生态的贡献，给贡献各个社区生态对接 opensergo 的代码，模块，文档以及整体的opensergo 文档。
最后是 opensergo 服务治理标准所对应的源上的产品，就是 Mse 服务治理，提供了全链路全方位的服务治理，从前端请求到网关再到后端应用，再到下游依赖，各个点位都提供了完整的服务治理能力比如全链路灰度以及在应用发布的服务治理里的各个阶段，比如像开发态，有服务测试还有互联等能力，以及在测试态，服务测试。发布态，全链路灰度，无损上下线，在运行态有流量降级，及时隔离或摘除，日志治理等等能力，同时面向各个组件，比如面向数据库，数据库的治理能力，微服务面向数据库的治理，比如满 SQL 的治理，数据库访问流量的分离，路由与分离，可以实现读写分离的能力以及面向其它服务的服务，不稳定第三方服务探测，融断与隔离，面向缓存热点 key 击穿防护等全部能力，这些能力目前都是跟 opensergo 紧密关联，会符合 opensergo 服务治理的标准。
