比 Amazon 的分布式数据库更为著名的是它的可伸缩架构模式，也就是面向服务架构。Werner Vogels 在 2006 年的一次访谈中指出，Amazon 在 2001 年时就意识到他们的前端需要横向伸缩，而面向服务架构有助于他们实现前端伸缩。工程师们面面相觑，最后只有少数几个工程师着手去做这件事情，而几乎没有人愿意将他们的静态网页拆分成小型的服务。

不过 Amazon 还是决定向 SOA 转型，他们当时有 7800 个员工和 30 亿美元的销售规模。

当然，并不是说你也要等到有 7800 个员工的时候才能转向 SOA……只是你要多想想，它真的能解决你的问题吗？你的问题的根源是什么？可以通过其他的方式解决它们吗？

如果你告诉我说，atv，你那 50 个人的公司打算转向 SOA，那么我不禁感到疑惑：为什么很多大型的公司仍然在乐此不彼地使用具有模块化的大型单体应用？

甚至 Google 也不是 Google

使用 Hadoop 和 Spark 这样的大规模数据流引擎会非常有趣，但在很多情况下，传统的 DBMS 更适合当前的负载，有时候数据量小到可以直接放进内存。你是否愿意花 10,000 美金去购买 1TB 的内存？如果你有十亿个用户，每个用户仅能使用 1KB 的内存，所以你的投入远远不够。

或许你的负载大到需要把数据写回磁盘。那么你需要多少磁盘？你到底有多少数据量？Google 之所以要创建 GFS 和 MapReduce，是要解决整个 Web 的计算问题，比如重建整个 Web 的搜索索引。或许你已经阅读过 GFS 和 MapReduce 的论文，Google 的部分问题在于吞吐量，而不是容量，他们之所以需要分布式的存储，是因为从磁盘读取字节流要花费太多的时间。那么你在 2017 年需要使用多少设备吞吐量？你一定不需要像 Google 那么大的吞吐量，所以你可能会考虑使用更好的设备。如果都用上 SSD 会给你增加多少成本？

或许你还想要伸缩性。但你有仔细算过吗，你的数据增长速度会快过 SSD 降价的速度吗？在你的数据撑爆所有的机器之前，你的业务会有多少增长？截止 2016 年，Stack Exchange 每天要处理 2 亿个请求，但是他们只用了 4 个 SQL Server，一个用于 Stack Overflow，一个用于其他用途，另外两个作为备份复本。

或许你在应用 UNPHAT 原则之后，仍然决定要使用 Hadoop 或 Spark。或许你的决定是对的，但关键的是你要用对工具。Google 非常明白这个道理，当他们意识到 MapReduce 不再适合用于构建索引之后，他们就不再使用它。

先了解你的问题

我所说的也不是什么新观点，不过或许 UNPHAT 对于你们来说已经足够了。如果你觉得还不够，可以听听 Rich Hickey 的演讲“吊床驱动开发（Hammock Driven Development）”，或者看看 Polya 的书《How to Solve It》， 或者学习一下 Hamming 的课程“The Art of Doing Science and Engineering”。我恳请你们一定要多思考！在尝试解决问题之前先对它们有充分的了解。最后送上 Polya 的一个金句名言：

回答一个你不了解的问题是愚蠢的，到达一个你不期望的终点是悲哀的。

今日荐文

AI 降临：揭秘京东智慧物流