这个在瞎扯淡下面，就是想随便扯扯。

有的时候，会看到这么两个词，架构师，架构能力。

那啥叫架构？这里举两个栗子，说下我的理解。

栗子一：搜索重构

上一份工作的搜索功能，一开始是后端自己撸的，存储用 ES，虽然不太准，但至少能用（毕竟没直接用 MySQL 的 like）。

但随着数据越来越多，用户要求越来越多，后端搞不定了，就交给搜索团队去做了。

搜索团队的 leader 重新做了架构。

首先，是解决了搜索不可扩展的问题。

这里的扩展问题指的是，产品使用的时间越长，内容越多，搜索会越慢。

方案并不复杂，就是默认搜索最近 2 年的。需要搜索之前的，需要加上时间限制。

旧的数据，可以存在廉价的机器上，或者干脆不存，看预算。

有不少软件，是不可扩展的，比如前公司买的 wiki（不说名字了）就挂了几天，因为 wiki 设计的时候，没考虑扩展性。

第二件事，搞了一套可以重新索引数据的机制。

这个我也想过要搞，不过一直没时间。但搜索团队的负责人，在迁移前，就把这个事情想清楚了，并且把它当成需求做了。

性能，监控，log 这些可以说都是功能，只不过有的产品不理解。

再然后，就是一些优化，提高准确率之类的东西了。

架构上，需要解决两件事，一个是可扩展性，一个是要能处理常见的情况。

栗子二：Google File System

Google 根据自身的使用场景，设计了一套文件存储系统，内部很多的服务都依赖这个文件系统。

如果存粹从技术的角度讲，并没有什么新鲜的东西。但作为工程实践，却非常值得学习。

Single master

GFS 用 single master 做控制，一般情况下，人们会认为，single master 不好扩展，所以会怀疑，到底能不能抗住 Google 的负载。但 single master 好处是，实现起来容易。

这里，并不是说 single master 很好，而是说在 huge scale 的场景下，用 single master 扛住了并发，就很牛逼。

再比如，一些数据 GFS 是存在内存里，那内存明显是瓶颈，但 GFS 给的理由是

If necessary to support even larger file systems, the cost of adding extra memory to the master is a small price to pay for the simplicity, reliability, performance, and flexibility we gain by storing the metadata in memory.

weak consistency

强一致对应用更友好，但 GFS 选了弱一致，因为性能好，好实现。。文件的内容，会重复也会被别人存的东西插进来（segnment）。反正 GFS server 不管你这个。它客户端靠 libary 识别这些，co-design client server。

ETX3 有类似的玩法，每次 write 是不会真的写到磁盘，而是一段时间，批量写入。减少了 system call 的损耗。代价是，write 返回了，如果这个时候重启，一些文件里的改动有可能会丢。

support & un-support

GFS 主要是为了处理大的，连续性的读写，小的，随机的读写性能并不好。但这覆盖了绝大多数使用场景。

再比如 GFS 认为带宽比延迟重要，以及处理了可用性问题。

总结下来，就是，取舍，怎么划分，每一个部分提供什么服务，不提供什么服务。

参考

• The Google File System, Sanjay Ghemawat
• Journaling the Linux ext2fs Filesystem, Stephen C. Tweedie

广告

既然都看到这里了，我们公司有不少岗位在招人，可以找我内推啊。