Posts

符合Angular规范的Commit Message <type>[(optional scope)]: <description> // 空行 [optional body] // 空行 [optional footers] 分为了Header、Body、footer三个部分 Header Header部分只有一行<type>[(optional scope)]: <description>，其中type必选，其它可选 type–>归为两类： Development(项目管理类变更，不影响用户和生产环境的代码) Production(影响用户和生产环境的代码) 类型 类别 说明 feat Production 新增功能 fix Production 修复缺陷 perf Production 提高代码性能的变更 style Development 代码格式类的变更，例如使用gofmt格式化代码 refactor Production 其他代码类的变更，例如 简化代码、重命名变量、删除冗余代码等等 test Development 新增测试用例或更新现有的测试用例 ci Development 持续基础和部署相关的改动，例如修改Jenkins、GitLab CI等Ci配置文件或者更新系统单元文件 docs Development 文档类的更新，包括修改用户文档、开发文档 chore Development 其他类型，例如构建流程、依赖管理或者复制工具的变动 scope–>不设置太具体的值，说明commit的影响范围 description–>对commit的简短描述，以动词开头 Body Body对Commit Message的高度概况，方便查看具体做了什么变更 Footer Footer部分不是必选，可根据需要选择，主要用来说什么本次commit导致的后果，通常用来说明不兼容的改动或者关闭的issue BREAKING CHANGE: <breaking change summary> // 空行 <breaking change description + migration instructions> // 空行 // 空行 Fixes(Closes) #<issue number> Revert Commit 特殊的Commit Message。还原了先前的commit，则以revert开头，后面跟还原的commit的Header， 在Body必须写This reverts commit <hash>，其中hash为要还原的commit的SHA标识 ...

Git 仓库 README # 项目名称 <!-- 写一段简短的话描述项目 --> ## 功能特性 <!-- 描述该项目的核心功能点 --> ## 软件架构(可选) <!-- 可以描述下项目的架构 --> ## 快速开始 ### 依赖检查 <!-- 描述该项目的依赖，比如依赖的包、工具或者其他任何依赖项 --> ### 构建 <!-- 描述如何构建该项目 --> ### 运行 <!-- 描述如何运行该项目 --> ## 使用指南 <!-- 描述如何使用该项目 --> ## 如何贡献 <!-- 告诉其他开发者如果给该项目贡献源码 --> ## 社区(可选) <!-- 如果有需要可以介绍一些社区相关的内容 --> ## 关于作者 <!-- 这里写上项目作者 --> ## 谁在用(可选) <!-- 可以列出使用本项目的其他有影响力的项目，算是给项目打个广告吧 --> ## 许可证 <!-- 这里链接上该项目的开源许可证 -->

消息队列是大型分布式系统不可缺少的中间件，也是高并发系统的基石中间件 一、消息队列MQ概述 消息队列（Message Queue），指保存消息的一个容器，本质是个队列，传送的消息可以是文本字符串，也可以是复杂的嵌入对象 基本模型 应用场景 1.异步处理 消息队列的主要特点是异步处理，主要目的是减少请求响应的时间，实现非核心流程异步化，提高系统响应性能 了解同步与异步同步与异步的区别(一看则懂)_同步和异步的区别-CSDN博客 异步的经典场景就是将比较耗时而且不需要即时（同步）返回结果的操作，通过消息队列来实现****异步化 2.应用解耦 解耦：保证消息格式不变，消息的发送方和接收方之间并不需要彼此联系，也不受对方的影响 只通过消息队列MQ来联系（？） 3.流量削锋 一般在秒杀或团抢活动中使用广泛 这种场景中系统的峰值流量往往集中于一小段时间内，所以为了防止系统在短时间内的峰值流量冲垮，往往采用消息队列来削弱峰值流量，相当于消息队列做了一次缓冲 4.日志处理 日志处理是指将消息队列用在日志处理中，以解决大量日志传输的问题（比如Kafka） 暂时无法在飞书文档外展示此内容 二、消息队列MQ设计 1.整体框架 暂时无法在飞书文档外展示此内容 Producer 消息生产者：负责产生和发生消息到Broker； Broker 消息处理中心：负责消息存储、确认、重试等，一般会有多个queue； Consumer 消息消费者：负责从Broker中获取消息，并进行相应处理； 2.详细设计 Producer生产者 产生消息 –> Broker消息处理中心 存储消息 –> Consumer 消费者对消费消息，返回 消息确认 –> Broker 进行消息备份/删除 RPC通信 Producer产生消息，Consumer消费消息都会涉及到通信的问题，消息队列使用了RPC将数据流串起来 Broker存储 消息到达服务端后需要存储到Broker 流量削峰、最终一致性等需求都是需要Broker先存储下来，等待合适的时机投递 存储可以有很多方式，存储在内存，分布式KV，磁盘，数据库等，存储的选项需要考虑综合性能/高可用和开发维护成本 消费模型 消息到达Broker后，最终需要Consumer去消费消息，这里涉及到消费模型 目前主要有两种：单播和广播 单播：点到点 广播：一点对多点 高级特性 Consumer端把消息消费了，除了需要消息确认，还会涉及到比如：重复消息、顺序消息、消息延迟、事务消息等需要考虑的高级特性 消息队列MQ模型 主要有两种模型：点对点 与 发布订阅 两种模型 消息队列是什么_mq是什么_MQ消息队列服务-AWS云服务 深入消息队列MQ，看这篇就够了！

