07 | 复杂度来源：低成本、安全、规模
李运华
该思维导图由 AI 生成，仅供参考
关于复杂度来源，前面的专栏已经讲了高性能、高可用和可扩展性，今天我来聊聊复杂度另外三个来源低成本、安全和规模。
低成本
当我们的架构方案只涉及几台或者十几台服务器时，一般情况下成本并不是我们重点关注的目标，但如果架构方案涉及几百上千甚至上万台服务器，成本就会变成一个非常重要的架构设计考虑点。例如，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 类似。
新浪微博将传统的 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 千万条入住酒店的客户信息泄露，由此导致很多敲诈、家庭破裂的后续事件。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
大规模服务器架构设计中的复杂度主要源自低成本、安全和规模三个方面。在追求高性能和高可用性的同时，低成本要求却需要减少服务器数量以节约成本，因此低成本与高性能、高可用存在冲突，成为架构设计的附加约束。创新成为实现低成本目标的关键，而创新的复杂度主要体现在引入新技术和自行创造新技术上。另外，安全领域的复杂性涉及功能安全和架构安全两方面，尤其在面对大规模DDoS攻击时的挑战。此外，规模带来的复杂度主要原因在于“量变引起质变”，功能和数据的增多都会导致系统复杂度的质的变化。文章通过深入分析了这些复杂度来源，为读者提供了对大规模服务器架构设计复杂性的深入了解。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《从 0 开始学架构》，新⼈⾸单¥68
《从 0 开始学架构》，新⼈⾸单¥68
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(85)
- 最新
- 精选
RookieDBA老师你好，请问后续的课程会有如何画好架构图的方法探讨或者方法论么？工作中时常因为汇报要画架构图，又总觉得自己架构图画不好。有没有推荐学习的材料。谢谢作者回复: 4+1视图，业界标准，对着画八九不离十
2018-05-15283
孙振超架构设计中最为重要的是考虑各种非功能性需求，同样的功能但不同的非功能性需求设计方案会有很大的不同，比如登陆系统，功能都是相同，但一个要求是100/s，另一个是10w/s，，这两个架构是完全不一样。在实际情况下在安全性上的考虑会弱些，需要借助于专门的安全团队去进行评估和提供建议，架构师更多的精力在性能、容量、高可用、扩展性等方面作者回复: 赞同，通俗的说法是功能需求和质量需求
2018-05-2931
张平内容比较理论化，有点像教科书，科普一下还行作者回复: 别急，一步一步来，后面会讲。而且现状就是大部分人都没有架构设计的体系理论指导，全靠自己摸索，效率很低，成长很慢
2018-05-14229
苟哥我们现在做的项目是一个针对教培机构的一站式营销解决方案平台。有个疑问想请教老师，目前数据规模还不大，所以单机即可满足，但是接下去随着用户量、和业务数据量的增大，我应该在哪个节点去往集群的方式部署呢？有没有一个评估的方法论？作者回复: 对单机进行性能测试，获得单机性能的极限数据，当业务实际性能达到极限的80%时，开始考虑扩容
2018-05-2324- Geek_88604f关于规模的论述非常经典，上升到了哲学的高度。量变是质变的必要准备，质变是量变的必然结果。当规模随着业务的发展逐渐增大时复杂度逐渐增加。一旦规模超过一定的量级时复杂度就会出现指数级的上升，完全超出预计。因此要做到在规模上升的时候不断演进架构，不断重构代码，并起且做好运维监控，防微杜渐。 软件领域的成本和硬件领域的成本有很大的不同。在硬件领域随着规模的增大成本会降低，基本上是一次性的技术成本，因为根据摩尔定律，每一美元买到的电脑性能将每隔18～24个月翻一倍。软件领域为什么会不一样呢？归根到底是软件销售模式发生了变化，以前软件的销售模式和硬件的销售模式是一致的，开发出了一个软件产品到处复制销售，每卖出一份软件产品和卖出一块CPU是等同的，卖的多成本就可以持续下降——薄利多销。现在软件的销售模式发生了很大的变化，是账号+充值+移动消费。用户侧的开销很小，只需要一个浏览器就可以了，软件能力基本在服务端，这就导致了服务端规模上升成本就上升的尴尬境地，要想降低成本必须寻找新的技术和方法，而新的方法和技术需要创新，创新后还要引入到现有的生产环节和现有的技术结合，复杂度可想而知，成本的投入是持续的。 云化架构下安全带来的复杂度主要体现在如下两方面:一是物理部署架构的变化，同一个系统的不同子系统部署在不同的安全区域，不同的安全区域需要不同的安全策略和不同的安全技术。另一个是不同的安全区域之间的通信需要选择或研发新的协议。原本简洁的网络通讯变得复杂和难以理解。
作者回复: 感谢你的分享，非常有见地👍
2019-08-0318 
丁丁历险记有幸在15年遭遇30g 流量冲击。 直接被机房下架。作者回复: 这是标准的处理方法，因为机房里面除了你的业务外还有很多业务，攻击你们的业务的时候把带宽都占满了，其它业务一样受影响，只能丢车保帅 ：）
2021-01-159
陈问渔2018年，美国东部时间 2 月 28 日，GitHub 在一瞬间遭到高达 1.35Tbps 的带宽攻击。这应该才是现在现在最大的拒绝服务攻击~作者回复: 我写初稿的时候还没到2018年😄
2018-10-248
小飞哥 超級會員觉得后面这几节课讲的太严肃了，都有点听不懂了，虽然是很面的，但讲的氛围让人走心。 老师能否讲课向两个人聊天一样，让人听着不那么累！作者回复: 如果是我们两聊天我可以根据你的习惯来交流，专栏面向的用户太多，不同用户口味不同，我只能优先保证正确性，逻辑性，条理性，对于趣味性，我还要修炼修炼😃
2018-05-186
Up首先感谢作者的分享，学到很多思考的角度。作者是从系统技术角度分析复杂度，我想补充下系统实施的角度。随着系统的规模、技术难度的增加，实施难度也在增加，需要做的辅助工作越来越多，比如需求文档、技术文档、学习成本，如果这些辅助工作没做好，那么实施难度会越来越高，团队成员的更换成本非常高，所以我认为实施难度也是复杂度来源之一！作者回复: 是的，架构师要考虑团队技术实力
2018-05-154
Alex在实战中最大的挑战不是划分这6个维度，而是要结合本团队的研发能力、项目需要（时间要求），做出较优解来实现项目规模的扩大。 个人理解，6个维度是考虑问题的角度，做出分析，但最终还是要将架构扩展后的风险控制下来。从这个意义上讲，需求的理解是核心，离开需求单纯说架构没太大的意义。合适最重要作者回复: 解读很赞
2020-07-0923
收起评论
