Go 云原生应用实战系列（一）
什么是Go chassis
go chassis是一个go语言微服务开发框架，专注于云原生应用的开发，我们主要的使用场景是云服务开发。我们将自己在云服务开发过程中沉淀的能力融入到了开发框架中，以帮助开发团队快速编写云原生应用。
文章目标
本文介绍我们的设计理念和目标，为何go chassis会诞生。后面的系列文章会着重介绍使用方法，项目实战。对于微服务架构模式，云原生要素，为什么选择go语言等将不再赘述。
诞生背景
公司开发云服务，要构建健壮，韧性，安全，高可靠的云服务，必然有大量基础能力需要编写，为了加速开发，我们将这些能力便沉淀在了该框架中。为什么呢？
我们希望加速每一个组件也就是微服务的开发速度。有的人看到的只是冰山一角，真的要达成微服务架构模式的愿景，其实需要繁重的工作量。就像冰山那样，我们要将通用能力沉淀下去，能够复用。如果让各个业务团队同时照顾冰山上下，各自开发各自的，那结果将是灾难性的，企业用人成本极高。
在业务交付的过程中，各个云团队有大量的管理服务需要对接，每个团队都在写重复的代码，通过框架能力，将交付职责分离，减少开发成本：
如何快速开发一个微服务
可以跟随这个文档体验。
https://github.com/go-chassis/go-chassis/edit/master/docs/getstarted/install.md
统一治理和协议模型
我们使用Invocation概念来统一协议描述，当协议请求到来后，go chassis会把request转换为Invocation进行治理（如负载均衡，限流，熔断，重试，金丝雀发布等），这样就可以允许任意的协议接入到go chassis，并无缝使用go chassis提供的核心功能，当前默认提供原生grpc和http两种协议的接入。
为什么会有这样的设计呢？
-
每个协议层的优化空间非常大，用户态到内核态的调用速度本来就相对内部代码来说是很慢的，优化这一层代码很重要，RPC怎么也比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甚至是业务逻辑代码的执行结果。帮助通用逻辑（即中间件）和业务逻辑彻底解耦。可以看下现在已经支持的中间件，无论限流，熔断，负载均衡，认证鉴权，审计，我们都用此机制实现：
https://go-chassis.readthedocs.io/en/latest/middleware.html
将公司全部的工具链，服务治理手段，安全合规等都落入到处理链中，可快速加快研发速度，并统一规范，减少管理负担。
不只是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组件的扩展过程，他负责资源的配额管理
https://go-chassis.readthedocs.io/en/latest/dev-guides/backends.html
后续
我将详细剖析go chassis的内部设计和特性使用。
在下一篇文章中，我将讲述go chassis如何快速开发出一个微服务。由于是系列文章，随着文章不断更新，如果有期望了解的话题，内容可以留言反馈，我会加入到后续文章中。
关于项目地址：
https://github.com/go-chassis/go-chassis
目前的用户：
-
趣头条
-
边缘计算：http://kubeedge.io/
-
ServiceComb: https://github.com/apache/servicecomb-service-center 等多个go语言开发项目