https://yeasy.gitbook.io/docker_practice/ 一、基本概念 镜像(Image) 容器(Container) 仓库(Repository) 理解以上三个概念，就能理解docker的生命周期 1.镜像 Docker镜像是一个特殊的文件系统，除了提供容器运行时所需的程序、库、资源、配置等文件，以及一些运行时所需的配置参数。镜像不包含任何动态数据，其内容在插件之后也不会被改变 分层存储，镜像采用了分层存储的架构，由一组文件系统组成的（多层文件系统联合组成）。在构建镜像时，会一层一层构建，后一层依赖于上一层，后一层上的任何改变都只会发生在本层，不会干涉到上一层。因此构建镜像的时候，需要对每层需要添加的东西尽量加最少最有必要的东西，减少额外的东西 分层存储的特征还使得镜像的复用，定制更为容易 2.容器 容器是镜像运行时的实体，可以被创建、启动、停止、删除暂停等 镜像(Image)和容器(container)的关系，就像是面向对象程序设计中的类 和实例 一样 容器的实质是进程，运行于属于自己的独立的命名空间。因此容器可以拥有自己的root 文件系统，网络配置、进程空间等，运行在一个隔离的环境。这样的隔离特性，使得容器封装的应用比直接在宿主运行更加安全 容器也是分层存储，是以镜像为基础层，在其上创建一个当前容器的存储层，这个层是为容器运行时进行读写而准备的，称为容器存储层 容器存储层的生命周期跟容器一样，当容器消亡时，容器存储层也随之消亡，因此任何保存于容器存储层的信息都会随着容器的删除而丢失 Dokcer最佳实践的要求，容器不应该向其存储层写入任何数据，容器存储层保存无状态化，所有的文件写入操作，都应该使用数据卷、或者绑定宿主目录 数据卷独立于容器，使用容器卷，容器的删除或者重写运行之后，数据都不会丢失 3.仓库 Docker Register：提供一个集中的存储、分发镜像的服务 一个Docker Register可以包含多个**仓库（Repository）;每个仓库可以包含多个标签（Tag）,**每个标签对应一个镜像 可以通过<Repository Name>:<Tag Name> 的格式来指定具体的软件是那个版本的镜像 仓库名以两段路径形式出现，比如jwilder/nginx-proxy 前者是Docker Registry多用户环境下的用户名，后者是对应的软件名 Docker Registry 公开服务 Docker Registry公开服务是开放给用户使用、允许用户管理镜像的Registry服务。 最常见的是Docker Registry公开服务是官方的hub.docker.com，也是默认的Registry 也可以使用国内的镜像网站 私有Docker Registry 用户可以在本地搭建私有的Docker Registry。Docker提供了Docker Registry镜像，可以直接使用搭建私有Registry服务 二、镜像 1.获取镜像 从Docker镜像仓库获取镜像的命令是 docker pull docker pull [选项] [Docker Registry 地址[:端口号]/] 仓库名[:标签] 具体选项可以从docker pull --help 命令查看， Docker镜像仓库地址：地址格式一般为 <域名/IP>[:端口号]。默认地址是 Docker Hub 仓库名：仓库名是两段式，即<用户名>/<软件名>.对于Docker Hub，如果不给出用户名，默认为 library，也就是官方镜像 $ docker pull ubuntu:18.04 上面命令没有给出Docker镜像仓库地址，默认从Docker Hub获取镜像。而镜像名称是ubuntun:18.04,因此会获取官方镜像 library/ubuntun仓库中标签为18.04的镜像 ...