跳到主要内容

赵奕豪

欢迎在校同学们参与 OpenSergo 开源之夏,社区大牛导师手把手让你的代码被社会广泛复用,来赚取最高12000奖金,可推荐入职/实习你心意公司,又拿钱又成长又有价值,你还等什么呢?报名马上截止,快来参与 2023 OpenSergo 开源之夏~

开源之夏是什么?

开源之夏是由“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动,旨在鼓励在校学生积极参与开源软件的开发维护,促进优秀开源软件社区的蓬勃发展,培养和发掘更多优秀的开发者。活动联合国内外各大开源社区,针对重要开源软件的开发与维护提供项目任务,并面向全球高校学生开放报名。学生可在本活动中自主选择感兴趣的项目任务进行申请,并在中选后获得该开源项目资深维护者(社区导师)亲自指导的机会,完成项目并贡献给社区后,参与学生还将获得开源之夏活动奖金结项证书

OpenSergo 项目介绍

OpenSergo 是面向云原生、覆盖微服务及上下游关联组件的微服务治理项目,由 阿里云、bilibili、SphereEx、中国移动等公司,及 Kratos、CloudWeGo、ShardingSphere、Dubbo、Spring Cloud Alibaba、Nacos 等社区联合发起。OpenSergo 从微服务的角度出发,涵盖流量治理、服务容错、服务元信息治理、安全治理等关键治理领域,围绕微服务统一控制面与服务治理标准,提供标准通用、专业的微服务治理解决方案与规范,全方位保障 Java/Go/网关/Mesh 异构微服务体系的高可用。在本次开源之夏活动中,同学们将参与到 OpenSergo 微服务统一控制面的核心演进中,结合 Istio、K8s 等云原生生态,一起开创微服务治理领域,共同主导下一代微服务技术演进。

参与开源之夏条件

  • 本活动面向年满 18 周岁在校学生。
  • 暑期即将毕业的学生,只要在申请时学生证处在有效期内,就可以提交申请。
  • 海外学生可提供录取通知书、学生卡、在读证明等文件用于证明学生身份。

参与开源之夏,你能获得什么?

  1. 【你的代码被社会广泛复用】你的代码可能会运行在上万家企业核心业务逻辑中,帮助企业解决问题。
  2. 【赢得最高12000奖金】奖金总额根据项目难度分为进阶 12000 元、基础 8000 元(注:奖金数额为税前人民币金额)
  3. 【社区核心人员辅导快速成长】只要你报名被选中,每个题目的导师会精心手把手教你融入社区,帮助你完成题目的设计以及最终的落地。
  4. 【推荐入职/实习】在本次编程之夏项目中表现优秀同学,可推荐入职/实习 你心意的公司工作。
  5. 【额外获得社区礼包】所有参与本次编程之夏项目的同学,均可获得 OpenSergo 社区大礼包。

百分百有奖品拿哦,现在唯一的问题是时间不多了,赶紧上车报名!截止报名时间是6月4日,快点来报名参与 2023 编程之夏吧~

课题&报名方式

点开 OpenSergo 开源之夏项目列表 选择你喜欢的题目,项目列表如下:

具体流程请参考学生指南

请注意找导师沟通截止流程时间,优先更导师沟通,能帮助你更好的了解题目。想要报名的同学,请加入 OpenSergo 社区讨论群(钉钉群群号:34826335),方便大家交流题目内容。也欢迎大家关注 OpenSergo 官方微信公众号,了解社区最新动态:

opensergo-wechat

参考资料

同时如果同学们对其他领域项目感兴趣,也可以尝试申请,例如:

  • 对于微服务注册发现和配置管理有兴趣的同学,可以尝试填报Nacos开源之夏;
  • 对于微服务分布式事务有兴趣的同学,可以尝试填报Seata开源之夏;
  • 对于微服务框架和RPC框架有兴趣的同学,可以尝试填报Spring Cloud AlibabaDubbo 开源之夏;
  • 对于云原生网关有兴趣的同学,可以尝试填报Higress 开源之夏;
  • 对于微服务治理及高可用防护有兴趣的同学,可以尝试填报 SentinelOpenSergo 开源之夏。

赵奕豪

本次(2023/02/01)OpenSergo 与 Sentinel 社区会议为兔年新春第一次社区会议,会议纪要:

  1. @十眠 详细分享了 Sentinel 2.0 流量路由模块的设计、代码流程与实现,以及 Dubbo 接入 Sentinel 流量路由模块的方案,并演示了 Dubbo + Sentinel 2.0 + OpenSergo 流量路由能力的 demo。Sentinel 2.0 抽象了 RouterFilter、LoadBalancer 等流量治理的基础接口与实现,并对接了 OpenSergo 流量路由 spec,欢迎社区一起 review 实现,并一起将更多的框架生态对接到新的 Sentinel 2.0 生态中。
  1. @宿何 分享了 OpenSergo 统一控制面最新的进展,以及 OpenSergo 体系与 Istio 的对比。目前 OpenSergo 统一控制面正在尝试以多种方式支持 Istio 生态,以标准方式 覆盖多语言生态、Mesh 生态。我们期望最终的形态是,OpenSergo 控制面既可以自成一体,又可以作为 Istio 的插件配合使用。欢迎社区参与 Istio 生态集成相关讨论:https://github.com/opensergo/opensergo-control-plane/issues/52
  2. 社区针对以下问题进行了详细讨论:

GitHub discussions: https://github.com/opensergo/opensergo-specification/discussions/74


社区会议参与方式

OpenSergo 社区会议每两周开展一次(一般是每两周的周三晚),时间为1小时左右。入会方式:

  • 会议形式:钉钉会议
  • OpenSergo 社区交流群(钉钉群):34826335
  • 钉钉会议入会口令:244 801 51010

泮圣伟
刘子明

Spring Cloud 应用为何需要服务治理

