Grafana has been adopted as a common monitoring dashboard by more and more companies, in many cases, when operators need to create dashboard repeatedly they either choose to use template variables or create dashboards one by one. I think it’s very useful to leverage the Grafana API to generate the monitoring dashboards automatically from template.

Spinnaker doesn’t support installation on CentOS machine, this article introduces how to use Docker to install Spinnaker components on CentOS directly.

As we know, according to the spinnaker’s official documentation, spinnaker provides a tool for installing the spinnaker cluster in Kubernetes cluster or debian/ubuntu bare metal machine, but there’s not an option to install it on CentOS or other common operating systems. Althogh the spinnaker provides a way to start Spinnaker with Docker Compose, but it’s out of date. So I created a new docker-compose project to quickstart a spinnaker cluster on any kind of os.

Maintain the swagger documentation by Swagger Editor and then you can use the yaml files to generate online swagger documentation easily with Spring boot.

I’ve joined my first Hackathon and worked on a project about using Spinnaker as CI/CD tool within company. The biggest challenge is to install Spinnaker on CentOS 7 with docker-compose.

Why Spinnaker?

• Spinnaker is dedicated to deploy services across multiple cloud providers and the integration with AWS, GCP, Azure is out of box.
• It’s focused on deploy stably, support full control of workflow, developers can customize the deployment flow to improve the quality of deployment, also it’s automatic.
• You will have a Web UI.

Envoy has become more and more popular, the basic functionality is quite similar to Nginx, working as a high performace Web server, proxy. But Enovy imported a lot of features that was related to SOA or Microservice like Service Discovery, Circuit Breaker, Rate limiting and so on.

A lot of developers know the roles envoy plays, and the basic functionality it will implement, but don’t know how it organize the architecture and how we understand its configuration well. For me, it’s not easy to understand envoy’s architecture and its configuration since it has a lot of terminology, but if the developer knew how the user traffic goes, he could understand the design of envoy.

Istio has been adopted as a common implementation of service mesh, since more and more companies want to bring Istio into production, the version control of Istio seems a significant problem to solve.

Version control is necessary as Istio components can be treated as the equivalent RPC services like our business services, we need to have an understanding of which version we are using now and what does the next version bring. And some Istio components can cooperate with the others, if we need to upgrade one component we need to upgrade the other components too.

Although the Istio community provides the Istio upgrade method, we don’t actually want to upgrade such a whole thing in one move, it influences so much that we don’t want to risk.

micro是基于golang的微服务框架，之前华尔街见闻架构升级中谈到了我们是基于go-micro的后端架构，随着我们对服务网格的调研、测试和实施，为了打通不同语言之间的服务调用，我们选择了gRPC作为服务内部的通用协议。

go-micro框架的架构非常具有拓展性，它拥有自己的RPC框架，通过抽象codec,transport,selector等微服务组件，你既可以使用官方实现的各种插件go-plugins进行组装，又可以根据实际的情况实现自己的组件。然而，我们打算利用服务网格的优势，将微服务的基础组件下沉到基础设施中去，将组件代码从代码库中剥离开来。

这样一来，我们相当于只需要最简的RPC框架，只需要服务之间有统一、稳定、高效的通信协议，由于micro在我们新架构中略显臃肿，于是我们选择逐渐剥除micro。还有一个重要原因，我们选择的服务网格方案是istio，它的代理原生支持gRPC，而micro只是将gRPC当做transport层，相当于复写了gRPC的服务路由逻辑，这样有损于istio的一些特性，譬如流量监控等功能。

出于这些考虑，第一步需要将micro改成纯gRPC模式，这里的改造部分我们考虑只应该去更改基础库的代码，而尽量不要使业务代码更改，减少对已有逻辑的影响，和一些软性的譬如开发人员的工作量。

gRPC is a well-known RPC protocol and a lot of companies adopted it as an internal communication protocol because of its robustness and stability. To use it more efficiently, I’ve done some experiments about how to maximize the gRPC client concurrency.