可能工程师做出这样的决定是因为他们预计未来需求会大增，或者对Kafka的基本原理有着深刻的理解。不过照我猜测，可能是社区对Kafka热情高涨，影响了他们，工程师没有深入思考它是否适合自己。我的意思是处理的信息少了10个数量级!

　　再次重申，你不是亚马逊

　　与亚马逊分布式数据库相比，让它可以扩展的架构模式更流行，也就是以服务为中心的架构。2006年，Jim Gray采访Werner Vogels，当时Werner Vogels说亚马逊早在2001年就意识到它们想扩展前端相当吃力，最终以服务为中心的架构帮上大忙。这种观点得到了工程师的推崇，结果一些只有几名工程师、没有多少用户的创业公司也将自己的App打碎，放进微服务。

　　当亚马逊决定向SOA转移时，它的员工数量已经达到8700人，销售额超过30亿美元。

　　并不是说你的员工数量达到8700人才能使用SOA……只是你应该多掂量掂量自己。要解决你的问题，它的方案真的是最好的吗?你的问题到底是什么，能不能用其它办法解决?

　　如果你告诉我，说你们有50人的工程团队，如果没有SOA工作将无法开展下去，我会感到奇怪，因为有许多更大的企业只有更大、但是组织更好的单一应用，它们同样做得很好。

　　甚至连Google都不是Google

　　使用大规模数据流引擎(比如Hadoop、Spark)是一件相当有趣的事：不过许多时候传统DBMS够用了，与工作流更匹配，有时数据的数量很小，完全可以放进内存中。你知道吗，花1万美元就可以买1TB的内存?即使你有10亿用户，每位用户也可以分派1KB的内存。

　　对你来说也许不够，你要将数据写入硬盘，从硬盘上读取。但是你要从无数的硬盘中完成读写操作吗?你到底有多少数据?GFS与MapReduce之所以开发出来，是为了处理基于整个网络的计算问题，例如为整个网络重建搜索索引。

　　你也许已经读过GFS和MapReduce的相关论文，知道Google的部分问题不在于容量，而在于吞吐量：它采用分布式存储方式，主要是字节流离开硬盘需要太长的时间。2017年，你所使用的设备吞吐量如何?假设你需要的数量没有Google多，你能否购买更好的?使用SSD到底要花多少钱?

　　也许你想在未来扩容。那么你计算过吗?数字的增长速度比SSD价格下跌的速度快吗?当你所有的数据不再适合用一台机器处理时，你的企业需要变得有多大?截止2016年，Stack Exchange每天处理2亿查询量，它只用了4台SQL服务器：一台服务器处理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的话说就是：“回答你不理解的问题是愚蠢的，为了一个你不想要的结果工作是悲哀的。”