随着微服务技术的发展,微服务(MicroServices) 的概念早已深入人心,越来越多的公司开始使用微服务架构来开发业务应用。如果采用得当,微服务架构可以带来非常大的优势。微服务架构的最大好处是它可以提升开发效率和系统整体的稳定性:

  • 开发和部署相对简单:单个微服务的功能可以更快地更改,因为可以独立部署、影响范围更小,启动和调试单个微服务的时间成本相比于单体应用也大大减少。
  • 横向扩展简单:根据业务的高峰低谷周期快速的横向扩展非常简单,因为单个微服务通常很小,可以随着系统整体负载的变化更快地启动和停止。
  • 架构升级灵活:单个微服务的“内部架构”可以迅速升级,因为微服务之间松散耦合的,只面向定义好的通讯接口进行编程。这使开发团队能够基于自身的技术背景和偏好灵活选择,而不会直接影响其他应用程序、服务或团队。
  • 更好的容错性:微服务之间可以实现更好的故障隔离,单个服务内的内存泄露等故障不容易影响其他服务,相比单体应用一个组件故障会拖垮整个系统。

但是微服务在实施过程中,也很容易遇到一些难点。随着业务规模的增长,在这个过程中如果微服务得不到恰当的治理,不仅不能享受到微服务架构带来的好处,反而会因为微服务带来的系统复杂性,造成开发、运维部署的复杂度增加,进而影响开发迭代的速度,甚至影响系统的整体稳定性,比如:

  • 服务之间使用远程调用进行通讯,这比进程内的直接调用复杂很多。由于通讯链路的复杂性,可能会出现很多不确定的问题,会出现远程调用不可用或者延迟较高的情况,开发人员需要能够处理这些偶发问题,避免影响业务。
  • 随着业务的发展,微服务之间的拓扑图开始变得复杂,排查问题变得困难,搭建完整的开发测试环境成本也越来越大。
  • 当功能涉及到多个微服务模块时,迭代时需要谨慎地协调多个开发团队的迭代排期,才能保证迭代能够按时交付,达到敏捷开发的效果。

因此, 微服务落地的成功与否,很大程度上取决于能否很好的对这些微服务进行治理,对于传统的 Spring Cloud 应用,并没有提供开箱即用的服务治理机制,用户只能通过自己去实现Spring Cloud中的各种扩展点来实现服务治理。相比起让用户费心费力去自己写代码实现扩展点,Spring Cloud Alibaba 选择了替用户做这些事情。用户只需导入 Spring Cloud Alibaba 中的 starter,即可快速给自己的 Spring Cloud 应用添加对应的微服务治理能力。

Spring Cloud Alibaba 新版本服务治理能力预览

最新发布的 Spring Cloud Alibaba 2.2.10.RC1 新版本,基于社区 2.2.x 分支进行的构建发布,其中 2.2.10.RC1 版本通过首次给 Spring Cloud 生态带来了微服务治理能力,并给Spring Cloud Alibaba应用带来了Proxyless Mesh的能力,让Spring Cloud Alibaba应用更好的拥抱服务网格。详细的新版本预览内容如下:

2.2.10.RC1 是在 Spring Cloud Hoxton.SR12、Spring Cloud 2.3.12.RELEASE 的基础上,支持 Istio 以及OpenSergo 控制面下发的服务治理规则,对 Spring Cloud 生态中的 Ribbon 负载均衡器以及 Spring MVC, Spring WebFlux 的各种拦截器做了增强,实现了服务治理的部分能力,属于一个重大特性发布的新版本

2.2.10 RC1版本主要支持了标签路由与鉴权这两种服务治理的能力,并且支持对接多种控制平面的实现,除了目前服务网格的事实标准 Istio,新版本也支持社区最新推出的 OpenSergo 控制平面以及服务治理生态,详细的能力如下所示:

流量路由

我们可以基于流量路由标准来实现各种业务场景,如标签路由、金丝雀发布、同机房优先路由等。

  • 标签路由:标签路由是按照标签为维度对目标负载进行划分,符合条件的流量匹配至对应的目标,从而实现标签路由的能力。当然基于标签路由的能力,赋予标签各种含义我们就可以实现各种流量路由的场景化能力。
  • 金丝雀发布:金丝雀发布是一种降低在生产中引入新软件版本的风险的技术,方法是在将更改推广到整个基础架构并使其可供所有人使用之前,缓慢地将更改推广到一小部分用户。金丝雀发布是一种在黑与白之间,能够平滑过渡的一种发布方式。让一部分用户继续用旧版本,一部分用户开始用新版本,如果用户对新版本没有什么反对意见,那么逐步扩大范围,把所有用户都迁移到新版本上面来。一直都有听说,安全生产三板斧的概念:可灰度、可观测、可回滚。那么灰度发布能力就是帮助企业软件做到快速迭代验证的必备能力。在K8s中金丝雀发布的最佳实践如下:第一步:新建灰度 Deployment,部署新版本的镜像,打上新版本的标签。第二步:配置针对新版本的标签路由规则。第三步:验证成功,扩大灰度比例。第四步:若验证成功,将稳定版本的应用更新成最新镜像;若验证失败,把灰度的 Deployment 副本数调整到 0 或删除该 Deployment。
  • 全链路灰度:当企业的发展,微服务的数量会逐渐增多。在有一定规模的一定数量的微服务情况下,一次发版可能涉及到的服务数量会比较多,微服务链路也相当较长。全链路灰度可以保证特定的灰度流量可以路由到所有涉及到的灰度版本中。
  • 同可用区优先路由:当企业的对稳定性的要求变高时,企业的应用会选择部署在多个可用区中提高应用的可用性,避免某个可用区出现问题后导致影响应用的可用性。当应用在不同的可用区部署时,应用间跨可用区调用可能会被因为远距离调用造成的网络延迟影响,同可用区优先路由会让我们的 Consumer 应用优先调用当前可用区内 的Provider 应用,可以很好地减少这种远距离调用造成的影响,同时当某个可用区出现问题后,我们只需在流量入口处将当前可用区的流量隔离掉,其他可用区的流量不会访问至当前可用区的节点,可以很好地控制某个可用区出现问题后的影响面。

