ARTS 第18周| LeetCode 384 打乱数组 | 应用开发12要素

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 是未来".

本周阅读列表

本周没咋阅读...