前言

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 的八荣八耻

前言

最近在做接口限流时涉及到了一个有意思问题，牵扯出了关于 concurrentHashMap 的一些用法，以及 CAS 的一些概念。限流算法很多，我主要就以最简单的计数器法来做引。先抽象化一下需求：统计每个接口访问的次数。一个接口对应一个 url，也就是一个字符串，每调用一次对其进行加一处理。可能出现的问题主要有三个：

1. 多线程访问，需要选择合适的并发容器
2. 分布式下多个实例统计接口流量需要共享内存
3. 流量统计应该尽可能不损耗服务器性能

但这次的博客并不是想描述怎么去实现接口限流，而是主要想描述一下遇到的问题，所以，第二点暂时不考虑，即不使用 redis。

说到并发的字符串统计，立即让人联想到的数据结构便是 ConcurrentHashpMap<String,Long> urlCounter;

对 java 中 volatile 关键字的描述，主要是 可见性 和 有序性 两方面。

一个很广泛的应用就是使得多个线程对共享资源的改动变得互相可见，如下：

并发编程模型的分类

在并发编程中，我们需要处理两个关键问题：线程之间如何通信及线程之间如何同步（这里的线程是指并发执行的活动实体）。通信是指线程之间以何种机制来交换信息。在命令式编程中，线程之间的通信机制有两种：共享内存和消息传递。

在共享内存的并发模型里，线程之间共享程序的公共状态，线程之间通过写 - 读内存中的公共状态来隐式进行通信。在消息传递的并发模型里，线程之间没有公共状态，线程之间必须通过明确的发送消息来显式进行通信。

同步是指程序用于控制不同线程之间操作发生相对顺序的机制。在共享内存并发模型里，同步是显式进行的。程序员必须显式指定某个方法或某段代码需要在线程之间互斥执行。在消息传递的并发模型里，由于消息的发送必须在消息的接收之前，因此同步是隐式进行的。

Java 的并发采用的是共享内存模型，Java 线程之间的通信总是隐式进行，整个通信过程对程序员完全透明。如果编写多线程程序的 Java 程序员不理解隐式进行的线程之间通信的工作机制，很可能会遇到各种奇怪的内存可见性问题。

前言

控制并发的方法很多，我之前的两篇博客都有过介绍，从最基础的 synchronized，juc 中的 lock，到数据库的行级锁，乐观锁，悲观锁，再到中间件级别的 redis，zookeeper 分布式锁。今天主要想讲的主题是“根据并发出现的具体业务场景，使用合理的控制并发手段”。

什么是并发

由一个大家都了解的例子引入我们今天的主题：并发

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

public class Demo1 {

    public Integer count = 0;

    public static void main(String[] args) {
        final Demo1 demo1 = new Demo1();
        Executor executor = Executors.newFixedThreadPool(10);
        for(int i=0;i<1000;i++){
            executor.execute(new Runnable() {
                @Override
                public void run() {
                    demo1.count++;
                }
            });
        }
        try {
            Thread.sleep(5000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        System.out.println("final count value:"+demo1.count);
    }
}

console:
final count value:973

这个过程中，类变量 count 就是共享资源，而 ++ 操作并不是线程安全的，而多个线程去对 count 执行 ++ 操作，并没有 happens-before 原则保障执行的先后顺序，导致了最终结果并不是想要的 1000

前言

回首大三下的暑假，那时候刚开始出来找实习，如今已经即将进入大四下学期，恍惚间，已经过去了 8，9 个月。写这篇文章的初衷就是想结合自己的经验给即将要出来找工作的应届生一些建议，想当初自己刚出来时，也得到过热心学长的教导，权当一种传递吧。

服务组件化

组件，是一个可以独立更换和升级的单元。就像 PC 中的 CPU、内存、显卡、硬盘一样，独立且可以更换升级而不影响其他单元。

在“微服务”架构中，需要我们对服务进行组件化分解。服务，是一种进程外的组件，它通过 http 等通信协议进行协作，而不是传统组件以嵌入的方式协同工作。服务都独立开发、部署，可以有效的避免一个服务的修改引起整个系统的重新部署。

打一个不恰当的比喻，如果我们的 PC 组件以服务的方式构建，我们只维护主板和一些必要外设之后，计算能力通过一组外部服务实现，我们只需要告诉 PC 我们从哪个地址来获得计算能力，通过服务定义的计算接口来实现我们使用过程中的计算需求，从而实现 CPU 组件的服务化。这样我们原本复杂的 PC 服务得到了更轻量化的实现，我们甚至只需要更换服务地址就能升级我们 PC 的计算能力。

SimpleDateFormat 众所周知是线程不安全的，多线程中如何保证线程安全又同时兼顾性能问题呢？那就是使用 ThreadLocal 维护 SimpleDateFormat

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

public class SimpleDateFormatThreadTest {

    static volatile AtomicInteger n = new AtomicInteger(-1);

<!-- more -->

    static ThreadLocal<DateFormat> sdf ;

    static {
        sdf =new ThreadLocal<DateFormat>() {
            @Override
            protected DateFormat initialValue() {
                return new SimpleDateFormat("yyyy-MM-dd");
            }
        };
    }

    public static void main(String[] args) throws ParseException, InterruptedException {

        Set<String> dateSet = new ConcurrentHashSet<>();
        Set<Integer> numberSet = new ConcurrentHashSet<>();

        Date[] dates = new Date[1000];
        for (int i = 0; i < 1000; i++) {
            dates[i] = sdf.get().parse(i + 1000 + "-11-22");
        }

        ExecutorService executorService = Executors.newFixedThreadPool(10);
        for(int i=0;i<1000;i++){
            executorService.execute(new Runnable() {
                @Override
                public void run() {
                    int number = n.incrementAndGet();
                    String date = sdf.get().format(dates[number]);
                    numberSet.add(number);
                    dateSet.add(date);
                    System.out.println(number+" "+date);
                }
            });
        }
        executorService.shutdown();
        Thread.sleep(5000);
        System.out.println(dateSet.size());
        System.out.println(numberSet.size());
    }

}

实践证明 sdf 的 parse（String to Date）有严重的线程安全问题，format（Date to String）有轻微的线程安全问题，虽然不太明显，但还是会出现问题，这和内部的实现有关。

简单分析下使用 ThreadLocal 的好处，1000 次转换操作，10 个线程争抢执行，如果每次都去 new 一个 sdf，可见其效率之低，而使用 ThreadLocal，是对每个线程维护一个 sdf，所以最多就只会出现 10 个 sdf，真正项目中，由于操作系统线程分片执行，所以线程不会非常的多，使用 ThreadLocal 的好处也就立竿见影了。