服务鉴权

正常生产场景,微服务应用都具有安全要求,不会让任意的服务都可直接调用。因此需要对调用该应用的上游应用进行服务鉴权,保证应用自身的安全。

通过 OpenSergo 探索治理能力的标准化

OpenSergo 是开放通用的,覆盖微服务及上下游关联组件的微服务治理项目,是阿里巴巴微服务治理的最佳实践。OpenSergo 从微服务的角度出发,涵盖流量治理、服务容错、服务元信息治理、安全治理等关键治理领域,提供一系列的治理能力与标准、生态适配与最佳实践,支持 Java, Go, Rust 等多语言生态。

image

OpenSergo 控制平面 (Control Plane) 作为 OpenSergo CRD 的统一管控组件,承载服务治理配置转换与下发的职责。

image

  1. 准备 Kubernetes 环境,请参考 Kubernetes 的安装工具小节;
  2. 在 K8s 集群安装 OpenSergo Control Plane,请参考 OpenSergo 官方提供的 OpenSergo 控制面安装文档
  3. Spring Cloud Alibaba 应用集成 OpenSergo

注意 本章节只是为了便于您理解接入方式,本示例代码中已经完成接入工作,您无需再进行修改。

首先,修改 pom.xml 文件,引入 spring-cloud-starter-alibaba-governance-routing 依赖。同时引入 Spring Cloud Alibaba 的 spring-cloud-starter-opensergo-adapter 模块:

<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-governance-routing</artifactId>
</dependency>
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-opensergo-adapter</artifactId>
</dependency>

在 application.properties 配置文件中配置 OpenSergo 控制面的相关信息:

# OpenSergo 控制面 endpoint
spring.cloud.opensergo.endpoint=127.0.0.1:10246
  1. Spring Cloud Alibaba 应用启动:启动三个模块的启动类,分别为OpenSergoConsumerApplication,两个ProviderApplication,将其注入到Nacos注册中心中。
  2. 通过 OpenSergo 控制面也定义了特定的流量路由规则 TrafficRouter 。TrafficRouter 将特定特征的流量映射至特定特征所对应的工作负载上,社区目前的设计TrafficRouter主要是基于 Istio VirtualService 进行补充与扩展。

如下是一个 OpenSergo 控制面对应的流量路由规则:

apiVersion: traffic.opensergo.io/v1alpha1
kind: TrafficRouter
metadata:
name: service-provider
namespace: default
labels:
app: service-provider
spec:
hosts:
- service-provider
http:
- match:
- headers:
tag:
exact: v2
route:
- destination:
host: service-provider
subset: v2
fallback:
host: service-provider
subset: v1
- route:
- destination:
host: service-provider
subset: v1

这条 TrafficRouter 指定了一条最简单的流量路由规则,将请求头tag为v2的HTTP请求路由到v2版本,其余的流量都路由到v1版本。如果v2版本没有对应的节点,则将流量fallback至v1版本。

效果演示

发送一条不带请求头的 HTTP 请求至 OpenSergoConsumerApplication:

curl --location --request GET '127.0.0.1:18083/router-test'

因为请求头不为 v2,所以请求将会被路由到v1版本,返回如下:

Route in 30.221.132.228: 18081,version is v1.

之后发送一条请求头tag为 v2 的HTTP请求:

curl --location --request GET '127.0.0.1:18083/router-test' --header 'tag: v2'

因为满足路由规则,所以请求会被路由至 v2 版本:

Route in 30.221.132.228: 18082,version is v2.

停止 v2 版本的 ProviderApplication 后,继续发送一条请求头tag为 v2 的 HTTP 请求:

curl --location --request GET '127.0.0.1:18083/router-test' --header 'tag: v2'

因为 v2 版本没有服务提供者,因此流量被 fallback 至 v1 版本。

Route in 30.221.132.228: 18081,version is v1.

上述详细示例代码可以在社区 GitHub 上示例代码中获取。

OpenSergo 总结与展望

在 Java 生态中, OpenSergo 紧接着会支持 Apache Dubbo 的流量路由与全链路灰度场景,同时 Sentinel 2.0 会进行服务治理全面升级,能力实现从流量防护场景升级至支持微服务治理场景。在多语言生态中,OpenSergo 后续会探索 Dubbo、Kratos、CloudWeGo 以及 Mesh 等更多生态的治理能力支持与覆盖,与企业与社区共建微服务治理的最佳实践。

image

OpenSergo 社区现在处于高速发展阶段,从微服务治理标准定义,到统一控制面 (control plane) 的实现,再到 Java/Go/C++/Rust 等多语言 SDK 与治理功能的实现,再到各个微服务生态的整合与落地、最佳实践,都还有大量的演进工作,欢迎社区一起参与标准完善与代码贡献。 image

OpenSergo 开源贡献小组正在火热招募贡献者。如果您有时间,有热情,有意愿,欢迎联系社区加入开源贡献小组,一起共同完善 OpenSergo 和 Sentinel,一起主导微服务治理技术与标准演进。Now let's start hacking!

赵奕豪

本次(2023/01/11)OpenSergo 与 Sentinel 社区会议合并进行,会议纪要:

议题讨论

  1. @屿山 详细分享了 OpenSergo 控制面 Go 扩展性的技术方案及业界调研。OpenSergo Control Plane 作为统一服务治理控制面,期望提供低侵入、灵活的扩展机制,以便支持配置监听/转换、策略预计算等模块可插拔扩展。欢迎社区一起参与讨论与设计:https://github.com/opensergo/opensergo-control-plane/issues/46
  2. @Jason 详细分享并讨论了事件/消息治理 proto 相关的设计,Apache EventMesh 等社区同学参与了讨论完善。该设计还在进一步完善中,欢迎大家参与完善:https://github.com/opensergo/opensergo-specification/issues/62

