07 | 复杂度来源：低成本、安全、规模
2018-05-12 李运华
《从 0 开始学架构》
课程介绍
讲述：黄洲君
时长:大小6.01M
关于复杂度来源，前面的专栏已经讲了高性能、高可用和可扩展性，今天我来聊聊复杂度另外三个来源低成本、安全和规模。
低成本
当我们的架构方案只涉及几台或者十几台服务器时，一般情况下成本并不是我们重点关注的目标，但如果架构方案涉及几百上千甚至上万台服务器，成本就会变成一个非常重要的架构设计考虑点。例如，A 方案需要 10000 台机器，B 方案只需要 8000 台机器，单从比例来看，也就节省了 20% 的成本，但从数量来看，B 方案能节省 2000 台机器，1 台机器成本预算每年大约 2 万元，这样一年下来就能节省 4000 万元，4000 万元成本不是小数目，给 100 人的团队发奖金每人可以发 40 万元了，这可是算得上天价奖金了。通过一个架构方案的设计，就能轻松节约几千万元，不但展现了技术的强大力量，也带来了可观的收益，对于技术人员来说，最有满足感的事情莫过于如此了。
当我们设计“高性能”“高可用”的架构时，通用的手段都是增加更多服务器来满足“高性能”和“高可用”的要求；而低成本正好与此相反，我们需要减少...
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
精选留言
公号-技术夜未眠2018-05-12今日心得
低成本
What：低成本是架构设计中需要考虑一个约束条件，但不会是首要目标。低成本本质上是与高性能和高可用冲突的，当无法设计出满足成本要求的方案，就只能协调并调整成本目标。
How：一般通过“创新”达到低成本的目标。（1）引入新技术。主要复杂度在于需要去熟悉新技术，并且将新技术与已有技术结合；一般中小型公司基本采用该方式达到目标。（2）开创一个全新技术领域。主要复杂度在于需要去创造全新的理念和技术，并且与旧技术相比，需要有质的飞跃，复杂度更高；一般大公司拥有更多的资源、技术实力会采用该方式来达到低成本的目标。
安全
What：安全是一个庞大而又复杂的技术领域，一旦出问题，对业务和企业形象影响非常大。从技术的角度来讲，包括（1）功能安全-“防小偷”，减少系统潜在的缺陷，阻止黑客破坏行为；（2）架构安全—“防强盗”，保护系统不受恶意访问和攻击，保护系统的重要数据不被窃取。由于是蓄意破坏系统，因此对影响也大得多。架构设计时需要特别关注架构安全。
How：（1）功能安全。是一个逐步完善的过程，而且往往都是在问题出现后才能有针对性的提出解决方案，与编码实现有关。（2）架构安全。传统企业主要通过防火墙实现不同区域的访问控制，功能强大、性能一般，但是成本更高。互联网企业更多地是依靠运营商或者云服务商强大的带宽和流量清洗的能力，较少自己来设计和实现。
规模
What：规模带来复杂度的主要原因就是“量变引起质变”，当数量超过一定的阈值后，复杂度会发生质的变化。随着业务的发展，规模带来的常见复杂度有（1）业务功能越来越多，调用逻辑越来越复杂；（2）数据容量、类型、关联关系越来越多。
How：规模问题需要与高性能、高可用、高扩展、高伸缩性统一考虑。常采用“分而治之，各个击破”的方法策略。
是否还有其他复杂度原因？- 可伸缩性
当前大型互联网网站需要面对大量用户高并发访问、存储更多数据、处理更高频次的用户交互。网站系统一般通过多种分布式技术将多台服务器组成集群对外提供服务。伸缩性一般是系统可以根据需求和成本调整自身处理能力的一种能力。伸缩性常意味着系统可以通过低成本并能够快速改变自身的处理能力以满足更多用户访问、处理更多数据而不会对用户体验造成任何影响。
伸缩性度量指标包括（1）处理更高并发；（2）处理更多数据；（3）处理更高频次的用户交互。
其复杂度体现在（1）伸——增强系统在上述三个方面的处理能力；（2）缩——缩减系统处理能力；（3）上述伸缩过程还必须相对低成本和快速。展开共 1 条评论164
RookieDBA2018-05-15老师你好，请问后续的课程会有如何画好架构图的方法探讨或者方法论么？工作中时常因为汇报要画架构图，又总觉得自己架构图画不好。有没有推荐学习的材料。谢谢作者回复: 4+1视图，业界标准，对着画八九不离十
共 2 条评论71
张平2018-05-14内容比较理论化，有点像教科书，科普一下还行作者回复: 别急，一步一步来，后面会讲。而且现状就是大部分人都没有架构设计的体系理论指导，全靠自己摸索，效率很低，成长很慢
共 2 条评论22
黑客悟理2018-05-20“具备 8 个功能的系统的复杂度不是比具备 3 个功能的系统的复杂度多 5，而是多了 30，基本是指数级增长的，主要原因在于随着系统功能数量增多，功能之间的连接呈指数级增长。” 这个叫。指数级增长不合适吧，这就是一个n(n-1)/2的关系。共 2 条评论21
孙振超2018-05-29架构设计中最为重要的是考虑各种非功能性需求，同样的功能但不同的非功能性需求设计方案会有很大的不同，比如登陆系统，功能都是相同，但一个要求是100/s，另一个是10w/s，，这两个架构是完全不一样。在实际情况下在安全性上的考虑会弱些，需要借助于专门的安全团队去进行评估和提供建议，架构师更多的精力在性能、容量、高可用、扩展性等方面作者回复: 赞同，通俗的说法是功能需求和质量需求
20
苟哥2018-05-23我们现在做的项目是一个针对教培机构的一站式营销解决方案平台。有个疑问想请教老师，目前数据规模还不大，所以单机即可满足，但是接下去随着用户量、和业务数据量的增大，我应该在哪个节点去往集群的方式部署呢？有没有一个评估的方法论？作者回复: 对单机进行性能测试，获得单机性能的极限数据，当业务实际性能达到极限的80%时，开始考虑扩容
15
Geek_88604f2019-08-03关于规模的论述非常经典，上升到了哲学的高度。量变是质变的必要准备，质变是量变的必然结果。当规模随着业务的发展逐渐增大时复杂度逐渐增加。一旦规模超过一定的量级时复杂度就会出现指数级的上升，完全超出预计。因此要做到在规模上升的时候不断演进架构，不断重构代码，并起且做好运维监控，防微杜渐。
软件领域的成本和硬件领域的成本有很大的不同。在硬件领域随着规模的增大成本会降低，基本上是一次性的技术成本，因为根据摩尔定律，每一美元买到的电脑性能将每隔18～24个月翻一倍。软件领域为什么会不一样呢？归根到底是软件销售模式发生了变化，以前软件的销售模式和硬件的销售模式是一致的，开发出了一个软件产品到处复制销售，每卖出一份软件产品和卖出一块CPU是等同的，卖的多成本就可以持续下降——薄利多销。现在软件的销售模式发生了很大的变化，是账号+充值+移动消费。用户侧的开销很小，只需要一个浏览器就可以了，软件能力基本在服务端，这就导致了服务端规模上升成本就上升的尴尬境地，要想降低成本必须寻找新的技术和方法，而新的方法和技术需要创新，创新后还要引入到现有的生产环节和现有的技术结合，复杂度可想而知，成本的投入是持续的。
云化架构下安全带来的复杂度主要体现在如下两方面:一是物理部署架构的变化，同一个系统的不同子系统部署在不同的安全区域，不同的安全区域需要不同的安全策略和不同的安全技术。另一个是不同的安全区域之间的通信需要选择或研发新的协议。原本简洁的网络通讯变得复杂和难以理解。展开作者回复: 感谢你的分享，非常有见地👍
12
卡莫拉内西2018-05-13我们政府项目的场景复杂度估计还是在安全和高可用上，其他的性能，扩展，成本相对要求较低8
万里晴空2018-05-12有时间就会看一遍，然后听音频。虽然有的听不懂，但是嵌套在我们系统上看，从设计的时候有的还是没有考虑到，比如这次讲的低成本的取舍还有前几次讲的高可用。接听重复听吧！8
老胡2018-05-13低成本考验技术团的技术选型，架构，设计，编码能力与掌握等
比如脸谱转成java，就少了很多事情。选择对一个技术可以减少很多成本。
低成本与高性能没有直接冲突，比如三十台服务才能支持一万五Tps，但是设计，架构，编码优化只要五台就可以到一万五。
dubbo，打算实现无阻塞，那性能提高一倍，哪得少多少服务。
应该说高性能是降低成本的手段，通过增加服务提高所谓的Tps，那是增加性能。而是高性能。
低成本的确与高可用直接犯冲，优化空间小。
短信系统并发一千五，需要八核服务，要高可用就得两台八核的。解决是两台四核，每台七百五，如果一台挂了，另外一台可用，但是容量少了而已，服务有限流，压力都到一台也没关系。
短信以前就是一百的Tps，一千五十台，技术技术优化就两台。
关于安全，这只会使用大众方案，或者一些微微深入的，这点实在没啥说的。我安全原则就是严，细。
规模，这份问题与低成本其实差不多。
应该分业务规模与性能规模。
深入分析业务，可以解决不少问题。
比如十个模块，只有两三个是核心的，一些并发低，数据小，热点数据缓存把多个模块合在一起，减少复杂度。
多个系统有很多类似的功能或者模块，可以整合在一起座位基础系统。等等
技术，架构，设计，编码是解决低成本，规模，安全的最基础，最重要的手段。展开共 1 条评论6
少年2018-05-12根据当前项目情况，认为可扩展性是最复杂最难处理的。
简述：访问量在升，业务在不断变化
难点：
1. 业务方面，功能无法正常迭代（小公司），旧功能可能重构，新功能有时需要兼容旧功能，技术尚未实现，复杂度就显而易见
2. 技术方面，单体架构，面向过程编程，各个模块之间依赖严重（典型的例子就是一堆left join），重构功能时代码基本全部重写。
3. 部分公用模块（无源码），对修改关闭，对扩展也关闭，导致一些需求无法满足。
我的解决方案：
项目全部重构代价太大，那姑且以当前架构入手：
1. 拒绝不合理需求，拒绝对现有功能的大修改
2. 新功能开发，严格控制模块依赖，做好逻辑分层
3. 针对单个的功能，逐步进行逻辑分离，最后逐步实现服务分离，逐步向分布式发展
请老师批评指正，谢谢展开6
小飞哥 超級會員2018-05-18觉得后面这几节课讲的太严肃了，都有点听不懂了，虽然是很面的，但讲的氛围让人走心。
老师能否讲课向两个人聊天一样，让人听着不那么累！作者回复: 如果是我们两聊天我可以根据你的习惯来交流，专栏面向的用户太多，不同用户口味不同，我只能优先保证正确性，逻辑性，条理性，对于趣味性，我还要修炼修炼😃
5
陈问渔2018-10-242018年，美国东部时间 2 月 28 日，GitHub 在一瞬间遭到高达 1.35Tbps 的带宽攻击。这应该才是现在现在最大的拒绝服务攻击~作者回复: 我写初稿的时候还没到2018年😄
4
品闲生活2018-05-14系统的复杂度 = 功能数量 + 功能之间的连接数量
应该是乘法吧？作者回复: 其实我没有从数学角度论证，只是简单说明一下
共 2 条评论3
Alex2020-07-09在实战中最大的挑战不是划分这6个维度，而是要结合本团队的研发能力、项目需要（时间要求），做出较优解来实现项目规模的扩大。
个人理解，6个维度是考虑问题的角度，做出分析，但最终还是要将架构扩展后的风险控制下来。从这个意义上讲，需求的理解是核心，离开需求单纯说架构没太大的意义。合适最重要作者回复: 解读很赞
2
gevin2018-11-01架构设计是要解决软件系统的复杂性，我觉得软件系统还有一个复杂性是，业务逻辑的复杂性，这个主要靠需求分析和业务架构设计来解决，这个靠软件架构设计比较难解决吧？
从这个角度出发，是不是架构设计之初，先要分业务架构设计和软件架构设计两步走？作者回复: 业务逻辑复杂性属于可扩展范围，有的系统并没有业务复杂度，例如Nginx，MySQL这些中间件系统
2
Up2018-05-15首先感谢作者的分享，学到很多思考的角度。作者是从系统技术角度分析复杂度，我想补充下系统实施的角度。随着系统的规模、技术难度的增加，实施难度也在增加，需要做的辅助工作越来越多，比如需求文档、技术文档、学习成本，如果这些辅助工作没做好，那么实施难度会越来越高，团队成员的更换成本非常高，所以我认为实施难度也是复杂度来源之一！作者回复: 是的，架构师要考虑团队技术实力
2
Even2018-05-13我们做银行内部系统的，企业架构和老师贴出来的类似，公司的系统多了，一般都有一套模板架构，例如普通的web系统，在安全方面考虑的并不多，就是一些XSS, SQL注入等之类的问题。
最近两年公司开始用公有云了，安全方面会多一些，例如使用VPN技术，bluecoat 代理，API的认证等方面，不知道这次有没有安全方面比较详细的讲解，谢谢老师。作者回复: 安全我不专业，而且安全一般由专业公司完成，较少自己完全设计和实现
2
约书亚2018-05-12一直觉得好多（包括我）架构师是从开发做起的，对可用性，性能，业务复杂度有些经验，但安全性上认识不足，知识缺乏，想重视但重视不起来。不知道大厂的情况如何？会不会有专门的安全性保障部门，或者安全架构师来审核架构设计？作者回复: 会的，安全专业性很强，一般程序员和架构师难以积累这部分的经验
2
波波安2018-05-12作为我们这种乙方公司，客户的主观意愿也是复杂度的一方面。
目前做运营商的项目，成本考虑的较少，主要是高可用，安全性，高性能，规模化这几个方面。
其中高可用和安全性要求最高。2