DDD
DDD全称为Domain Drive Design,领域驱动设计。这是一个比较陌生的词，但是一看又知道是属于那种高大上的方法论，属于软件工程理论类的概念。
待补充。。。
每日一概念-Serverless/2019-06-18
Serverless
望文生义就是“无服务器”的意思。无服务器不是真的没有服务器，而是不用关心物理服务器。因为云厂商会解决服务器的问题，他们为开发者提供一些无状态的容器，开发者可以在其中运行自己的逻辑。
Serverless在某种场景下更进一步的解放了开发者，使其更加关心业务逻辑而不是运维，而且无状态的容器可以提供极大的扩展性，这是云所擅长的，不过托管的部分及其依赖云平台，如果从一个云厂商切换到另外一个云厂商成本还比较高。
Serverless有两个基本的应用特征：BaaS（Backend as a Service，后端即服务）和FaaS（Function as a Service,函数即服务）。符合这两个基本特征的应用可称为Serverless应用。其中BaaS是指云厂商提供的对象存储与数据库存储等服务，而开发者自己写的基于云厂商的容器的逻辑就是FaaS。
学习《五星级沟通》
进公司六年多了，刚开始的时候参加过一些培训课程，但是感觉收获都不是很大，可能我自己不太适合培训这种方式吧，所以渐渐的都不去参加了。公司有两门非常热门的课程叫《五星级沟通》与《金字塔思维》，陆陆续续听到有些同事去听这两门课程，搞得自己也忍不住想去听一下，所以就都报名了。因为太火爆了，所以根据报名情况进行排队在，直到今天才去学习了《五星级沟通》。下面对今天的学习进行总结下，也算是复习了。
人最重要的属性是社会性，社会性就是指人不是孤立存在的，他是需要与周围的人交流互动进而产生一定关系的。所以沟通就是最常见也最必不可少的方式了。参加课程前我只知道沟通的学问很多，因为无论在生活中还是在工作中，总会有人沟通起来很顺畅，有些人沟通起来很费劲，这里面一定有些门道。那怎么样才能做好沟通呢？
几种生成ID的方法
在我们的工作中，经常会遇到需要生成ID的场景，比如全链路日志中标识唯一请求或者说唯一链路的ID，用户注册过程中给用户分配的唯一账号ID，交易过程中的幂等值等。下面就说说几种常见的ID生成方法，也就是Id Maker的实现方案。
1. 数据库auto increment
我们很容易的想到，数据库中auto increment就是为了生成唯一主键ID的，而且数据库的ACID特性，保证该过程肯定是原子的，原子的意思就是不会有ID冲突即有两个ID生成的一模一样。该方法对于生成ID不是很频繁的场景还是比较适用的，一般是生成请求在几千次/s的情况下。
2. 使用redis自增命令
redis有个incrby的命令，通用点的叫法就是计数器，其实这种思路与mysql的自增并没有什么分别，不过因为存储方式的原因，使用redis做id maker可以在单位时间内生成更多的ID，redis的性能都是10W/s的。不过使用redis没有使用mysql那么简单，它需要在业务层面做一些保护。
数据迁移的几种方法
在我们的日常工作中，因为各种各样的原因，比如机器裁撤、业务重构等都会遇到数据迁移的情况，下面就谈谈数据迁移的几种常见方法。
介绍方法之前，我们先来谈谈数据迁移的几个原则：
- 数据不能丢，不能错。数据的准确性、一致性、完整性是最基础的东西。
- 服务尽可能不中断，
- 数据迁移过程可以重入重迁。
轻量级的监控统计系统AcOss设计与实现
一直以来我们都比较缺乏一个易用的业务粒度的监控统计，故借鉴wechat的idkey系统来做了一个轻量级的AcOss系统。
具备的功能
- 开发人员可以很方便的添加各种监控项，监控项可分为累加值、设置值、最大值与平局值四种类型
- 提供后台界面来申请idkey，id与key是两个概念，具体会在下文中给出。
- 提供后台界面来查看idkey的监控情况，一页展示所有的监控项目，最多128个。
- 每个监控项可以配置最大与最小阈值，超过阈值可以发送告警信息到负责人，告警可以在配置页面取消
- 因为是轻量级方案，并没有使用客户端部署agent的方式，而且采取集中往UDP Server发包，为了防止包量过大添加了采样率参数，对于分钟调用量万级别以上的接口强制设置采样率。在监控视图展示的时候会将数据反向放大回去。（项目初期可以使用默认值1，即100%采样）
Mysql乐观锁与悲观锁
我们在操作数据库的时候，可能会由于并发问题而引起的数据的不一致性（数据冲突）
乐观锁
乐观锁不是数据库自带的，需要我们自己去实现。乐观锁是指操作数据库时(更新操作)，想法很乐观，认为这次的操作不会导致冲突，在操作数据时，并不进行任何其他的特殊处理（也就是不加锁），而在进行更新后，再去判断是否有冲突了。