介绍

• Zipkin 为一个分布式的调用链跟踪系统 (distributed tracing system) , 设计来源于 google dapper paper
• 官方网站

快速入门

• 安装方式一：使用 zipkin 官方提供的 jar 启动服务
  zipkin 官方提供了一个现成的使用 springboot 写的 zipkin 服务端，客户端的链路监控报告可以通过多种方式（下文会讲解具体的方式）向服务端发送报告。

• 系统需要安装 java8

• 下载地址

  配置详解
  
  查看源码可知其有 4 种持久化方式，本文选择使用最熟悉的 mysql 持久化链路调用信息。

首先建立数据库：
默认情况下 zipkin 运行时数据保存在内存中，重启数据会丢失
数据库脚本下载

查看与 mysql storage 相关的配置

1
2
3
4
5
6
7
8
9
10
11
12
13

@ConfigurationProperties("zipkin.storage.mysql")
public class ZipkinMySQLStorageProperties implements Serializable { // for Spark jobs
  private static final long serialVersionUID = 0L;

  private String host = "localhost";
  private int port = 3306;
  private String username;
  private String password;
  private String db = "zipkin";
  private int maxActive = 10;
  private boolean useSsl;
	...
}

所以，我们使用 mysql 作为持久化策略，启动服务端的脚本也就有了

1

java -server -jar zipkin-server-1.26.0-exec.jar --zipkin.storage.type=mysql --zipkin.storage.mysql.host=localhost --zipkin.storage.mysql.port=3306 --zipkin.storage.mysql.username=root --zipkin.storage.mysql.password=root --zipkin.storage.mysql.db=zipkin

• 安装方式二
  springcloud 官方按照传输方式分成了三种启动服务端的方式：Sleuth with Zipkin via HTTP，Sleuth with Zipkin via Spring Cloud Stream，Spring Cloud Sleuth Stream Zipkin Collector。只需要添加相应的依赖，之后配置相应的注解，如 @EnableZipkinStreamServer 即可。具体配置参考 Spring Cloud 官方文档

项目中，我们使用第一种作为服务端的启动方式，使用 mysql 作为持久化方案

• 初级 — 初

掌握 java 基础，熟悉常用类库。理解 java web 中的 servlet，jsp，并了解常用的框架对 java web 的封装原理，能够借助框架完成增删改查功能。理解数据库在 web 开发中的地位。

• 初级 — 中

  理解 java 中较为高级的特性，如反射，动态代理，JVM，内存模型，多线程等等。熟练使用框架，对框架中遇到的 bug，能够借助日志和搜索引擎分析出问题的原因。在团队中，能够独立完成普通后台业务功能的开发。了解数据库的高级特性，如索引，存储引擎等等。

Cross Products

之前提到“Cross Products”一词，其实就是一个 join 操作（译者注：可以理解为笛卡尔积）。想象一下，火灾报警示例的数据与以下规则结合使用，其中没有字段约束：

1
2
3
4
5
6
7

rule "Show Sprinklers" when
    $room : Room()
    $sprinkler : Sprinkler()
then
    System.out.println("room:" + $room.getName() +
                        "sprinkler:" + $sprinkler.getRoom().getName() );
end

在 SQL 术语中，这就像是执行了 select * from Room, Sprinkler，Sprinkler 表中的每一行将与 Room 表中的每一行相连接，从而产生以下输出：

Methods vs Rules

人们经常混淆方法和规则，初学者经常会问：“我如何理解规则的含义？“ 在最后一节之后，你会对规则的使用得心应手，答案也变得显而易见的，但在这之前，先让我们总结一下方法判断和规则的差异。

1
2
3
4
5

public void helloWorld(Person person) {
    if (person.getName().equals("Chuck") ) {
        System.out.println("Hello Chuck");
    }
}

stateless session 无状态会话

Drools 规则引擎中有如此多的用例和诸多功能，它变得令人难以置信。不过不用担心，复杂性是分层的，你可以用简单的用例来逐步了解 drools。

无状态会话，不使用推理，形成最简单的用例。无状态会话可以被称为函数传递一些数据，然后再接收一些结果。无状态会话的一些常见用例有以下但不限于：

1. 验证
   这个人有资格获得抵押吗？
2. 计算
   计算抵押保费。
3. 路由和过滤
   将传入的邮件（如电子邮件）过滤到文件夹中。
   将传入的邮件发送到目的地。

所以让我们从使用驾驶执照应用程序的一个非常简单的例子开始吧。

1
2
3
4
5
6

public class Applicant {
    private String name;
    private int age;
    private boolean valid;
    // getter and setter methods here
}

现在我们有了我们的数据模型，我们可以写出我们的第一个规则。我们假设应用程序使用规则来拒绝不符合规则的申请。由于这是一个简单的验证用例，我们将添加一条规则来取消任何 18 岁以下的申请人的资格。

1
2
3
4
5
6
7
8

package com.company.license

rule "Is of valid age"
when
    $a : Applicant(age < 18)
then
    $a.setValid(false);
end

stateful session 有状态会话

有状态会话长期存在，并允许随着时间的推移进行迭代更改。 有状态会话的一些常见用例包括但不限于：

1. 监测
   半自动买入股票市场监控与分析。
2. 诊断
   故障查找，医疗诊断
3. 物流
   包裹跟踪和送货配置
