成本

当我们的架构方案只涉及几台或者十几台服务器时，一般情况下成本并不是我们重点关注的目标，但如果架构方案涉及几百上千甚至上万台服务器，成本就会变成一个非常重要的架构设计考虑点。

2013年5月17日，阿里集团最后一台IBM小机在支付宝下线。这是自2009年“去IOE”战略透露以来，“去IOE”非常重要的一个节点。 “去IOE”指的是摆脱掉IT部署中原有的IBM小型机、Oracle数据库以及EMC存储的过度依赖。告别最后一台小机，意味着整个阿里集团尽管还有一些Oracle数据库和EMC存储，但是IBM小型机已全部消失。 7月10日，淘宝重中之重的广告系统使用的Oracle数据库下线，也是整个淘宝最后一个Oracle数据库。这两件事合在一起是阿里巴巴技术发展过程中的一个重要里程碑

通过一个架构方案的设计，就能轻松节约几千万元，不但展现了技术的强大力量，也带来了可观的收益，对于技术人员来说，最有满足感的事情莫过于如此了。

当我们设计“高性能”“高可用”的架构时，通用的手段都是增加更多服务器来满足“高性能”和“高可用”的要求；

而低成本正好与此相反，我们需要减少服务器的数量才能达成低成本的目标。

“低成本”本身与”高性能”、”高可用”是冲突的。所以低成本将作为框架的附加约束，而不是首要目标。

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

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 语言实现的例子还有很多。

安全

安全本身是一个庞大而又复杂的技术领域，并且一旦出问题，对业务和企业形象影响非常大。

从技术的角度来讲，安全可以分为两类：

功能安全

功能上的缺陷和漏洞：系统、技术框架、业务逻辑。但大多防的住君子防不住小人，所谓道高一尺，魔高一丈。

从实现的角度来看，功能安全更多地是和具体的编码相关，与架构关系不大。现在很多开发框架都内嵌了常见的安全功能，能够大大减少安全相关功能的重复开发.

功能安全是一个逐步完善的过程，而且往往都是在问题出现后才能有针对性的提出解决方案，我们永远无法预测系统下一个漏洞在哪里，也不敢说自己的系统肯定没有任何问题。换句话讲，功能安全其实也是一个“攻”与“防”的矛盾，只能在这种攻防大战中逐步完善，不可能在系统架构设计的时候一劳永逸地解决。

架构安全

传统的架构安全主要依靠防火墙，防火墙最基本的功能就是隔离网络，通过将网络划分成不同的区域，制定出不同区域之间的访问控制策略来控制不同信任程度区域间传送的数据流。

2016 年知名安全研究人员布莱恩·克莱布斯（Brian Krebs）的安全博客网站遭遇 DDoS 攻击，攻击带宽达 665Gbps，是目前在网络犯罪领域已知的最大的拒绝服务攻击。

一般也不会堆防火墙来防 DDoS 攻击，因为 DDoS 攻击最大的影响是大量消耗机房的出口总带宽。

互联网系统的架构安全目前并没有太好的设计手段来实现，更多地是依靠运营商或者云服务商强大的带宽和流量清洗的能力，较少自己来设计和实现。

云化架构下

一是物理部署架构的变化，同一个系统的不同子系统部署在不同的安全区域，不同的安全区域需要不同的安全策略和不同的安全技术。
另一个是不同的安全区域之间的通信需要选择或研发新的协议。原本简洁的网络通讯变得复杂和难以理解。

规模

规模带来复杂度的主要原因就是“量变引起质变”，当数量超过一定的阈值后，复杂度会发生质的变化。常见的规模带来的复杂度有：

功能越来越多，导致系统复杂度指数级上升

一旦规模超过一定的量级时复杂度就会出现指数级的上升，完全超出预计。因此要做到在规模上升的时候不断演进架构，不断重构代码，并起且做好运维监控，防微杜渐。

软件领域的成本和硬件领域的成本有很大的不同。 在硬件领域随着规模的增大成本会降低，基本上是一次性的技术成本，因为根据摩尔定律，每一美元买到的电脑性能将每隔18～24个月翻一倍。软件领域为什么会不一样呢？归根到底是软件销售模式发生了变化，以前软件的销售模式和硬件的销售模式是一致的，开发出了一个软件产品到处复制销售，每卖出一份软件产品和卖出一块CPU是等同的，卖的多成本就可以持续下降——薄利多销。现在软件的销售模式发生了很大的变化，是账号+充值+移动消费。用户侧的开销很小，只需要一个浏览器就可以了， 软件能力基本在服务端，这就导致了服务端规模上升成本就上升的尴尬境地，要想降低成本必须寻找新的技术和方法，而新的方法和技术需要创新，创新后还要引入到现有的生产环节和现有的技术结合，复杂度可想而知，成本的投入是持续的。

数据越来越多，系统复杂度发生质变

目前的大数据理论基础是 Google 发表的三篇大数据相关论文，其中 Google File System 是大数据文件存储的技术理论， Google Bigtable 是列式数据存储的技术理论， Google MapReduce 是大数据运算的技术理论，这三篇技术论文各自开创了一个新的技术领域。

即使我们的数据没有达到大数据规模，数据的增长也可能给系统带来复杂性。

例如：MySQL 单表的数据因不同的业务和应用场景会有不同的最优值，但不管怎样都肯定是有一定的限度的，一般推荐在 5000 万行左右。

目前描述的复杂度6个来源：性能、可用性、可扩展性、成本、安全、规模架构画图，业界标准”4+1”视图

ps：如何判定进行扩容呢？当业务实际性能大道极限的80%