What is Go Chassis

Go Chassis is a go language micro-service development framework, focusing on the development of cloud native applications. Our main application scenario is cloud service development. We built our capabilities from cloud service development into our development framework to help development teams quickly write cloud-native applications.

The article goal

This article introduces our design concept and goal, and why go Chassis was born. The following series of articles will focus on the use of methods, project actual combat. As for the micro service architecture pattern, cloud native elements, why choose go language will not be repeated.

The background

Companies developing cloud services need to build robust, resilient, secure, and highly reliable cloud services. There are a lot of basic capabilities that need to be written. In order to accelerate development, we have deposited these capabilities in this framework.

How to develop a microservice quickly

You can play along with this document.

Github.com/go-chassis/…

Unified governance and protocol model

The Concept of Invocation is used to unify the protocol description. When the protocol request comes, the Go Chassis will convert the Request to the Invocation for management (such as load balancing, flow limiting, fuse, retry, canary release, etc.), so that any protocol can be connected to the Go Chassis. In addition, the core functions provided by Go Chassis are seamlessly used. Currently, the access of native GRPC and HTTP is provided by default.

Why is there such a design?

  1. There is a lot of room for optimization at each protocol layer. The speed of user-to-kernel calls is slow compared to internal code, so it is important to optimize this layer of code. RPC is better than HTTP anyway.

  2. Different departments may have proprietary agreements, so service governance is left to the core framework. It is up to the business unit to independently develop or integrate existing protocols. When you find that different departments within the company are developing their own protocols and doing their own service governance, it’s very difficult to unify the business into one architecture, one tool chain.

Handler chain as middleware

Using Java as an example, you can write an interceptor or filter to process the request. After processing, the execution of the interceptor is finished. So how to achieve the following goals?

1. Track performance metrics, such as HTTP status codes, and export them for Prometheus to collect.

2. Track key business execution results and audit these information. For example, some result information returned by the request

3. Distributed call chain tracing, end Span must wait until the request returns.

  1. When a client invokes a remote service, there are also intermediate processes, such as client load balancing and request retries, that cannot be coupled in the business code

Java’s answer is simple: annotations. What about go?

We introduced the handler chain programming model. Each handler in the chain can get the execution results of subsequent handlers, including the execution results of business codes.

Take a look at the interface definition

type Handler interface {
	Handle(*Chain, *invocation.Invocation, invocation.ResponseCallBack)
	Name() string
}

// ResponseCallBack process invocation response
type ResponseCallBack func(*Response)
Copy the code

ResponseCallBack is a ResponseCallBack that receives the return of a subsequent handler, so each handler can define its own ResponseCallBack to retrieve the result of subsequent handler or even business logic code execution. Help fully decouple generic logic (i.e., middleware) from business logic. We can take a look at the middleware currently supported. We use this mechanism to achieve flow limiting, fusing, load balancing, authentication and auditing:

Go – chassis. Readthedocs. IO/en/latest/m…

All of the company’s tool chain, service governance means, safety compliance and so on are put into the processing chain, which can quickly speed up research and development, unify and standardize, and reduce the management burden.

Not just apis, but configuration to simplify the development process

Just two examples

monitoring

Reduce the need for developers to make their own API calls and simplify them to configuration items

For example:

Introducing a line of code

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

Combined with the configuration

handler:
  chain:
    Provider:
      default: monitoring
Copy the code

It can be monitored on the server side, exporting the number of requests, latency and other indicators, greatly speeding up developer efficiency

# HELP request_count # TYPE request_count counter Request_count {app = "default", env = "", the instance =", "service =" servicecomb - kie ", version = "0.1.0 from}" 14 # HELP request_process_duration # TYPE request_process_duration summary Request_process_duration {app = "default", env = "", the instance =", "service =" servicecomb - kie ", version = "0.1.0 from", quantile = "0.5"} 3 Request_process_duration {app = "default", env = "", the instance =", "service =" servicecomb - kie ", version = "0.1.0 from", quantile = "0.9"} 80 Request_process_duration {app = "default", env = "", the instance =", "service =" servicecomb - kie ", version = "0.1.0 from", quantile = "0.99"} 80 Request_process_duration_sum {app = "default", env = "", the instance =", "service =" servicecomb - kie ", version = "0.1.0 from"} 315 Request_process_duration_count {app = "default", env = "", the instance =", "service =" servicecomb - kie ", version = "0.1.0 from}" 14Copy the code

Need to customize indicators:

Err := metrics.CreateCounter(metrics.CounterOpts{Name: "user_login", Labels: }) metrics.CounterAdd(" user_login ", 1, labelMap)Copy the code

Trusted software

The company’s high requirements for software quality require us to write a lot of basic code. We’ve also landed common parts in the framework, enabling them with simple configuration files, eliminating the need for multiple teams to write code

Servicecomb: transport: failure: rest: http_500,http_502 # Count error rates, for example, only 500 and 502 as errors maxIdleCon: rest: 1024 maxBodyBytes: Rest: 20 # Just specify the body size my service will accept, and the timeout for access will no longer require the teams to maintain the code. MaxHeaderBytes: rest: 1 # Limit HTTP header size timeout: # Limit client timeout REST: 30sCopy the code

pluggable

We always have to consider “replaceable” in order to respond to different business needs. This always takes precedence over “reusability”. That’s the idea behind the Go Chassis plug-in. Basically all the important components are plug-in, the framework has defined the standard interface, only need developers to implement, register in the framework, can be configured in the configuration file and take effect, business developers are completely unaware. See our extension process for the Quota component, which is responsible for resource quota management

Go – chassis. Readthedocs. IO/en/latest/d…

subsequent

I will analyze the internal design and feature use of Go Chassis in detail.

In the next post, I’ll talk about how go Chassis can quickly develop a microservice

About the project address:

Github.com/go-chassis/…

Current Users:

  • Interesting headline

  • Edge calculation: kubeed.io /

  • ServiceComb: github.com/apache/serv… Several go language development projects