其它社区进展同步

OpenSergo 社区关键进展:

Sentinel 社区关键进展:


社区会议参与方式

OpenSergo 社区会议每两周开展一次(一般是每两周的周三晚),时间为1小时左右。入会方式:

  • 会议形式:钉钉会议
  • OpenSergo 社区交流群(钉钉群):34826335
  • 钉钉会议入会口令:244 801 51010

本次社区会议是春节前的最后一次社区会议,社区在此预祝各位开发者新年快乐~

赵奕豪

本次(2022/12/07)OpenSergo 与 Sentinel 社区会议合并进行,会议纪要:

议题讨论

  1. @十眠 分享了 Spring Cloud Alibaba 流量路由基于 OpenSergo 新的流量路由 CRD 的演示与改造。目前 OpenSergo 流量路由 CRD 直接基于 Istio VirtualService/DestinationRule 进行扩展,传输链路 proto 基于 RDS 进行扩展,以便做到易理解、通用。欢迎社区一起 review SCA+OpenSergo 流量路由 spec 整合 PR:https://github.com/alibaba/spring-cloud-alibaba/pull/2921

  2. @流士 介绍了无损上下线治理相关的技术与模型设计,并与 bilibili、小红书的同学进行了探讨。对于任何一个线上应用来说,发布、扩容、缩容、重启等操作不可避免。伴随微服务规模化和应用的云原生化,对业务频繁发布过程中流量损失的容忍度逐步降低,在应用部署阶段我们可以借助无损上下线治理解决变更态业务有损问题。模型设计可以参考 OpenSergo 无损上下线治理之模型与原理篇 这篇文章。

image

  1. @宿何(Eric) 介绍了从微服务框架的视角如何统一对接 Sentinel 2.0 流量治理能力。Sentinel 2.0 将升级为云原生的流量治理组件,在原有流量防护与自愈能力的基础上,新增流量路由调度、负载均衡策略、流量权重策略、流量染色等流量治理的核心能力。目前 Sentinel 社区还在进行骨架抽象,预计下次社区双周会可以分享 Sentinel 2.0 初版骨架的 POC。

其它社区进展同步

OpenSergo 社区关键进展:

  • OpenSergo Go SDK 正式发布首个版本,具备各个 Go 框架与组件快速对接 OpenSergo 标准 CRD 的能力,进一步扩充多语言治理生态。后续社区将持续推进各主流微服务框架与 OpenSergo 生态的对接,并将流量治理核心能力沉淀到 Sentinel Go 2.0 中。

Sentinel 社区关键进展:


社区会议参与方式

OpenSergo 社区会议每两周开展一次(一般是每两周的周三晚),时间为1小时左右。入会方式:

  • 会议形式:钉钉会议
  • OpenSergo 社区交流群(钉钉群):34826335
  • 钉钉会议入会口令:244 801 51010

下一次社区会议为2022年度最后一次 Sentinel & OpenSergo 社区联合会议,时间为 2022/12/22(周四)晚 19:30,欢迎社区同学参与讨论与分享。

赵奕豪

本次(2022/11/23)OpenSergo 与 Sentinel 社区会议合并进行,议程如下:

  • 同步上一周期的进展,包括微服务治理 spec 建设、Control Plane && SDK 进展、社区生态接入,以及 Sentinel 社区进展。
  • 社区分享与讨论,包括 Sentinel 2.0 新模型及流量治理骨架设计讨论、OpenSergo 与 Istio 生态结合的方案讨论等。

会议纪要:

议题讨论

  1. 社区分享了 Sentinel 2.0 新模型及流量治理骨架设计。Sentinel 2.0 将升级为流量治理组件并作为 OpenSergo 流量治理能力与标准实现,其中重点设计包括:

欢迎大家一起参与 Sentinel 2.0 Java/Go 版本的共建~

  1. 社区分享了 OpenSergo 与 Istio 生态结合的方案,同时分享了 OpenSergo 流量路由 spec 订正思路。
  • 关于 OpenSergo 与 Istio 生态结合的方案,有两种情况(1)OpenSergo 控制平面具备 CRD 转换的能力,支持将 OpenSergo 流量路由/染色 CRD 受限转换为 Istio VirtualService/DestinationRule 以及 EnvoyFilter(按需)。这样可以做到开箱即用,但 CRD 转换受限于 Istio/Envoy 本身的能力,只能配置最基本的 OpenSergo 治理能力(2)OpenSergo 控制面将 CRD 转为 low-level config 后由 OpenSergo 自身的链路进行配置下发,通过 Envoy WASM plugin 或 SDK 生效(后者即框架本身支持 OpenSergo),这种场景支持全部的 OpenSergo 治理能力。
  • 基于通用性、理解成本等考虑,社区提出了 OpenSergo 流量路由 spec 的另一种思路:直接基于 Istio VirtualService/DestinationRule 进行字段扩展,重新定义了 TrafficRouterVirtualWorkload。稍后社区将提交新的 PR 来进行详细描述。
  • 基于以上两点,全链路灰度在 OpenSergo 生态中的实现方式:TrafficLane CRD 按需生成 TrafficRouter/VirtualWorkload CRD(OpenSergo 体系,走 OpenSergo 链路下发与生效)或 VirtualService/DestinationRule + EnvoyFilter(纯 Istio+xDS 体系)。

image

同时社区针对 Istio 控制平面存在的问题进行了讨论。

其它社区进展同步

OpenSergo 社区关键进展:

Sentinel 社区关键进展:


社区会议参与方式

OpenSergo 社区会议每两周开展一次(一般是每两周的周三晚),时间为1小时左右。入会方式:

  • 会议形式:钉钉会议
  • OpenSergo 社区交流群(钉钉群):34826335
  • 钉钉会议入会口令:244 801 51010

欢迎社区同学参与讨论与分享。

赵奕豪

为什么需要微服务治理与 OpenSergo?

