复杂度来源------低本钱、安全、规模

        软件系统复杂度的别的三个来源低本钱、安全、规模
  低本钱

          当架构方案只涉及几台或者十几台服务器时，一般情况下本钱并不是我们重点关注的目标，假如架构方案涉及几百上千甚至上万台服务器，本钱就会酿成一个非常紧张的架构计划考虑点。
          当我们计划“高性能”“高可用”的架构时，通用的本领都是增长更多服务器来满足“高性能”和“高可用”的要求；而低本钱恰好与此相反，我们需要减少服务器的数量才能告竣低本钱的目标。因此，低本钱本质上是与高性能和高可用辩说的，所以低本钱很多时候不会是架构计划的首要目标，而是架构计划的附加束缚。也就是说，我们首先设定一个本钱目标，当我们根据高性能、高可用的要求计划出方案时，评估一下方案是否能满足本钱目标，假如不行，就需要重新计划架构；假如无论如何都无法计划出满足本钱要求的方案，那就只能找老板调整本钱目标了。
          低本钱给架构计划带来的重要复杂度表现在，往往只有“创新”才能达到低本钱目标。这里的“创新”既包括开创一个全新的技能领域(这个要求对绝大部分公司太高)，也包括引入新技能，假如没有找到能够解决自己题目标新技能，那么就真的需要自己创造新技能了。
    类似的新技能例子。
  

• 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 年雅虎爆出史上最大规模信息泄露事件，逾 5 亿用户资料在 2014 年被窃取。
  
• 2016 年 10 月美国遭史上最大规模 DDoS 攻击，东海岸网站集体瘫痪。
  
• 2013 年 10 月，为天下 4500 多家酒店提供网络服务的浙江慧达驿站网络有限公司，因安全漏洞题目，致 2 千万条入住酒店的客户信息泄露，由此导致很多敲诈、家庭破裂的后续事件。
  

  正因为经常能够看到或者听到各类安全事件，所以大部分技能人员和架构师，对安全这部分会多一些了解和考虑。
          从技能的角度来讲，安全可以分为两类：一类是功能上的安全，一类是架构上的安全。
      1. 功能安全
          例如，常见的 XSS 攻击、CSRF 攻击、SQL 注入、Windows 漏洞、暗码破解等，本质上是因为系统实现有漏洞，黑客有了可乘之机。黑客会利用各种漏洞潜入系统，这种行为就像小偷一样，黑客和小偷的手法都是利用系统或家中不完善的地方潜入，并举行破坏或者偷取。因此形象地说，功能安全实在就是“防小偷”。
          从实现的角度来看，功能安全更多地是和具体的编码相关，与架构关系不大。现在很多开发框架都内嵌了常见的安全功能，能够大大减少安全相关功能的重复开发，但框架只能预防常见的安全漏洞和风险(常见的 XSS 攻击、CSRF 攻击、SQL 注入等)，无法预知新的安全题目，而且框架自己很多时候也存在漏洞(例如，流行的 Apache Struts2 就多次爆出了调用远程代码实行的高危漏洞，给整个互联网都造成了一定的恐慌)。所以功能安全是一个徐徐完善的过程，而且往往都是在题目出现后才能有针对性的提出解决方案，我们永远无法预测系统下一个漏洞在哪里，也不敢说自己的系统肯定没有任何题目。换句话讲，功能安全实在也是一个“攻”与“防”的矛盾，只能在这种攻防大战中徐徐完善，不可能在系统架构计划的时候一劳永逸地解决。
      2. 架构安全
          假如说功能安全是“防小偷”，那么架构安全就是“防强盗”。强盗会直接用大锤将门砸开，或者用暴力将围墙炸倒；小偷是偷东西，而强盗很多时候就是故意搞破坏，对系统的影响也大得多。因此架构计划时需要特殊关注架构安全，尤其是互联网期间，理论上来说系统部署在互联网上时，全球任何地方都可以发起攻击。
          传统的架构安全重要依靠防火墙，防火墙最基本的功能就是隔离网络，通过将网络分别成差别的区域，制定出差别区域之间的访问控制策略来控制差别信托程度区域间传送的数据流。例如，下图是一个典范的银行系统的安全架构。
  
     

   
  从图中可以看到，整个系统根据差别的分区部署了多个防火墙来保证系统的安全。
          防火墙的功能虽然强盛，但性能一般，所以在传统的银行和企业应用领域应用较多。但在互联网领域，防火墙的应用场景并不多。因为互联网的业务具有海量用户访问和高并发的特点，防火墙的性能不足以支持；尤其是互联网领域的 DDoS 攻击，轻则几 GB，重则几十 GB。2016 年着名安全研究人员布莱恩·克莱布斯(Brian Krebs)的安全博客网站遭遇 DDoS 攻击，攻击带宽达 665Gbps，是目前在网络犯罪领域已知的最大的拒绝服务攻击。这种规模的攻击，假如用防火墙来防，则需要部署大量的防火墙，本钱会很高。
          就算是公司对钱不在乎，一般也不会堆防火墙来防 DDoS 攻击，因为 DDoS 攻击最大的影响是大量斲丧机房的出口总带宽。不管防火墙处理本领有多强，当出口带宽被耗尽时，整个业务在用户看来就是不可用的，因为用户的正常请求已经无法到达系统了。防火墙能够保证内部系统不受冲击，但用户也是进不来的。对于用户来说，业务都已经受到影响了，至于是因为用户自己进不去，照旧因为系统出故障，用户实在根本不会关心。
          基于上述原因，互联网系统的架构安全目前并没有太好的计划本领来实现，更多地是依靠运营商或者云服务商强盛的带宽和流量洗濯的本领，较少自己来计划和实现。
  规模

          很多企业级的系统，既没有高性能要求，也没有双中央高可用要求，也不需要什么扩展性，但往往我们一说到这样的系统，很多人都会脱口而出：这个系统好复杂！为什么这样说呢？关键就在于这样的系统往往功能特殊多，逻辑分支特殊多。特殊是有的系统，发展时间比较长，不断地往上面叠加功能，厥后的人由于不熟悉整个发展历史，可能连很多功能的应用场景都不清楚，或者细节根本无法掌握，面对的就是一个黑盒系统，看不懂、改不动、不敢改、修不了，复杂度自然就感觉很高了。
          规模带来复杂度的重要原因就是“量变引起质变”，当数量凌驾一定的阈值后，复杂度会发生质的变化。常见的规模带来的复杂度有：
            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 拆表，当业务需要查询学历为“本科”以上的用户时，要去很多表查询才能得到最闭幕果，怎么保证性能？
  上一章: 复杂度来源--可扩展性
  下一章: 架构计划三原则
  归类: 从0开始学架构

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。