共计 4452 个字符，预计需要花费 12 分钟才能阅读完成。
对于复杂度起源，后面曾经讲了高性能、高可用和可扩展性，明天我来聊聊复杂度另外三个起源低成本、平安和规模。
低成本
在设计架构计划时，老本通常只有在波及数百、数千乃至数万台服务器时才成为重点思考的指标。举例来说，计划 A 须要 1 万台机器，计划 B 只须要 8 千台机器，只管从比例上看，B 计划仅比 A 计划节俭了 20% 的老本，但因为 B 计划须要的机器数量更少，因而能够节俭约 4000 万元的老本，每人能够分得 40 万元奖金。因而，通过奇妙的架构设计，能够轻松地节俭数千万元的老本，不仅展现了技术的实力，而且带来了可观的收益，这对技术人员来说是最有成就感的事件之一。
当咱们致力于设计“高性能”和“高可用”的架构时，通常的做法是减少更多的服务器以满足需要。但在设计低成本的架构时，咱们须要相同的策略：缩小服务器的数量。因而，低成本与高性能和高可用往往是互相抵触的，因而低成本通常不是架构设计的首要指标，而是作为附加束缚。这意味着，咱们须要首先设定一个老本指标，而后在设计满足高性能和高可用的计划时，思考计划是否合乎老本要求。如果无奈设计出满足老本要求的计划，就须要从新设计架构；如果无论如何都无奈满足老本指标，那么就须要与老板磋商调整老本指标。
低成本带来的次要挑战在于，往往只有通过“翻新”能力实现低成本指标。这里的“翻新”包含创始全新的技术畛域（对大多数公司来说要求过高），也包含引入新技术。如果没有找到解决问题的新技术，那么就须要本人开发新技术。这是低成本架构设计的次要复杂性所在。
有很多相似的新技术呈现，我来举几个例子。
- NoSQL（如 Memcache 和 Redis）的呈现是为了解决关系型数据库无奈应答高并发拜访带来的压力。
- 全文搜索引擎（如 Sphinx、Elasticsearch 和 Solr）的呈现是为了解决关系型数据库 like 搜寻的效率问题。
- Hadoop 的呈现是为了解决传统文件系统无奈应答海量数据存储和计算的问题。
以下是一些业界相似的例子：
- Facebook 为了解决 PHP 低效的问题，首先采纳了 HipHop PHP，将 PHP 翻译成 C ++ 并执行。之后，Facebook 转向 HHVM，将 PHP 翻译成字节码并应用虚拟机执行，相似于 Java 的 JVM。
- 新浪微博将传统的 Redis/MC + MySQL 架构扩大为 Redis/MC + SSD Cache + MySQL 架构，其中 SSD Cache 作为 L2 缓存应用，解决了 MC/Redis 老本高和容量小的问题，同时也解决了穿透数据库带来的拜访压力问题（起源：http://www.infoq.com/cn/articles/weibo-platform-archieture）。
- LinkedIn 为了解决每天 5 千亿事件，开发了高效的 Kafka 音讯零碎。
- 还有许多相似的例子，如将 Ruby on Rails 改为 Java，将 Lua + Redis 改为 Go 语言实现等。
引入新技术和本人发明新技术都是简单的工作。引入新技术的次要挑战在于须要相熟新技术，并将其与现有技术联合起来。而本人发明新技术的次要挑战在于须要发明新的理念和技术，并且新技术须要与旧技术相比具备质的飞跃。
总的来说，发明新技术的难度更大，因而中小型公司通常借助引入新技术来达成低成本指标。大公司则更有可能本人发明新技术，因为只有大公司才有足够的资源、技术和工夫去发明新技术。
平安
平安是一个宏大而又简单的技术畛域，一旦呈现问题，会对业务和企业形象产生微小的影响。例如：
- 2016 年，雅虎曝出了史上最大规模的信息泄露事件，超过 5 亿用户的材料在 2014 年被窃取。
- 2016 年 10 月，美国蒙受了史上最大规模的 DDoS 攻打，导致东海岸的网站个体瘫痪。
- 2013 年 10 月，浙江慧达驿站网络有限公司为全国 4500 多家酒店提供网络服务，因安全漏洞而导致 2 千万条入住酒店的客户信息泄露，引发了许多讹诈和家庭破裂等后续事件。
正是因为常常产生各种安全事件，大多数技术人员和架构师对平安问题有了更多的理解和思考。
从技术的角度来看，平安问题能够分为两类：性能上的平安和架构上的平安。
1. 性能平安
常见的 XSS 攻打、CSRF 攻打、SQL 注入、Windows 破绽、明码破解等平安问题，实质上是因为零碎实现存在破绽，黑客能够利用这些破绽入侵零碎。这种行为与小偷利用家庭不欠缺的中央潜入进行毁坏或偷盗的形式相似。因而，性能平安的目标是“防小偷”。
从实现的角度来看，性能平安与具体的编码相干，与架构关系不大。当初很多开发框架都内置了常见的平安性能，缩小了平安相干性能的反复开发，但框架只能预防常见的安全漏洞和危险（例如 XSS 攻打、CSRF 攻打、SQL 注入等），无奈预知新的平安问题。此外，框架自身也存在破绽（例如，风行的 Apache Struts2 就屡次爆出了调用近程代码执行的高危破绽），给整个互联网造成了肯定的恐慌。因而，性能平安是一个逐步完善的过程，须要有针对性地提出解决方案来应答新呈现的平安问题。咱们无奈预测零碎下一个破绽在哪里，也不敢说本人的零碎必定没有任何问题。换句话说，性能平安是一个“攻”与“防”的矛盾，须要在攻防大战中逐步完善，而不能在零碎架构设计的时候一劳永逸地解决。
2. 架构平安
如果说性能平安是“防小偷”，那么 架构平安就是“ 防匪徒 ”。匪徒能够采纳暴力手段入侵零碎，例如用大锤将门砸开，或者用炸药将围墙炸倒。相比之下，小偷所做的只是偷东西，而匪徒则可能成心搞破坏，对系统的影响也更大。因而，在架构设计时须要特地关注架构平安，尤其是在互联网时代，实践上来说零碎部署在互联网上时，寰球任何中央都能够发动攻打。
传统的架构平安次要依附防火墙，防火墙最根本的性能就是隔离网络，通过将网络划分成不同的区域，制订出不同区域之间的 拜访控制策略 来管制不同信赖水平区域间传送的数据流。例如，下图是一个典型的银行零碎的平安架构。
从图中你能够看到，整个零碎依据不同的分区部署了多个防火墙来保证系统的平安。
除了依附运营商和云服务商，还有一些技术手段能够应答互联网零碎的架构平安问题，例如：
- CDN（内容散发网络）：CDN 能够缓存网站的动态资源，加重源站的压力，同时也能起到肯定的进攻作用，抵挡轻量级的攻打。CDN 提供商也个别会提供一些根本的防护服务，例如对常见的 DDoS 攻打进行荡涤。
- 反向代理：反向代理能够通过限度用户拜访频率、申请流量、IP 地址等，对歹意攻打进行肯定水平的拦挡。
- 分布式架构：采纳分布式架构能够将零碎部署在多台服务器上，通过负载平衡等伎俩来解决高并发申请。这样能够防止单点故障，同时也能在肯定水平上进步零碎的抗攻击能力。
- 破绽扫描和危险评估：针对互联网零碎的架构平安问题，能够应用破绽扫描工具对系统进行扫描，发现安全漏洞，及时进行修复。同时也能够进行危险评估，剖析零碎存在的危险和安全隐患，有针对性地进行平安布局和布局。
总之，在互联网畛域，架构平安是一个非常复杂的问题，须要综合思考多个因素。除了技术手段，还须要从治理、人员和流程等多个方面进行布局和治理，能力确保零碎的平安和稳固。
规模
的确，这种状况在企业级零碎中很常见。在零碎开发的过程中，为了应答一直变动的需要，往往会增加各种性能和逻辑，然而不足对系统整体架构的布局和治理，导致系统变得越来越简单、难以了解和保护。
此外，企业级零碎往往面向简单的业务场景和业务流程，其中波及到的各种规定、束缚和限度十分多，这些规定可能存在互相矛盾的状况，导致系统逻辑变得更加简单。同时，为了保证系统的正确性和可靠性，往往须要进行大量的异样解决、日志记录等操作，这些操作也会减少零碎的复杂度。
最初，随着零碎的倒退，很多晚期版本的代码可能会被保留下来，而这些代码可能曾经过期、冗余或者存在破绽，然而因为不足保护和更新，这些代码依然在零碎中存在，进一步减少了零碎的复杂度。
因而，在开发企业级零碎时，须要留神对系统的整体架构进行布局和治理，防止过多的性能堆砌和逻辑分支，同时保障代码的可读性、可维护性和可扩展性，这样能力确保零碎的长期衰弱倒退。
规模带来复杂度的次要起因就是“质变引起量变”，当数量超过肯定的阈值后，复杂度会产生质的变动。常见的规模带来的复杂度有：
1. 性能越来越多，导致系统复杂度指数级回升
例如，某个零碎开始只有 3 大性能，起初一直减少到 8 大性能，尽管还是同一个零碎，但复杂度曾经相差很大了，具体相差多大呢？
我以一个简略的形象模型来计算一下，假如零碎间的性能都是两两相干的，零碎的复杂度 = 性能数量 + 性能之间的连贯数量，通过计算咱们能够看出：
- 3 个性能的零碎复杂度 = 3 + 3 = 6
- 8 个性能的零碎复杂度 = 8 + 28 = 36
能够看出，具备 8 个性能的零碎的复杂度不是比具备 3 个性能的零碎的复杂度多 5，而是多了 30，根本是指数级增长的，次要起因在于随着零碎性能数量增多，性能之间的连贯呈指数级增长。下图形象地展现了性能数量的增多带来了复杂度。
通过肉眼就能够很直观地看出，具备 8 个性能的零碎复杂度要高得多。
2. 数据越来越多，零碎复杂度产生量变
随着数据规模的增长，传统的数据处理技术曾经无奈胜任，导致系统的复杂度减少。这也是“大数据”技术畛域的衰亡，其实践根底是 Google 发表的三篇大数据相干论文，包含 Google File System、Google Bigtable 和 Google MapReduce，它们创始了一个新的技术畛域。大数据技术的利用可能更无效地解决海量数据，进步数据处理效率和准确性。然而，大数据技术的引入也会给零碎架构设计带来新的复杂度，例如如何抉择适合的大数据存储系统、如何设计分布式计算模型等问题。因而，零碎设计师须要具备深刻的技术常识和实践经验，能力在设计中均衡各种因素，以实现零碎高效、牢靠、可扩大等要求。
即便咱们的数据没有达到大数据规模，数据的增长也可能给零碎带来复杂性。最典型的例子莫过于应用关系数据库存储数据，我以 MySQL 为例，MySQL 单表的数据因不同的业务和利用场景会有不同的最优值，但不管怎样都必定是有肯定的限度的，个别举荐在 5000 万行左右。如果因为业务的倒退，单表数据达到了 10 亿行，就会产生很多问题，例如：
- 增加索引会很慢，可能须要几个小时，这几个小时内数据库表是无奈插入数据的，相当于业务停机了。
- 批改表构造和增加索引存在相似的问题，耗时可能会很长。
- 即便有索引，索引的性能也可能会很低，因为数据量太大。
- 数据库备份耗时很长。
- ……
因而，当 MySQL 单表数据量太大时，咱们必须思考将单表拆分为多表，这个拆分过程也会引入更多复杂性，例如：
- 拆表的规定是什么？
以用户表为例：是依照用户 id 拆分表，还是依照用户注册工夫拆表？
- 拆完表后查问如何解决？
以用户表为例：假如依照用户 id 拆表，当业务须要查问学历为“本科”以上的用户时，要去很多表查问能力失去最终后果，怎么保障性能？
小结
明天我剖析了低成本给架构设计带来的次要复杂度体现在引入新技术或发明新技术，探讨了从性能平安和架构平安引入的复杂度，以及规模带来复杂度的次要起因是“质变引起量变”
本文由 mdnice 多平台公布