在经典微服务架构中,我们通常将服务调用中各角色划分为三部分:服务提供者、服务消费者、注册中心。经典的微服务架构可以解决微服务能调通、可以运行起来的问题。随着分布式服务架构的不断演进、业务规模的扩张,诸多复杂的稳定性与易用性问题显现出来,这时候就需要一些手段来针对日益复杂的微服务架构进行“治理”。微服务治理就是通过流量治理、服务容错、安全治理等技术手段来减少甚至避免发布和管理大规模应用过程中遇到的稳定性问题,对微服务领域中的各个组件进行治理。服务提供者、消费者、注册中心、服务治理,构成现代微服务架构中重要的几环。

image

微服务治理是把微服务做稳做好的关键一环。但是,业界微服务治理存在概念不统一、配置形式不统一、能力不统一、多框架统一管控较为复杂等问题。比如我们希望配置流量灰度规则,在 Spring Cloud Alibaba 中可能需要通过 YAML 方式配置,在 Dubbo 中需要通过另一种配置格式进行配置,在 Istio 体系内中可能又需要通过 Istio CRD 的方式进行配置。不同框架治理配置方式的不一致使得微服务统一治理管控的复杂度相当高。另外,业界的各种框架支持的服务治理能力都不统一,且通常比较基础,很多时候无法覆盖生产级的场景。

background

基于上面这些痛点,阿里巴巴在2022年1月开始和 bilibili、字节等企业讨论服务治理如何规范化和更加普及,从而共同发起了 OpenSergo 项目OpenSergo 是开放通用的,覆盖微服务及上下游关联组件的微服务治理项目,从微服务的角度出发,涵盖流量治理、服务容错、服务元信息治理、安全治理等关键治理领域,提供一系列的治理能力与标准、生态适配与最佳实践,支持 Java, Go, Rust 等多语言生态。OpenSergo 的最大特点就是以统一的一套配置/DSL/协议定义服务治理规则,面向多语言异构化架构,覆盖微服务框架及上下游关联组件。无论微服务的语言是 Java, Go, Node.js 还是其它语言,无论是标准微服务还是 Mesh 接入,从网关到微服务调用,再到微服务对数据库/缓存的访问,开发者都可以通过同一套 OpenSergo CRD 标准配置进行统一的治理管控,而无需关注各框架、语言的差异点,降低异构化、全链路微服务治理管控的复杂度。

overview

OpenSergo 提供 Java、Go 等多语言的 SDK,各个框架生态可以非常方便地通过 OpenSergo SDK 来对接 OpenSergo 标准配置,接入到 OpenSergo 生态中,通过 OpenSergo 控制平面 (Control Plane) 统一管理服务治理规则。

微服务视角的数据库治理是保障服务稳定性的关键一环

提到“微服务治理”,很多开发者会首先想到针对微服务之间的调用流量进行治理,但很多时候大家容易忽视掉微服务访问存储与其它中间件的这部分流量。在一个真实的业务生产环境中,流量首先先进入入口网关(如 Nginx、Envoy),再流转到后端 Web Server,再流转到微服务之间的 RPC 调用,再流转到针对数据库、缓存、消息等存储/中间件的访问。在这样一个全链路的架构中,仅仅关注微服务之间的调用是不够的,我们需要针对链路中的每一环分别进行针对性的治理。其中微服务对数据库的访问是非常普遍的,也是容易出现稳定性问题的一环。比如:

  • 某个应用某类报表 SQL 访问量非常大,且查询非常消耗性能,把数据库 CPU 打满
  • 慢 SQL 访问非常多,占满连接池/业务线程池,导致服务无法处理正常请求,甚至导致级联雪崩
  • 连接池参数配置不合理,导致大量 SQL 写操作时无法有效获取连接,业务大量报错
  • 数据库访问需要按环境标进行隔离,比如灰度数据写入到灰度表中

db-gov-bg

对于大多数的后端应用来讲,系统性能扩展的瓶颈主要受限于数据库。尤其在微服务的环境下,数据库的性能治理问题往往也是团队优先级最高的几类工作之一,数据库治理自然也成为微服务治理中必不可少的一环。我们期望开发者可以结合数据库治理能力,来保障微服务访问数据库的稳定性(保护微服务自身不被拖垮),同时也保障数据库的稳定性。

OpenSergo 联合 ShardingSphere 社区共建数据库治理标准

基于以上背景,OpenSergo 社区期望结合企业与开源社区的经验,抽出一套通用的、从微服务视角出发的数据库治理标准规范。ShardingSphere 作为数据库治理领域的标杆项目,沉淀了非常丰富的最佳实践与技术经验,可以很好地为 OpenSergo 补充数据库治理领域的空缺。因此 OpenSergo 社区联合 ShardingSphere 社区共建微服务视角的数据库治理标准,扩充治理边界,让社区能够以标准化的方式针对不同数据层框架与流量进行统一治理管控,共同推进治理领域技术与生态演进。

opensergo-db-governance-overview

对于此次 OpenSergo 与 ShardingSphere 社区之间的合作,双方社区负责人都对此次合作表达了自己的观点:

Apache ShardingSphere PMC Chair 张亮: 在微服务领域,服务间的交互与协作已日臻完善,而服务对数据库的访问却依然缺失行之有效的标准。ShardingSphere 自开源以来,一直持续不断的践行着“连接、增强、可插拔”的设计哲学。其中,“连接”则是希望提供标准化的协议和接口,打破开发语言访问异构数据库的壁垒。OpenSergo 提出了微服务治理的标准,并首次将数据库的访问放在了标准中,非常具备前瞻性。作为访问数据库重要入口的微服务,我非常希望 ShardingSphere 和 OpenSergo 共建标准。

