前几天看技术交流群的话题，又刷到了「Service 层和 Dao 层真的有必要每个类都加上接口吗？」这个问题，之前简单回答了一波，给出的观点是「看情况」

现在结合我参与的项目以及阅读的一些项目源码来看，如果项目中使用了像 Spring 这样的依赖注入框架，那可以不用接口！

先来说说为什么使用了依赖注入框架以后，可以不使用接口。

分布式遭遇并发

在前面的章节，并发操作要么发生在单个应用内，一般使用基于 JVM 的 lock 解决并发问题，要么发生在数据库，可以考虑使用数据库层面的锁，而在分布式场景下，需要保证多个应用实例都能够执行同步代码，则需要做一些额外的工作，一个最典型分布式同步方案便是使用分布式锁。

分布式锁由很多种实现，但本质上都是类似的，即依赖于共享组件实现锁的询问和获取，如果说单体式应用中的 Monitor 是由 JVM 提供的，那么分布式下 Monitor 便是由共享组件提供，而典型的共享组件大家其实并不陌生，包括但不限于：Mysql，Redis，Zookeeper。同时他们也代表了三种类型的共享组件：数据库，缓存，分布式协调组件。基于 Consul 的分布式锁，其实和基于 Zookeeper 的分布式锁大同小异，都是借助于分布式协调组件实现锁，大而化之，这三种类型的分布式锁，原理也都差不多，只不过，锁的特性和实现细节有所差异。

前言

控制并发的方法很多，从最基础的 synchronized，juc 中的 lock，到数据库的行级锁，乐观锁，悲观锁，再到中间件级别的 redis，zookeeper 分布式锁。特别是初级程序员，对于所谓的锁一直都是听的比用的多，第一篇文章不深入探讨并发，更多的是一个入门介绍，适合于初学者，主题是“根据并发出现的具体业务场景，使用合理的控制并发手段”。

什么是并发

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

1 引子

项目开发中的工具类代码总是随着项目发展逐渐变大，在公司诸多的公用代码中，笔者发现了一个简单的，也是经常被使用的类：BaseDomain，引起了我的思考。
在我们公司的开发习惯中，数据库实体类通常会继承一个叫做 BaseDomain 的类，这个类很简单，主要用来填充一些数据库实体公用的属性，它的设计如下：

前言

领域驱动的火爆程度不用我赘述，但是即便其如此得耳熟能详，但大多数人对其的认识，还只是停留在知道它的缩写是 DDD，知道它是一种软件思想，或者知道它和微服务有千丝万缕的关系。Eric Evans 对 DDD 的诠释是那么地惜字如金，而我所认识的领域驱动设计的专家又都是行业中的资深前辈，他们擅长于对软件设计进行高屋建瓴的论述，如果没有丰富的互联网从业经验，是不能从他们的分享中获取太多的营养的，可以用曲高和寡来形容。1000 个互联网从业者，100 个懂微服务，10 个人懂领域驱动设计。

可能有很多和我一样的读者，在得知 DDD 如此火爆之后，尝试去读了开山之作《领域驱动设计——软件核心复杂性应对之道》，翻看了几张之后，晦涩的语句，不明所以的专业术语，加上翻译导致的语句流畅性，可以说观看体验并不是很好，特别是对于开发经验不是很多的读者。我总结了一下，为何这本书难以理解：

1. 没有阅读软件设计丛书的习惯，更多人偏向于阅读偏应用层面的书籍，“talk is cheap，show me the code”往往更符合大多数人的习惯。
2. 没有太多的开发经验支撑。没有踩过坑，就不会意识到设计的重要性，无法产生共情。
3. 年代有些久远，这本书写于 2004 年，书中很多软件设计的反例，在当时是非常流行的，但是在现在已经基本绝迹了。大师之所以为大师，是因为其能跨越时代的限制，预见未来的问题，这也是为什么 DDD 在十几年前就被提出，却在微服务逐渐流行的现阶段才被大家重视。

诚然如标题所示，本文是领域驱动设计的一个入门文章，或者更多的是一个个人理解的笔记，笔者也正在学习 DDD 的路上，可能会有很多的疏漏。如有理解有偏颇的地方，还望各位指摘。

前言

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

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

经典限流算法

前言

控制并发的方法很多，我之前的两篇博客都有过介绍，从最基础的 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

服务组件化

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

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

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