亲宝软件园·资讯

展开

Go chassis云原生微服务框架

二手雄狮 人气:0

什么是Go chassis

go chassis是一个go语言微服务开发框架,专注于云原生应用的开发主要的使用场景是云服务开发。go chassis将云服务开发过程中沉淀的能力融入到了开发框架中,以帮助开发团队快速编写云原生应用。

文章目标

本文介绍我们的设计理念和目标,为何go chassis会诞生。后面的系列文章会着重介绍使用方法,项目实战。对于微服务架构模式,云原生要素,为什么选择go语言等将不再赘述。

诞生背景

公司开发云服务,要构建健壮,韧性,安全,高可靠的云服务,必然有大量基础能力需要编写,为了加速开发,我们将这些能力便沉淀在了该框架中。为什么呢?

我们希望加速每一个组件也就是微服务的开发速度。有的人看到的只是冰山一角,真的要达成微服务架构模式的愿景,其实需要繁重的工作量。就像冰山那样,我们要将通用能力沉淀下去,能够复用。如果让各个业务团队同时照顾冰山上下,各自开发各自的,那结果将是灾难性的,企业用人成本极高。

在业务交付的过程中,各个云团队有大量的管理服务需要对接,每个团队都在写重复的代码,通过框架能力,将交付职责分离,减少开发成本:

如何快速开发一个微服务

可以跟随这个文档体验。

github.com/go-chassis/…

统一治理和协议模型

我们使用Invocation概念来统一协议描述,当协议请求到来后,go chassis会把request转换为Invocation进行治理(如负载均衡,限流,熔断,重试,金丝雀发布等),这样就可以允许任意的协议接入到go chassis,并无缝使用go chassis提供的核心功能,当前默认提供原生grpc和http两种协议的接入。

为什么会有这样的设计呢?

可扩展的处理链条:handler chain as middleware

我们以Java为例,大家在写一个拦截器或者过滤器的时候可以对请求进行处理,处理完,这个拦截器的的执行过程就结束了,那么如何达成以下目标?

1.跟踪业务执行结果指标,比如http状态码,并导出他们让prometheus收集。

2.跟踪关键的业务执行结果,审计这些信息。比如请求返回的一些结果信息

3.分布式调用链追踪,end span必须等到请求返回才能拿到。

Java的答案很简单,注解。那么go呢?

我们引入了handler chain编程模型,chain中每个handler都可以拿到后面的handler的执行结果,包括业务代码的执行结果。

看下接口定义

type Handler interface {
	Handle(*Chain, *invocation.Invocation, invocation.ResponseCallBack)
	Name() string
}
// ResponseCallBack process invocation response
type ResponseCallBack func(*Response)

ResponseCallBack用于接受后置handler返回的结果,所以每一个handler处理时都可以按需定义自己的ResponseCallBack来获取后面handler甚至是业务逻辑代码的执行结果。帮助通用逻辑(即中间件)和业务逻辑彻底解耦。可以看下现在已经支持的中间件,无论限流,熔断,负载均衡,认证鉴权,审计,我们都用此机制实现:

go-chassis.readthedocs.io/en/latest/m…

将公司全部的工具链,服务治理手段,安全合规等都落入到处理链中,可快速加快研发速度,并统一规范,减少管理负担。

不只是API,通过配置简化开发过程

只举2个例子

监控

减少让开发者自己调用API的过程,将他们简化为配置项

例如可观察:

引入一行代码

import _ github.com/go-chassis/go-chassis/v2/middleware/monitoring

加上配置

handler:
  chain:
    Provider:
      default: monitoring

就可以在服务端进行监控,导出请求数,延迟等指标,大大加速开发人员效率

# HELP request_count 
# TYPE request_count counter
request_count{app="default",env="",instance="",service="servicecomb-kie",version="0.1.0"} 14
# HELP request_process_duration 
# TYPE request_process_duration summary
request_process_duration{app="default",env="",instance="",service="servicecomb-kie",version="0.1.0",quantile="0.5"} 3
request_process_duration{app="default",env="",instance="",service="servicecomb-kie",version="0.1.0",quantile="0.9"} 80
request_process_duration{app="default",env="",instance="",service="servicecomb-kie",version="0.1.0",quantile="0.99"} 80
request_process_duration_sum{app="default",env="",instance="",service="servicecomb-kie",version="0.1.0"} 315
request_process_duration_count{app="default",env="",instance="",service="servicecomb-kie",version="0.1.0"} 14

需要自定义指标:

err := metrics.CreateCounter(metrics.CounterOpts{
		Name:   “user_login”,
		Labels: labelsSlice,
	})
metrics.CounterAdd(“user_login”, 1, labelMap)

可信软件

公司对软件质量的高要求,需要我们编写大量的基础代码。我们也将通用的部分都落地到了框架中,通过简单的配置文件启用,不再需要不同团队重复编写代码

servicecomb:
  transport:
    failure:
      rest: http_500,http_502 #统计错误率时,例如只把500和502作为错误
    maxIdleCon:
      rest: 1024
    maxBodyBytes:
      rest: 20 #只需要指定我的服务能接受的body体大小,访问的超时时间即可不再需要各个团队维护代码。
    maxHeaderBytes:
      rest: 1 #限制http header大小
    timeout: #限制客户端超时
      rest: 30s

插件化

为了应对不同业务诉求,我们总是要考虑“可替换性”。而这个的优先级总是大于“可复用性”。这就是go chassis的插件理念。基本所有的重要组件都是插件化的,框架已经定义好标准接口,只需要开发者实现好,注册到框架中,就可以在配置文件中配置并生效了,业务开发者是完全不感知的。可以参考我们对quota组件的扩展过程,他负责资源的配额管理

go-chassis.readthedocs.io/en/latest/d…

后续将详细剖析go chassis的内部设计和特性使用。

在下一篇文章中,我将讲述go chassis如何快速开发出一个微服务。由于是系列文章,随着文章不断更新,如果有期望了解的话题,内容可以留言反馈,我会加入到后续文章中。

项目地址:

github.com/go-chassis/…

目前的用户:

加载全部内容

相关教程
猜你喜欢
用户评论