OpenSergo && Sentinel 社区负责人 赵奕豪(宿何):在微服务治理领域中,除了微服务本身的治理之外,针对数据库访问的治理也是保障业务可靠性与连续性的关键一环。ShardingSphere 作为数据库治理领域的标杆项目,沉淀了非常丰富的最佳实践与技术经验,可以很好地为 OpenSergo 补充数据库治理领域的空缺。因此我们联合 ShardingSphere 社区共建微服务视角的数据库治理标准,扩充治理边界,期待让社区能够以标准化的方式针对不同数据层框架与流量进行统一治理管控,共同推进治理领域技术与生态演进。

OpenSergo 微服务视角的数据库治理标准主要包括以下几部分:

对数据库 workload 及访问对象的抽象

在治理规则中,我们通常需要指定规则作用的数据库实例(或实例组),或者满足的 SQL 条件。针对这一部分,我们在 OpenSergo 数据库治理标准中针对数据库 target workload 及访问对象进行了一些抽象。

  • 虚拟数据库 (VirtualDatabase):在数据库治理中,不管是读写分离、分库分表、影子库,还是加密、审计和访问控制等,都需要作用在一个具体的数据库之上。在这里将这样的一个逻辑的数据库称为虚拟数据库,即 VirtualDatabase。VirtualDatabase 在应用看来是一组特定的数据库访问信息,并通过绑定特定的治理策略实现相应的治理能力
  • 数据库端点 (DatabaseEndpoint):在数据库治理中,通过 VirtualDatabase 向应用声明了可以使用的逻辑数据库,而数据的真实存储则依赖于这样的一个物理的数据库,这里称为数据库访问端点,即 DatabaseEndpoint。DatabaseEndpoint 对应用无感知,它只能被 VirtualDatabase 通过特定治理策略所绑定然后连接和使用。

针对访问对象的条件抽象:

  • 数据库访问对象 (DatabaseAccessTarget):定义一组匹配条件,如针对某个实例/库/表的访问、针对某类 SQL 性质(读/写操作)、按 SQL pattern 匹配、按 SQL 参数匹配等。将 DatabaseAccessTarget 与具体的治理规则结合,我们可以实现细粒度的数据库流量治理。

流量治理在数据库访问的体现

在微服务对数据库的访问中,流量路由、流量隔离、流控降级与容错等相关流量治理能力是数据库治理中非常重要的一块。

在流控降级与容错领域,我们复用了 OpenSergo 流控降级与容错标准。OpenSergo 流控降级与容错 spec 定义了三要素:Target(针对怎样的流量)、Strategy(对应怎样的流量治理策略)、FallbackAction(触发策略之后的行为)。在针对数据库访问的治理中,我们将流量条件抽象为 DatabaseAccessTarget,结合 OpenSergo 自有的流控、并发控制、熔断等策略,即可以实现细粒度的流控降级与容错。

db-ft

同时数据库流量治理体系中还有一些关键的、数据库领域特有的治理能力:

  • 读写流量路由 (ReadWriteSplitting):读写分离是常用的数据库扩展方式之一,主库用于事务性的读写操作,从库主要用于查询等操作。读写流量路由规则可以指定将读 SQL 路由到读库,事务性的读写操作路由到主库。
  • 分库分表路由 (Sharding):数据分片路由是基于数据属性一种扩展策略,对数据属性进行计算后将请求路由到特定的数据后端,目前分为分片键分片和自动分片。其中分片键分片中需要指明需要分片的表、列、以及进行分片的算法。
  • 数据流量隔离 (影子库表 Shadow):影子库表可以帮助在灰度环境或者测试环境中,接收灰度流量或者测试数据请求,结合影子算法等灵活配置多种路由方式。
  • 数据加密 (Encryption):企业往往因为安全审计和合规的要求,需要对数据存储提供多种安全加固措施,比如数据加密。 数据加密通过对用户输入的 SQL 进行解析,并依据用户提供的加密规则对 SQL 进行改写,从而实现对原文数据进行加密,并将原文数据(可选)及密文数据同时存储到底层数据库。在用户查询数据时,它仅从数据库中取出密文数据,并对其解密,最终将解密后的原始数据返回给用户。

db-gov-feature-intro-1

以下是一个读写流量路由规则的示例:

# 虚拟数据库配置
apiVersion: database.opensergo.io/v1alpha1
kind: VirtualDatabase
metadata:
name: readwrite_splitting_db
spec:
services:
- name: readwrite_splitting_db
databaseMySQL:
db: readwrite_splitting_db
host: localhost
port: 3306
user: root
password: root
readWriteSplitting: "readwrite" # 声明所需要的读写分离策略
---
# 写数据源的数据库端点配置
apiVersion: database.opensergo.io/v1alpha1
kind: DatabaseEndpoint
metadata:
name: write_ds
spec:
database:
MySQL: # 声明后端数据源的类型及相关信息
url: jdbc:mysql://192.168.1.110:3306/demo_write_ds?serverTimezone=UTC&useSSL=false
username: root
password: root
connectionTimeout: 30000
idleTimeoutMilliseconds: 60000
maxLifetimeMilliseconds: 1800000
maxPoolSize: 50
minPoolSize: 1
---
# 第一个读数据源的数据库端点配置
apiVersion: database.opensergo.io/v1alpha1
kind: DatabaseEndpoint
metadata:
name: read_ds_0
spec:
database:
MySQL: # 声明后端数据源的类型及相关信息
url: jdbc:mysql://192.168.1.110:3306/demo_read_ds_0?serverTimezone=UTC&useSSL=false
username: root
password: root
connectionTimeout: 30000
idleTimeoutMilliseconds: 60000
maxLifetimeMilliseconds: 1800000
maxPoolSize: 50
minPoolSize: 1
---
# 第二个读数据源的数据库端点配置
apiVersion: database.opensergo.io/v1alpha1
kind: DatabaseEndpoint
metadata:
name: read_ds_1
spec:
database:
MySQL: # 声明后端数据源的类型及相关信息
url: jdbc:mysql://192.168.1.110:3306/demo_read_ds_1?serverTimezone=UTC&useSSL=false
username: root
password: root
connectionTimeout: 30000
idleTimeoutMilliseconds: 60000
maxLifetimeMilliseconds: 1800000
maxPoolSize: 50
minPoolSize: 1
---
# 静态读写分离配置
apiVersion: database.opensergo.io/v1alpha1
kind: ReadWriteSplitting
metadata:
name: readwrite
spec:
rules:
staticStrategy:
writeDataSourceName: "write_ds"
readDataSourceNames:
- "read_ds_0"
- "read_ds_1"
loadBalancerName: "random"
loadBalancers:
- loadBalancerName: "random"
type: "RANDOM"

