关于复杂度来源,前面的专栏已经讲了高性能、高可用和可扩展性,今天我来聊聊复杂度另外三个来源低成本、安全和规模。
低成本
当我们的架构方案只涉及几台或者十几台服务器时,一般情况下成本并不是我们重点关注的目标,但如果架构方案涉及几百上千甚至上万台服务器,成本就会变成一个非常重要的架构设计考虑点。例如,A 方案需要 10000 台机器,B 方案只需要 8000 台机器,单从比例来看,也就节省了 20% 的成本,但从数量来看,B 方案能节省 2000 台机器,1 台机器成本预算每年大约 2 万元,这样一年下来就能节省 4000 万元,4000 万元成本不是小数目,给 100 人的团队发奖金每人可以发 40 万元了,这可是算得上天价奖金了。通过一个架构方案的设计,就能轻松节约几千万元,不但展现了技术的强大力量,也带来了可观的收益,对于技术人员来说,最有满足感的事情莫过于如此了。
当我们设计“高性能”“高可用”的架构时,通用的手段都是增加更多服务器来满足“高性能”和“高可用”的要求;而低成本正好与此相反,我们需要减少服务器的数量才能达成低成本的目标。因此,低成本本质上是与高性能和高可用冲突的,所以低成本很多时候不会是架构设计的首要目标,而是架构设计的附加约束。也就是说,我们首先设定一个成本目标,当我们根据高性能、高可用的要求设计出方案时,评估一下方案是否能满足成本目标,如果不行,就需要重新设计架构;如果无论如何都无法设计出满足成本要求的方案,那就只能找老板调整成本目标了。
低成本给架构设计带来的主要复杂度体现在,往往只有“创新”才能达到低成本目标。这里的“创新”既包括开创一个全新的技术领域(这个要求对绝大部分公司太高),也包括引入新技术,如果没有找到能够解决自己问题的新技术,那么就真的需要自己创造新技术了。
类似的新技术例子很多,我来举几个。
NoSQL(Memcache、Redis 等)的出现是为了解决关系型数据库无法应对高并发访问带来的访问压力。
全文搜索引擎(Sphinx、Elasticsearch、Solr)的出现是为了解决关系型数据库 like 搜索的低效的问题。
Hadoop 的出现是为了解决传统文件系统无法应对海量数据存储和计算的问题。
我再来举几个业界类似的例子。
Facebook 为了解决 PHP 的低效问题,刚开始的解决方案是 HipHop PHP,可以将 PHP 语言翻译为 C++ 语言执行,后来改为 HHVM,将 PHP 翻译为字节码然后由虚拟机执行,和 Java 的 JVM 类似。
Linkedin 为了处理每天 5 千亿的事件,开发了高效的 Kafka 消息系统。
其他类似将 Ruby on Rails 改为 Java、Lua + redis 改为 Go 语言实现的例子还有很多。
无论是引入新技术,还是自己创造新技术,都是一件复杂的事情。引入新技术的主要复杂度在于需要去熟悉新技术,并且将新技术与已有技术结合起来;创造新技术的主要复杂度在于需要自己去创造全新的理念和技术,并且新技术跟旧技术相比,需要有质的飞跃。
相比来说,创造新技术复杂度更高,因此一般中小公司基本都是靠引入新技术来达到低成本的目标;而大公司更有可能自己去创造新的技术来达到低成本的目标,因为大公司才有足够的资源、技术和时间去创造新技术。
安全
安全本身是一个庞大而又复杂的技术领域,并且一旦出问题,对业务和企业形象影响非常大。例如:
2016 年雅虎爆出史上最大规模信息泄露事件,逾 5 亿用户资料在 2014 年被窃取。
2016 年 10 月美国遭史上最大规模 DDoS 攻击,东海岸网站集体瘫痪。
2013 年 10 月,为全国 4500 多家酒店提供网络服务的浙江慧达驿站网络有限公司,因安全漏洞问题,致 2 千万条入住酒店的客户信息泄露,由此导致很多敲诈、家庭破裂的后续事件。