...
This commit is contained in:
parent
82a492ed0a
commit
c1070d917b
|
@ -3,7 +3,7 @@
|
|||
layout: pages
|
||||
title: 我的 zsh 配置
|
||||
categories: [config]
|
||||
update: 2017-10-06
|
||||
lastModifiedDate: 2017-10-06
|
||||
keywords: [zsh]
|
||||
|
||||
---
|
||||
|
|
|
@ -0,0 +1,67 @@
|
|||
---
|
||||
|
||||
layout: pages
|
||||
title: 给开发人员配置 mongodb 账号
|
||||
categories: [config]
|
||||
lastModifiedDate: 2017-12-26
|
||||
keywords: [mongodb]
|
||||
|
||||
---
|
||||
|
||||
### 说明
|
||||
这篇文章纯属胡扯。。。正经配置方法, 请参考官方文档
|
||||
|
||||
### 没有密码
|
||||
刚装好的数据库默认不需要账号密码
|
||||
|
||||
### 新建连接
|
||||
```sh
|
||||
docker exec -it mongo0 mongo admin
|
||||
```
|
||||
|
||||
### 新建 dba 用户
|
||||
要想给开发人员分配账号密码。首先,要创建一个 dba 用户。像这样:
|
||||
|
||||
1. 切换到 admin 这个 db 下
|
||||
2. 创建一个 dba 用户
|
||||
|
||||
```js
|
||||
use admin
|
||||
db.createUser(
|
||||
{
|
||||
user: "dba",
|
||||
pwd: "woshiyigedba",
|
||||
roles: [ { role: "userAdminAnyDatabase", db: "admin" } ]
|
||||
}
|
||||
)
|
||||
```
|
||||
|
||||
### 新建普通用户
|
||||
然后用 dba 用户来操作, 创建给开发人员用的数据库、账号密码。
|
||||
像这样:
|
||||
|
||||
1. 创建数据库 `shujukumingzi`
|
||||
2. 在这个数据库下,创建账号密码 `yonghuming/mima`
|
||||
|
||||
```js
|
||||
use admin
|
||||
db.auth("dba", "woshiyigedba")
|
||||
use shujukumingzi
|
||||
db.createUser(
|
||||
{
|
||||
user: "yonghuming",
|
||||
pwd: "mima",
|
||||
roles: [ { role: "readWrite", db: "shujukumingzi" } ]
|
||||
}
|
||||
)
|
||||
```
|
||||
|
||||
|
||||
### 删除用户
|
||||
```js
|
||||
db.dropUser('yonghuming')
|
||||
```
|
||||
|
||||
|
||||
* 文章目录
|
||||
{:toc}
|
|
@ -0,0 +1,146 @@
|
|||
---
|
||||
|
||||
layout: pages
|
||||
title: 2017 年终总结
|
||||
categories: [play]
|
||||
lastModifiedDate: 2018-01-01
|
||||
|
||||
---
|
||||
|
||||
|
||||
### 酝酿一下感情
|
||||
|
||||
2017...刚开始的时候...
|
||||
|
||||
年后上班的前几天是比较闲的,那两天完善了下春节期间写的 WeMQ 的代码...
|
||||
这个新工作的一大好处,就是啥都没有,啥都可以自己搞。WeMQ 就是今年搞事情的开始:
|
||||
1. 我想要能通过主题模式收发 mq
|
||||
2. 想要类似 qmq 的语法
|
||||
|
||||
就这两个目的,在老大那肯定是说不过去的。因为没有体现出对公司的价值,只是在满足个人的快感(实际上是有价值的,只不过那个时候的自己,表达不出来)。
|
||||
|
||||
2017年的开始,还带着好几件想要做的事:
|
||||
1. 打通系统间的链路, 有一个工具能通过链路id方便的查询日志,把自己从技术支持中解救出来
|
||||
2. 能看到线上运行的系统的状态, 有多少异常、响应时间怎么样、请求量有多少、缓存命中率多少、sql执行时间多少、...
|
||||
3. 希望能在业务流程的关键节点发出主题模式的 mq 消息
|
||||
|
||||
1、2 两件事,伴随着 WeMQ、WeLog 的正常上线,很自然的实现了。
|
||||
3 这件事,本来已经无望。机缘巧合的因为高管的一句话,铺出了条高速公路
|
||||
|
||||
还有一些...计划之外的事情...
|
||||
|
||||
|
||||
### java 工程师之路
|
||||
|
||||
#### 工具基础
|
||||
|
||||
- 为了能看懂项目里的代码,学习了 java8 的 stream、lambda
|
||||
- 知道了以前从来没听说过的 mongodb、rabbitMQ、elasticsearch、grafana
|
||||
- 知道了 zk 是什么东西
|
||||
- 因为 WeMQ, 熟悉了 java 的注解和反射的运用
|
||||
- 可重复读的字节数组流
|
||||
- 时间处理上的坑: 六个月后 不等于 三个月后的三个月后
|
||||
- Lombok
|
||||
|
||||
...哇...细节简直数不清
|
||||
|
||||
|
||||
|
||||
#### welog
|
||||
|
||||
welog 这项目可以说是 0业务复杂度的了:
|
||||
|
||||
![](/images/welog.svg)
|
||||
|
||||
- 通过 logback 的自定义 appender 来收集日志,
|
||||
1. 不关心日志格式
|
||||
2. 不用运维一个个日志文件的配置
|
||||
3. 不觉得对代码有侵入性,反而能帮助提升日志内容的质量
|
||||
|
||||
- 通过主题模式的 mq 消息,提供可自定义日志处理插件的能力。在这个地方还可以体验一把:从“流”的角度来思考处理数据。
|
||||
- 通过 LogId 能精确匹配到日志。
|
||||
- weLogKV(weLogLongs、weLogStrings、weLogBooleans) 能提供结构化的数据。同时,按类型归类字段,在代码层面上保证了 elasticsearch 能正常索引
|
||||
- 完整的 logEvent 对象在 analyzer 处被汇总,统一推到 ELK, 在实际工作中遇到需要修改推ELK的数据格式、logstash 的 tcp 连接数异常增多运维找上门 时,发挥过令人感动的作用
|
||||
- 加上 slf4j 的 MDC 里设置 traceId,完整链路信息也能在 kibana 上查询了
|
||||
|
||||
|
||||
|
||||
|
||||
#### 7月
|
||||
|
||||
7月,我们终于动手把线上的上一届团队的核心代码,换成我们的(welog 也趁机跟着一起上线)。两个星期整出了两个大故障,但是这两个大故障之后。。。hahahahahahahahahahahahahahaha
|
||||
- 原本每个月各种姿势挂好几次的服务,连续几个月故障次数都变成了0。
|
||||
- kibana 上查询日志的功能,交给技术支持团队后,开发人员干技术支持活的时间也几乎为0。
|
||||
- 监控、统计、报警,也都有了
|
||||
|
||||
|
||||
|
||||
|
||||
#### 计算资源使用量
|
||||
|
||||
多大的用户量/数据量/调用量,需要多少的计算量。有这个经验,或者是预估资源使用量的意识后,感觉一件事完整了许多。
|
||||
- 新加了一段代码,用到了redis,得给出内存使用量的数量级、每秒的请求数。
|
||||
- welog上线了,日志收集的 appender 占用了多少带宽、多少内存、cpu。
|
||||
|
||||
|
||||
|
||||
这些经验的获得,有时候是故意的。(也算是公司的福利之一吧)
|
||||
- welog 日志收集的 appender 一开始就故意用了 http 短连接的方式来推送日志。
|
||||
- 去掉了所有数据库查询缓存。事实证明数据库毫无压力。缓存的加入反而增加了维护的成本。
|
||||
|
||||
|
||||
|
||||
#### 划边界、划边界、划边界、
|
||||
以电商场景为例,总结下处理简单业务需求的套路吧。
|
||||
|
||||
一句话简单概括电商的核心业务,是: “用户”看到了“可购买的资源”完成了“交易”。
|
||||
所以,最粗的边界,可以按 “用户”、“资源”、“交易” 分成 3 个。对“用户”又可以划出 “登录”、“消息通知”、“收货地址”的边界。
|
||||
边界划分的结果可能每个人给出的都不一样,可行的方案有很多,但是都应该满足 `数据独立` 这个检验标准(不准动我的表!!!)。
|
||||
|
||||
在 `数据独立` 的基础上,站在边界内思考应该提供给外界什么样的接口。
|
||||
一个个独立的、设计过自己接口的模块拼接组合在一起,就能 `自底向上` 实现完整的业务系统。
|
||||
|
||||
在单个边界内思考问题,一般就只是对单个实体的增删改查了。如果这个实体的业务场景比较复杂,画出 `数据流`、`状态机` 的图,基本上就没啥问题了。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
#### 对待产品的思维
|
||||
|
||||
原本是巨排斥写前端代码的,年末却开始学起了前端。[vue](https://cn.vuejs.org/v2/guide/index.html) + [uikit](https://getuikit.com/v2/) 基本上是最终的选型。
|
||||
有机会深入的话,下一步应该是学习css3、熟悉js的代码规范、储备类似 [clipboardjs](https://clipboardjs.com/) 的优秀第三方库。
|
||||
至于一个主流的前端工程应该是什么样的: 打包、路由、模块... 放到下下步吧。
|
||||
这个转变的很大一部分原因,是一直被灌输产品的思想。多出了个想要细致的考虑每一个交互,给出最好的体验的念头。
|
||||
|
||||
|
||||
|
||||
|
||||
#### 主动推动一件事儿
|
||||
还记得毕业后刚到业务线的那半年的自己。。。要是现在的自己来带他,估计会咬牙切齿----这世间竟有如此差劲之人!工作能力简直为0!
|
||||
|
||||
现在的自己,不受控制的,就开始把自己当成负责人,主动跟相关的人沟通,试图推进事情发展。
|
||||
虽然能力有限、没发挥什么作用,但是能不受控制的硬着头皮上啊。
|
||||
不受控制的、本能的、做着那个时候最害怕的事。。。
|
||||
|
||||
|
||||
|
||||
|
||||
### 科学那么美
|
||||
|
||||
|
||||
|
||||
|
||||
### 宅男的愿望
|
||||
|
||||
日语、钢琴、游戏、动漫、轮滑、小说...基本上都没实现。哈哈哈。。。好歹护照办好了
|
||||
日语课上了33节,计划进度已经到80节了
|
||||
明天去把钢琴的一级课给过了吧
|
||||
手办的钱是时候开始存了。。。房子和两百万的小提琴呢。。。
|
||||
啥时候能继续后来的事。。。啥时候能觉得把南音、北北买了不会吃灰。。。
|
||||
|
||||
<audio controls loop autoplay src="/audio/knowledge-is-power.mp3" >
|
||||
|
||||
|
||||
* 文章目录
|
||||
{:toc}
|
Binary file not shown.
File diff suppressed because one or more lines are too long
After Width: | Height: | Size: 20 KiB |
Loading…
Reference in New Issue