以下是一个针对某个 SQL 进行并发控制的示例。这个规则会针对 foo 应用针对 SELECT * FROM users WHERE id = ? 的 SQL 访问进行并发控制,单机并发数不超过 8。

apiVersion: traffic.opensergo.io/v1alpha1
kind: DatabaseAccessTarget
metadata:
name: target-foo-user-select-sql
spec:
sqlMatch:
- exactMatch: "SELECT * FROM users WHERE id = ?"
---
apiVersion: fault-tolerance.opensergo.io/v1alpha1
kind: ConcurrencyLimitStrategy
metadata:
name: concurrency-limit-foo
spec:
maxConcurrency: 8
limitMode: 'Local'
---
apiVersion: fault-tolerance.opensergo.io/v1alpha1
kind: FaultToleranceRule
metadata:
name: my-sql-conc-limit-rule
spec:
selector:
app: foo
targets:
- targetRef: target-foo-user-select-sql
strategies:
- name: concurrency-limit-foo

其它数据库治理能力

  • 数据库发现 (DatabaseDiscovery):数据库自动发现指的是根据数据库高可用配置,通过探测的方式感知数据源状态变化,并对流量策略做出相应的调整。比如后端数据源为 MySQL MGR,那么可以配置数据库发现类型为 MYSQL.MGR,指定 group-name,并配置相应的探测心跳节律。
  • 分布式事务配置 (DistributedTransaction):声明分布式事务相关的配置,目前支持声明事务的类型。

展望

微服务视角的数据库治理是保障微服务稳定性的重要一环。OpenSergo 社区将持续与 ShardingSphere 及 Database Mesh 社区进行合作,不断完善与丰富数据库治理标准及场景。接下来社区会开展 ShardingSphere 与 OpenSergo 的集成工作,将数据库治理 spec 落地到社区实现。

微服务治理是微服务改造深入到一定阶段之后的必经之路,是将微服务做稳做好的关键。OpenSergo 社区持续与 ShardingSphere、Database Mesh、CloudWeGo、Kratos、Spring Cloud Alibaba、Dubbo 等社区共同建设 OpenSergo 微服务治理标准,将企业与社区中微服务治理的场景与最佳实践共同提取成标准规范,也欢迎更多社区与企业一起参与 OpenSergo 微服务治理标准的共建。

OpenSergo 社区现在处于高速发展阶段,从微服务治理标准定义,到 Control Plane 的实现,再到 Java/Go/C++/Rust 等多语言 SDK 与治理功能的实现,再到各个微服务生态的整合与落地,都还有大量的演进工作,欢迎社区一起参与标准完善与代码贡献。

OpenSergo 开源贡献小组正在火热招募贡献者。如果您有时间,有热情,有意愿,欢迎联系社区加入开源贡献小组,一起共同完善 OpenSergo 和 Sentinel,一起主导微服务治理技术与标准演进。Now let's start hacking!

欢迎关注 OpenSergo 社区微信公众号,了解微服务治理社区最新动态:OpenSergo

赵奕豪

本次 OpenSergo 社区双周会(2022/11/09)的议程:

  • 同步上一周期的进展,包括 spec 建设、Control Plane && SDK 进展、社区生态接入等进展
  • 社区分享与讨论,包括 Spring Cloud Alibaba 流量染色 Demo 演示、OpenSergo 控制面设计优化讨论、开源贡献小组任务梳理与讲解等

本次 OpenSergo 社区双周会纪要:

  1. @十眠 演示了 Spring Cloud Alibaba 集成 OpenSergo 流量染色 spec 的 demo,适配模块的代码预计近期提交 PR。流量染色是流量治理领域非常重要的能力,欢迎社区一起来 review 与完善流量染色 spec: https://github.com/opensergo/opensergo-specification/pull/52

  2. 社区针对 OpenSergo 控制平面 (Control Plane) 现有的设计与问题进行了讨论。其中包括:

近期社区整理了很多 OpenSergo 控制平面相关的 good first issue,欢迎社区同学参与贡献:https://github.com/opensergo/opensergo-control-plane/issues

  1. Committer @贾江南 分享了如何快速参与到 OpenSergo 社区贡献中,并进行操作演示。大家也可以参考社区贡献指南进行入门:

GitHub discussions: https://github.com/opensergo/opensergo-specification/discussions/55


OpenSergo 社区会议每两周开展一次(一般是每两周的周三晚),时间为1小时左右。入会方式:

  • 会议形式:钉钉会议
  • OpenSergo 社区交流群(钉钉群):34826335
  • 钉钉会议入会口令:244 801 51010

欢迎社区同学参与讨论与分享。

赵奕豪

OpenSergo 是开放通用的,覆盖微服务及上下游关联组件的微服务治理项目。OpenSergo 从微服务的角度出发,涵盖流量治理、服务容错、服务元信息治理、安全治理等关键治理领域,提供一系列的治理能力与标准、生态适配与最佳实践,支持 Java, Go, Rust 等多语言生态。

Go 生态支持、流量染色最佳实践、流控降级与容错 spec 落地... OpenSergo 微服务治理社区 10月最新动态来啦,欢迎了解~

