概念

话说不会偷懒的程序员不是好的程序员，笔者就时常如果有一个软件能够帮我把日常的体力工作都给干了，这样就可以有时间做更多的脑力工作了。
逛博客的时候，经常看到DevOps和CI/CD的相关文章，抱着试试看的想法研究下如何实现。当然跟很多初次看到这几个单词都一脸懵的朋友一样，肯定搜索下都是什么意思:

DevOps: DevOps是Development和Operations的组合，是一种重视软件开发人员（Dev）和运维人员（Ops）之间沟通合作的文化，运动和惯例，用于促进应用开发、应用运维和质量保障（QA）部门之间的沟通、协作与整合。以期打破传统开发和运营之间的壁垒和鸿沟。 通过自动化软件交付和架构变更的流程，使构建，测试，发布软件能够更快，频繁和可信。

CI: 持续集成（Continuous Integration，简称 CI），开发人员各自编写自己负责部分的代码，然后上传到源代码库中合并，CI服务器负责构建软件并测试是否能正常运行，将测试结果反馈给开发人员。

CD: 持续交付（Continuous Delivery，简称 CD）和持续部署(Continuous Deployment)，是在持续集成的基础上将集成后的代码部署到更贴近真实运行的环境中去进行进一步的测试，并可以在多种不同的配置上测试代码，运行额外的性能测试，并自动化每个步骤直到部署到生产环境。

需要注意的是: 持续交付并不是指软件每一个改动都要尽快部署到产品环境中，它指的是任何的代码修改都可以在任何时候实施部署，持续部署是作为持续交付——自动将生产就绪型构建版本发布到代码存储库——的延伸，持续部署可以自动将应用发布到生产环境。

好像有点意思了，按照笔者的理解：平常我们写完代码完成自测后提交代码后，就有工具可以帮我们自动编译和测试，如果没有问题就自动打包并部署到实际的生产环境中。看上去很不错的样子，那么怎么实现呢？

以下内容抄录自硅谷创业之父Paul Graham编写并由阮一峰大佬翻译的经典巨著《黑客与画家》，很有意思备份下来便于以后查阅

1984年，《新闻周刊》的作者史蒂文·利维出版的《Hackers: Heroes of the Computer Revolution》(黑客: 计算机革命的英雄)是历史上第一本介绍黑客的著作。
在该书中，他总结了六条“黑客伦理”作为黑客的价值观参考：

1. 使用计算机以及所有有助于了解这个世界本质的事物都不应受到任何限制。任何事情都应该亲手尝试。

   Access to computers-and anything that might teach you something about the way the world works-should be unlimited and total. Always yield to the Hands-On Imperative!

2. 信息应该全部免费。

   All information should be free.

3. 不信任权威，提倡去中心化。

   Mistrust Authority-Promote Decentralization.

4. 判断一名黑客的水平应该看他的技术能力，而不是看他的学历、年龄或者地位等其他标准。

   Hackers should be judged by their hacking, not bogus criteria such as degrees,age,race,or position.

5. 你可以用计算机创造美和艺术。

   You can create art and beauty on a computer.

6. 计算机使生活更美好。

   Computers can change your life for the better.

   根据这六条“黑客伦理”，黑客价值观的核心原则可以概括成这样几点：分享、开放、民主、计算机的自由使用、进步。

前言

使用idea新建SpringBoot项目时，大家应该会发现除了正常的src/main文件夹之外，还会有个test文件夹，相应的会引入spring-boot-starter-test模块，
本文就来聊聊这个test模板的用法

说到test大家都会想到junit，是的spring-boot-starter-test默认集成的就是junit，但需要注意的是：springboot2.x的版本, 默认使用的是junit5 版本, junit4和junit5两个版本差别比较大，需要注意下用法：

通常我们只要引入 spring-boot-starter-test 依赖就行，它包含了一些常用的模块 Junit、Spring Test、AssertJ、Hamcrest、Mockito 等

为什么要使用消息队列-MQ

不要跟风 使用MQ是为了：

- 解耦:
  传统模式下系统间耦合性太强，比如系统A在代码中直接调用系统B和系统C的代码，如果将来D系统接入，系统A还需要修改代码，过于麻烦！
  使用了MQ后系统A将消息写入消息队列，需要消息的系统B、C、D自己从消息队列中订阅，从而系统A不需要做任何修改。
- 异步:  
  传统模式下一些非必要的业务逻辑以同步的方式运行，太耗费时间！
  使用了MQ后系统A将消息写入消息队列，非必要的业务逻辑以异步的方式运行，加快响应速度。
- 削峰:
  传统模式下并发量大的时候，所有的请求直接连接到数据库，会造成数据库连接异常从而引起系统崩溃！
  使用了MQ后系统A慢慢的按照数据库能处理的并发量，从消息队列中慢慢拉取消息，减少后端的压力。在生产中，这个短暂的高峰期积压是允许的。

不要挖坑 不管是引入MQ技术，还是其他技术，有利也有弊：

- 系统可用性降低: 引入MQ之后一旦MQ不可用之后(提供MQ的服务挂掉了)，那凡是关联使用的系统都会受到影响，因此，系统可用性降低
- 系统复杂性增加: 要多考虑很多方面的问题，比如一致性问题、如何保证消息不被重复消费，如何保证保证消息可靠传输等等，会使得系统的复杂性增大(可能会引入一些潜在的bug)

