木之陽兮 卿云烂兮

背景说明

API网关的作用不言而喻，在微服务架构下多个微服务接口需要一个网关来协调，从而实现拦截器、代理转发、流量控制、负载均衡、熔断等机制；有许多成熟的第三方网关中间件，比如Zuul, Kong等，如果没有一个可配置化的方式去管理路由，则每新增一个接口就要到API服务中增加相应的代码，从而达到代理转发请求到后端服务的目的，导致开发人员要分别维护微服务和API网关两套代码，繁琐而低效。

当然，在不想引入第三方网关组件的情况下，我们还是可以自己来手写一个简单的网关组件，从而实现配置化的路由管理功能，大致思路如下：

1. 路由配置：通过配置文件管理微服务的路由
2. 实现代理：用户请求 -> 输入拦截 -> 服务发现 -> 向上游转发请求 -> 输出拦截 -> 返回信息
3. 监听路由：通过Flask.route函数注册路由，绑定每个路由的代理

DAG与拓扑排序的应用

在普通的程序设计中，当一个或一批事件完成时触发下一个或下一批事件的开始，通常我们会设计一个“围栏”，使用观察者模式或监听器模式对事件进行回调、观察并控制围栏的开关（比如java中用到的CountDownLatch），当事件越来越多、触发条件越来越复杂的时候，这种模式就愈发显得力有不逮，特别是在并发控制的表现中。

最近在开发一个工具时遇到了一个根据输入参数渲染yml文件的问题:

• 需要在yaml样板的指定的位置上填入指定的值，yml样板随时可能更新
• 需要根据输入参数以及对应字段的生成规则动态生成对象、数组（长度不固定）、字符串等各种类型的值

这种情况下，最先想到的就是直接使用占位符或者模板语言。但是经过实践发现了两个问题：

1. yaml文件样板更新时，必须从旧模板上的迁移占位符，增大了维护的负担（特别是生产中用到的yaml文件通常有上千行）
2. 生成规则不固定，需要在工具中硬编码指定某些特定属性的生成规则，使业务逻辑高度耦合

所以使用占位符或者模板语言直接作用在yaml样板上思路就是错的，我们应该通过一个中间的配置来定义yml文件的生成规则，这样才能使工具和业务逻辑解耦合，并且降低维护的难度。

TL;DR

简单记录一下实践过程，并结合对etcd/raft源码的阅读，总结一下自己的缺陷以及etcd中可借鉴的思想。本文没有介绍raft算法如何实现，关于raft算法的介绍可直接参考以下文档：

1. 《The Raft Consensus Algorithm》
2. 《In Search of an Understandable Consensus Algorithm》
3. 《Raft一致性算法论文：探索一种易理解的一致性算法 中文译文》
4. 《CoreOS 实战：剖析 etcd》
5. 《etcd/raft design》

Initially, we spoke about an “index” being similar to a “database” in an SQL database, and a “type” being equivalent to a “table”. This was a bad analogy that led to incorrect assumptions. [ref]

本文参考《Elasticsearch权威指南》

基础概念

如果使用过glances，如果有一颗geek的心的话，一定会觉得不但酷炫而且十分实用。不过如果想观察一个程序从运行开始到结束的cpu占用率怎么办？好办，利用python的psutil异步观察就行。

介绍一下放在github上的一个项目： oscillo

github 源码地址： suniper/plum-mesh-agent

以之前完成的开源项目suniper-pma的代码实例为例，阐述一下我的服务发现和负载均衡框架是如何实现的 (注：下文中为了更好理解，所贴的代码在源代码的基础上做了一些修改)