微服务治理 Spec 演进

  • 流量染色领域的最佳实践及 spec 设计正式透出。流量染色,顾名思义将请求流量进行颜色标记,并且将标记跟随着链路一直传递下去。结合流量路由与流量染色能力,我们可以实现全链路灰度、多环境隔离等场景,实现“流量泳道”的能力。流量染色是流量治理领域非常重要的能力,期待大家一起来完善场景以及实现相关能力,后续社区公众号会出专题文章解析这一块的场景与技术原理。

SDK/Control Plane 演进

  • OpenSergo Java SDK 迎来了首个发布版本 0.1.0-beta1。
  • 由社区主导贡献的 OpenSergo Go SDK 初版已形成,目前已初步具备流控降级与容错 spec 的对接能力。相关 PR: https://github.com/opensergo/opensergo-go-sdk/pull/2
  • OpenSergo Rust SDK 也在与社区规划中,欢迎 Rust 大佬一起参与贡献~
  • 性能与稳定性优化:社区针对同个应用多个框架分别对接了 OpenSergo SDK 的情况下,gRPC client 的复用机制进行了一些讨论与设计,预计会在11月对 Java/Go SDK 的实现进行完善。相关讨论可见:https://github.com/opensergo/opensergo-java-sdk/issues/8

社区生态演进

  • 社区完成 Spring Cloud Alibaba 流量路由能力与 OpenSergo 流量路由 spec 的初步对接,集成模块预计11月发布正式版;后续 Dubbo, Kratos, CloudWeGo 等社区也会一起参与到流量路由能力建设及 spec 对接中。
  • 随着流量治理组件 Sentinel Java 1.8.6 版本正式发布,Sentinel OpenSergo 流量治理数据源也迎来了首个版本。借助 sentinel-datasource-opensergo 数据源模块,开发者可以很方便地将 Kubernetes 集群下的应用通过 Sentinel 接入到 OpenSergo 控制面,然后通过统一的 OpenSergo CRD 对异构化的服务进行统一的流控降级与容错治理,原生支持 20+ 框架集成。文档可以参考:https://sentinelguard.io/zh-cn/docs/opensergo-data-source.html
  • 随着 OpenSergo Go SDK 初版成形,Sentinel Go 集成 OpenSergo 的数据源模块也已形成初版,目前支持流控、熔断、并发控制等规则 spec。该集成模块可作为 Go 框架对接 OpenSergo Go SDK 的指导示例,相关 PR 见:https://github.com/alibaba/sentinel-golang/pull/489

社区开发者

  • 本月 OpenSergo 社区迎来了新的一位 committer 贾江南(GitHub ID: @jnan806)。贾江南同学在过去的一段时间,积极、活跃地参与到 OpenSergo 社区讨论与贡献中,从0到1完成了 OpenSergo Go SDK 的初版实现,并且在 Go 生态适配、proto 管理、Java SDK 等方面都有着不少贡献,符合社区对 committer 持续贡献的期望。恭喜江南,期待未来持续贡献!

OpenSergo 开源贡献小组正在火热招募贡献者。如果您有时间,有热情,有意愿,欢迎联系社区加入开源贡献小组,一起共同完善 OpenSergo 和 Sentinel;对于核心贡献者,我们会提名为 committer,一起主导微服务治理技术与标准演进,并且有持续的激励机制。Now let's start hacking!

赵奕豪

本次 OpenSergo 社区双周会(2022/10/26)的议程:

  • 同步上一周期的进展,包括 spec 建设、Control Plane && SDK 进展、社区生态接入等进展
  • 宣布 Committer 晋升动态
  • 社区分享与讨论,包括流量染色 spec 与实践分享、Sentinel+OpenSergo 展望、多语言生态讨论等

本周 OpenSergo 社区双周会纪要:

  1. 经过全体 committer 提名与讨论,社区很高兴地宣布,贾江南(GitHub ID: @jnan806)正式晋升为 OpenSergo 社区 committer。贾江南同学在过去的一段时间,积极、活跃地参与到 OpenSergo 社区讨论与贡献中,从0到1完成了 OpenSergo Go SDK 的初版实现,并且在 Go 生态适配、proto 管理、Java SDK 等方面都有着不少贡献,符合社区对 committer 持续贡献的期望。恭喜江南,期待未来持续贡献!

  2. @宿何 分享 Sentinel 近期社区动态及 Sentinel 2.0+OpenSergo 的演进。本周随着 Sentinel 1.8.6 版本正式发布,Sentinel OpenSergo 流量治理数据源也迎来了首个版本。借助 sentinel-datasource-opensergo 数据源模块,开发者可以很方便地将 Kubernetes 集群下的应用通过 Sentinel 接入到 OpenSergo 控制面,然后通过统一的 OpenSergo CRD 对异构化的服务进行统一的治理规则管控。后续社区会出专题教程来指导大家接入,简短文档可以参考:https://sentinelguard.io/zh-cn/docs/opensergo-data-source.html

  3. OpenSergo Java SDK 也迎来了首个发布版本 0.1.0-beta1: https://github.com/opensergo/opensergo-java-sdk/releases/tag/v0.1.0-beta1

  4. @十眠 分享了流量染色这一块领域的最佳实践及 spec 设计。流量染色,顾名思义将请求流量进行颜色标记,并且将标记跟随着链路一直传递下去。结合流量路由与流量染色能力,我们可以实现全链路灰度、多环境隔离等场景,实现“流量泳道”的能力。流量染色是流量治理领域非常重要的能力,社区正在形成初版文档,稍后会提交 PR 请大家一起进行完善。

  5. 社区对 OpenSergo 多语言生态进行简短的讨论。除了 Java 和 Go 生态之外,Rust 生态也是社区未来期望建设的重要生态,期待大家一起共建 Rust SDK。

GitHub discussions: https://github.com/opensergo/opensergo-specification/discussions/50


OpenSergo 社区会议每两周开展一次,时间为1小时左右。入会方式:

  • 会议形式:钉钉会议
  • OpenSergo 社区交流群(钉钉群):34826335
  • 钉钉会议入会口令:244 801 51010

欢迎社区同学参与讨论与分享。