个人建议，要看实际项目的需求，业务量不是特别大的项目，不建议为了使用而使用。
当然如果项目中有以上的场景需求，或者使用传统模式时遇到了瓶颈时，大胆的引入吧(上面说的弊端也是有很多解决方案的，如可以搭建MQ集群来保持MQ的高可用性)！

消息中间件的应用场景

前言

这两天翻查以前的笔记，偶然看到了记录的关于积极心理相关的摘录，防止以后丢了，写到文章中了，与有缘人共同分享，希望看到了同学都能拥有积极的心态，让思维改变生活。

前言

使用Spring Boot Starters可以快速集成相关组件，无需编写复杂的配置，在引入某项技术框架时，一个比较好的习惯就是看有没有xxx-starter

SpringBoot 2.4.0开始官方插件增加了对docker的支持

阿里云

登录阿里云容器镜像服务

创建命名空间

获取访问凭证(这里为了演示方便,采用固定密码方式，企业项目需根据实际情况设置密码或子账号访问等)

pom.xml检查是否为:

1
2
3
4
5
6

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>2.4.0</version>
    <relativePath/> <!-- lookup parent from repository -->
</parent>

插件中加入docker配置

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

            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
                <configuration>
                    <image>
                        <name>registry.cn-shanghai.aliyuncs.com/jonesun/${project.artifactId}:${project.version}</name>
                        <!-- 执行完build 自动push -->
                        <publish>true</publish>
                        <!-- 默认build访问的是docker.io/paketobuildpacks/builder:base 这个在国内访问较慢，可从阿里云镜像中心搜索用户公开的镜像代替 -->
                        <builder>registry.cn-shanghai.aliyuncs.com/sannmizu/builder:base</builder>
                        <!-- 默认runImage访问的是docker.io/paketobuildpacks/run:base-cnb 如果在国内访问较慢，可从阿里云镜像中心搜索用户公开的镜像代替 -->
<!--                        <runImage>registry.cn-hangzhou.aliyuncs.com/paketo-buildpacks/run:base-cnb</runImage>-->
                    </image>
                    <!--配置构建远程机信息，本机不用配置-->
                    <docker>
<!--                        &lt;!&ndash;远程docker daemon的连接地址和端口(如果本地未安装docker的话)&ndash;&gt;-->
<!--                        <host>tcp://192.168.99.100:2375</host>-->
<!--                        &lt;!&ndash;如果使用https协议需要设置为true&ndash;&gt;-->
<!--                        <tlsVerify>false</tlsVerify>-->
                        <publishRegistry>
                            <username>xxx</username>
                            <password>xxx</password>
                            <url>registry.cn-shanghai.aliyuncs.com</url>
                        </publishRegistry>
                    </docker>
                </configuration>
            </plugin>

maven插件有两种方式构建镜像:

前言

在日常项目开发中，代码可以使用GIT/SVN 来进行版本控制，而数据库的更新却需要人工进行干预。

之前我在项目开发时会根据项目版本手工创建好每次版本迭代会更新的sql文件，发布版本时先在线上执行下对应sql，然后再更新应用版本。在研究自动构建时就想有没有一种技术/框架可以将这种手工行为变为自动。

偶然的机会在网上搜索到flyway-一个能对数据库变更做版本控制的工具，通过在项目中集成就可以在每次版本更新时自动执行对应版本sql了

Flyway具有以下优点：

• 简单 非常容易安装和学习，同时迁移的方式也很容易被开发者接受。
• 专一 Flyway 专注于搞数据库迁移、版本控制而并没有其它副作用。
• 强大 专为持续交付而设计。让Flyway在应用程序启动时迁移数据库。

前言

idea 可以通过Spring Initializr创建SpringBoot/SpringCloud项目并勾选引用第三方组件，阿里巴巴也发行了类似的插件Alibaba Java Initializr(可在插件市场搜索安装)

可以看到分类还是不少的，下面我就逐一分享下每个分类及可选择的组件和使用场景

idea版本基于2020.2, 不同idea可能会有出入，Spring Boot基于2.4.0，更详细的见https://start.spring.io/

数据类型

Java里将数据类型分为了基本数据类型和引用数据类型，基本数据类型包含: byte、char、short、int、float、double、long、boolean，剩下的都是引用类型。最常用的就是String字符串：

• 基本数据类型的值都是直接保存在变量中的(一个变量一个值，可以体会到类似Integer.valueof缓存值的用意)
• 而引用类型的变量类似于C语言的指针，它内部存储一个“地址”，指向某个对象在内存的位置
• 对于基本类型变量num，赋值运算符将会直接修改变量的值，原来的数据将被覆盖掉，被替换为新的值。
• 对于引用类型变量str，赋值运算符只会改变变量中所保存的对象的地址信息，原来对象的地址被覆盖掉，重新写入新对象的地址数据。但原来的对象本身并不会被改变，只是不再被任何引用所指向的对象，即“垃圾对象”，后续会被垃圾回收器回收。
• 引用类型的变量可以指向一个空值null，它表示不存在，即该变量不指向任何对象

基本类型的变量是“持有”某个数值，引用类型的变量是“指向”某个对象