架构复杂度4-低成本、安全、规模

复杂度来源：低成本、安全、规模

低成本

如果架构方案涉及几百上千甚至上万台服务器，成本就会变成一个非常重要的架构设计考虑点
需要减少服务器的数量才能达成低成本的目标。因此低成本本质上是与高性能和高可用冲突的

• 往往只有“创新”才能达到低成本目标
  1. NoSQL（Memcache、Redis 等）的出现是为了解决关系型数据库无法应对高并发访问带来的访问压力。
  2. 全文搜索引擎（Sphinx、Elasticsearch、Solr）的出现是为了解决关系型数据库 like 搜索的低效的问题。
  3. Hadoop 的出现是为了解决传统文件系统无法应对海量数据存储和计算的问题。
  4. Linkedin 为了处理每天 5 千亿的事件，开发了高效的 Kafka 消息系统。
  5. Facebook 为了解决 PHP 的低效问题，改为 HHVM，将 PHP 翻译为字节码然后由虚拟机执行，和 Java 的 JVM 类似。
  6. 新浪微博将传统的 Redis/MC + MySQL 方式，扩展为 Redis/MC + SSD Cache + MySQL 方式，SSD Cache 作为 L2 缓存使用，既解决了 MC/Redis 成本过高，容量小的问题，也解决了穿透 DB 带来的数据库访问压力

安全

经常能够看到或者听到各类安全事件，所以大部分技术人员和架构师，对安全这部分会多一些了解和考虑。
从技术的角度来讲，安全可以分为两类：

1. 一类是功能上的安全 “防小偷”
   更多地是和具体的编码相关，与架构关系不大（常见的 XSS 攻击、CSRF 攻击、SQL 注入等）
2. 一类是架构上的安全 ”防强盗”
   传统的架构安全主要依靠防火墙 访问控制策略,但性能一般.在传统的银行和企业应用领域应用较多。
   互联网系统的架构安全目前并没有太好的设计手段来实现，更多地是依靠运营商或者云服务商强大的带宽和流量清洗的能力

规模

规模带来复杂度的主要原因就是“量变引起质变”
有些系统功能特别多，逻辑分支特别多。发展时间比较长，不断地往上面叠加功能，到最后面对的就是一个黑盒系统，看不懂、改不动、不敢改、修不了，复杂度自然就感觉很高了。

1. 功能越来越多，导致系统复杂度指数级上升
2. 数据越来越多，系统复杂度发生质变