ARTS

ARTS 是陈浩（网名左耳朵耗子）在极客工夫专栏里发动的一个流动，目标是通过分享的形式来保持学习。

每人每周写一个 ARTS：Algorithm 是一道算法题，Review 是读一篇英文文章，Technique/Tips 是分享一个小技术，Share 是分享一个观点。

本周内容

这周的 ARTS 你将看到:

1. 一道不太适宜做面试题的面试题.
2. 应用服务开发的 12 因素 12-Factor.
3. (疑难)做 k8s 相干的开发到底是做什么?

Algorithm

本周的算法题, 是 LeetCode 384 Shuffle An Array 打乱数组.

具体解释看这里吧. 这道题就是考查洗牌算法的实现, 但更重要的是能证实算法的正确性, 这两点下面题解中都讲的十分具体.

type Solution struct {original []int

}

  

func Constructor(nums []int) Solution {return Solution{original: nums}

}

  

/** Resets the array to its original configuration and return it. */

func (this *Solution) Reset() []int {return this.original}

  

/** Returns a random shuffling of the array. */

func (this *Solution) Shuffle() []int {l := len(this.original)

ret := make([]int, l)

copy(ret, this.original)

// 洗牌算法

for i := l - 1; i >= 0; i-- {// 产生 [0, i] 范畴内的随机数

r := rand.Intn(i + 1)

ret[i], ret[r] = ret[r], ret[i]

}

return ret

}

这道题我始终感觉不适宜作为面试题, 因为我认为这不是常见或者罕用的算法, 也没什么通用的思维.

Review 文章举荐

本周的英文文章举荐是 12-Factor.

这是一篇介绍软件开发和交付流程中要害因素的文章, 如题目所说的, 作者认为一个好的应用程序应该遵循 12 中个性.

PS: 文中所说的利用 (app) 指的是艰深来说的一个服务或者一个过程, 如果对应到分布式系统的话, 就是整个零碎中的其中一个 service.

上面就是所谓 “12 因素 ”:

1. 每个利用都是用各自独立的代码仓库(repo).
2. 每个利用的代码依赖包定应该被 显式的申明 并且不同利用的依赖该当 相互隔离.
3. 在运行环境而不是代码中保留配置.

乏味的是作者列举了一个测验规范, 就是: 我的项目即使齐全开源也不会造成信息泄露.

1. 将利用的依赖服务 (backing service) 当做资源来治理.

相似策略模式的思维, 利用能够将所依赖的 MySQL 服务换成其余的同类服务, 比方 Amazon RDS, 除配置改变之外无需批改任何代码.

1. 应用 Build, Release 和 Run 严格辨别利用的不同阶段.

Build 向指定的运行环境编译代码, 包含指定代码版本和依赖版本.

Release 指 Build 的输入加上配置文件的组合, 该组合能够间接运行在指标环境.

Run 指抉择一个 Release 阶段的输入版本, 并运行.

1. 每个利用都因该是无状态的过程.

任何须要保留的数据 (所谓状态) 都应该交给 4 中的依赖服务来存储.

1. 通过端口绑定来提供服务.
2. 依赖过程模型实现服务扩大(伸缩).
3. 应用疾速启动和优雅敞开来最大化健壮性.
4. 开发环境, 预公布环境和线上环境要尽可能保持一致.

具体的措施就是应用集成工具缩小公布工夫, 以及应用 devops 防止开发和运维的认知一致.

1. 把日志当做事件流.
2. 将后盾治理工作作为一次性过程运行.

后盾治理工作是指相似数据库迁徙这种个别只会执行一次的非业务逻辑.

Tip 编程技巧

本周的编程毫无技巧.

Share 灵光一闪

这周和几个从事或者想从事 k8s 相干开发的敌人聊了聊.

之前始终认为从事这方面开发就是解决方案工程师的我, 仍然对做 k8s 开发相干的工作有一个感性的意识. 因为这几个人对于为什么要做 k8s 的时候, 给出的第一个理由全都是: “ 因为 k8s 是将来 ”.

本周浏览列表

本周没咋浏览 …