4. 合规
   验证市场交易的合法性。

与无状态会话相反，必须先调用 dispose() 方法，以确保没有内存泄漏，因为 KieBase 包含创建状态知识会话时的引用。 由于状态知识会话是最常用的会话类型，所以它只是在 KIE API 中命名为 KieSession。 KieSession 还支持 BatchExecutor 接口，如 StatelessKieSession，唯一的区别是 FireAllRules 命令在有状态会话结束时不被自动调用。

我们举例说明了用于提高火灾报警器的监控用例。 只使用四个类，我们假设 Room 代表房子里的房间，每个 Room 都有一个喷头 Sprinkler。 如果在房间里发生火灾，我们用一个 Fire 实例来表示, 用 Alarm 代表警报 。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

public class Room {
    private String name
    // getter and setter methods here
}

public class Sprinkler {
    private Room room;
    private boolean on;
    // getter and setter methods here
}

public class Fire {
    private Room room;
    // getter and setter methods here
}

public class Alarm {
}

在上一节无状态会话中介绍了插入和匹配数据的概念。 这个例子假设每个对象类型的都是单个实例被插入的，因此只使用了字面约束。 然而，房子有许多房间，因此 rules 必须表达实体类之间的关系，例如在某个房间内的喷洒器。 这最好通过使用绑定变量作为模式中的约束来完成。 这种“加入”过程产生了所谓的“cross products”，这在下一节中将会介绍。

环境准备

采用三台阿里云服务器作为测试
10.19.52.8 部署网关应用 -gateway
10.19.52.9, 10.19.52.10 部署用于测试的业务系统

压测工具准备

选用 ab 作为压力测试的工具，为了方便起见，直接将 ab 工具安装在 10.19.52.8 这台机
测试命令如下：

1

ab -n 10000 -c 100 http://10.19.52.8:8080/hello/testOK?access_token=e0345712-c30d-4bf8-ae61-8cae1ec38c52

其中－n 表示请求数，－c 表示并发数, 上面一条命令也就意味着，100 个用户并发对 http://10.19.52.8/hello/testOK 累计发送了 10000 次请求。

服务器, 网关配置

由于我们使用的 tomcat 容器，关于 tomcat 的一点知识总结如下：

前言

Zuul 是 Netflix 提供的一个开源组件, 致力于在云平台上提供动态路由，监控，弹性，安全等边缘服务的框架。也有很多公司使用它来作为网关的重要组成部分，碰巧今年公司的架构组决定自研一个网关产品，集动态路由，动态权限，限流配额等功能为一体，为其他部门的项目提供统一的外网调用管理，最终形成产品 (这方面阿里其实已经有成熟的网关产品了，但是不太适用于个性化的配置，也没有集成权限和限流降级)。

不过这里并不想介绍整个网关的架构，而是想着重于讨论其中的一个关键点，并且也是经常在交流群中听人说起的：动态路由怎么做？

再阐释什么是动态路由之前，需要介绍一下架构的设计。

传统互联网架构图

上图是没有网关参与的一个最典型的互联网架构 (本文中统一使用 book 代表应用实例，即真正提供服务的一个业务系统)

加入 eureka 的架构图

book 注册到 eureka 注册中心中，zuul 本身也连接着同一个 eureka，可以拉取 book 众多实例的列表。服务中心的注册发现一直是值得推崇的一种方式，但是不适用与网关产品。因为我们的网关是面向众多的 ** 其他部门 ** 的 ** 已有 ** 或是 ** 异构架构 ** 的系统，不应该强求其他系统都使用 eureka，这样是有侵入性的设计。

最终架构图

要强调的一点是，gateway 最终也会部署多个实例，达到分布式的效果，在架构图中没有画出，请大家自行脑补。

本博客的示例使用最后一章架构图为例，带来动态路由的实现方式，会有具体的代码。

前言

最近正在为本科论文的事感到心烦，一方面是在调研期间，发现大部分的本科论文都是以 MVC 为架构，如果是使用了 java 作为开发语言则又是千篇一律的在使用 SSH，二方面是自己想就微服务，分布式方面写一篇论文，讲述一些技术点的实现，和一些中间件的使用，看到如八股文般的模板格式.. 不免让人望文生怯。退一步，投入模板化 ssh-web 项目的怀抱，落入俗套，可以省去自己不少时间，因为在外实习，琐事并不少；进一步，需要投入大量时间精力去研究，而且不成体系，没有论文参考。

突然觉得写博客，比写论文爽多了，可以写自己想写的，记录自己最真实的想法。可能会逐渐将之前博客维护的自己的一些想法，纳入到本科论文中去。

经典限流算法

前言

被群里的好友安利了一发，周日跑去参加了一个技术讲座《云上开发与运维最佳实践》，听完两个人的演讲之后才发现主题竟然是讲运维，好在有一个人干货不少，在此记录下所得。简单追溯了一下这个 DevOps 才发现并不是一个新的概念，早在 2010 年就能看到有相关的人在追捧这个概念了。DevOps 就是开发（Development）和运维（Operations）这两个领域的合并。（如果没错的话，DevOps 还包括产品管理、QA、winces 甚至销售等领域）。这种理念和现如今流行的微服务架构以及分布式特性的相关理念不谋而合。这篇文章主要就是转载记录了当时又拍云运维总监的演讲稿。

DevOps 的八荣八耻