复杂度来源-低成本¶

重要

低成本本质上是与高性能和高可用冲突的，所以低成本很多时候不会是架构设计的首要目标，而是架构设计的附加约束

当我们的架构方案只涉及几台或者十几台服务器时，一般情况下成本并不是我们重点关注的目标，但如果架构方案涉及几百上千甚至上万台服务器，成本就会变成一个非常重要的架构设计考虑点。例如，A 方案需要 10000 台机器，B 方案只需要 8000 台机器，单从比例来看，也就节省了 20% 的成本，但从数量来看，B 方案能节省 2000 台机器，1 台机器成本预算每年大约 2 万元，这样一年下来就能节省 4000 万元。通过一个架构方案的设计，就能轻松节约几千万元，不但展现了技术的强大力量，也带来了可观的收益，对于技术人员来说，最有满足感的事情莫过于如此了。

低成本&高可用/高性能的冲突¶

当我们设计 “高性能”“高可用” 的架构时，通用的手段都是增加更多服务器来满足 “高性能” 和 “高可用” 的要求；
而低成本正好与此相反，我们需要减少服务器的数量才能达成低成本的目标。

一般我们首先设定一个成本目标，当我们根据高性能、高可用的要求设计出方案时，评估一下方案是否能满足成本目标，如果不行，就需要重新设计架构；如果无论如何都无法设计出满足成本要求的方案，那就只能找老板调整成本目标了。

低成本&创新¶

低成本给架构设计带来的主要复杂度体现在，往往只有 “创新” 才能达到低成本目标。这里的 “创新” 既包括开创一个全新的技术领域（这个要求对绝大部分公司太高），也包括引入新技术，如果没有找到能够解决自己问题的新技术，那么就真的需要自己创造新技术了。

新技术例子¶

NoSQL（Memcache、Redis 等）的出现是为了解决关系型数据库无法应对高并发访问带来的访问压力。
全文搜索引擎（Sphinx、Elasticsearch、Solr）的出现是为了解决关系型数据库 like 搜索的低效的问题。
Hadoop 的出现是为了解决传统文件系统无法应对海量数据存储和计算的问题。

业界类似的例子¶

Facebook 为了解决 PHP 的低效问题，刚开始的解决方案是 HipHop PHP，可以将 PHP 语言翻译为 C++ 语言执行，后来改为 HHVM，将 PHP 翻译为字节码然后由虚拟机执行，和 Java 的 JVM 类似。
新浪微博将传统的 Redis/MC + MySQL 方式，扩展为 Redis/MC + SSD Cache + MySQL 方式，SSD Cache 作为 L2 缓存使用，既解决了 MC/Redis 成本过高，容量小的问题，也解决了穿透 DB 带来的数据库访问压力（来源：http://www.infoq.com/cn/articles/weibo-platform-archieture ）。
Linkedin 为了处理每天 5 千亿的事件，开发了高效的 Kafka 消息系统。

其他¶

将 Ruby on Rails 改为 Java
Lua + redis 改为 Go 语言实现

复杂度表现¶

无论是引入新技术，还是自己创造新技术，都是一件复杂的事情:

1. 引入新技术的主要复杂度在于: 需要去熟悉新技术，并且将新技术与已有技术结合起来；
2. 创造新技术的主要复杂度在于: 需要自己去创造全新的理念和技术，并且新技术跟旧技术相比，需要有质的飞跃。

相比来说，创造新技术复杂度更高，因此:

一般中小公司基本都是靠引入新技术来达到低成本的目标；
而大公司更有可能自己去创造新的技术来达到低成本的目标，因为大公司才有足够的资源、技术和时间去创造新技术。