从0开始学架构
李运华
资深技术专家
立即订阅
38968 人已学习
课程目录
已完结 59 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 照着做,你也能成为架构师!
免费
基础架构 (13讲)
01 | 架构到底是指什么?
02 | 架构设计的历史背景
03 | 架构设计的目的
04 | 复杂度来源:高性能
05 | 复杂度来源:高可用
06 | 复杂度来源:可扩展性
07 | 复杂度来源:低成本、安全、规模
08 | 架构设计三原则
09 | 架构设计原则案例
10 | 架构设计流程:识别复杂度
11 | 架构设计流程:设计备选方案
12 | 架构设计流程:评估和选择备选方案
13 | 架构设计流程:详细方案设计
高性能架构模式 (8讲)
14 | 高性能数据库集群:读写分离
15 | 高性能数据库集群:分库分表
16 | 高性能NoSQL
17 | 高性能缓存架构
18 | 单服务器高性能模式:PPC与TPC
19 | 单服务器高性能模式:Reactor与Proactor
20 | 高性能负载均衡:分类及架构
21 | 高性能负载均衡:算法
高可用架构模式 (10讲)
22 | 想成为架构师,你必须知道CAP理论
23 | 想成为架构师,你必须掌握的CAP细节
24 | FMEA方法,排除架构可用性隐患的利器
25 | 高可用存储架构:双机架构
26 | 高可用存储架构:集群和分区
27 | 如何设计计算高可用架构?
28 | 业务高可用的保障:异地多活架构
29 | 异地多活设计4大技巧
30 | 异地多活设计4步走
31 | 如何应对接口级的故障?
可扩展架构模式 (6讲)
32 | 可扩展架构的基本思想和模式
33 | 传统的可扩展架构模式:分层架构和SOA
34 | 深入理解微服务架构:银弹 or 焦油坑?
35 | 微服务架构最佳实践 - 方法篇
36 | 微服务架构最佳实践 - 基础设施篇
37 | 微内核架构详解
架构实战 (13讲)
38 | 架构师应该如何判断技术演进的方向?
39 | 互联网技术演进的模式
40 | 互联网架构模板:“存储层”技术
41 | 互联网架构模板:“开发层”和“服务层”技术
42 | 互联网架构模板:“网络层”技术
43 | 互联网架构模板:“用户层”和“业务层”技术
44 | 互联网架构模板:“平台”技术
45 | 架构重构内功心法第一式:有的放矢
46 | 架构重构内功心法第二式:合纵连横
47 | 架构重构内功心法第三式:运筹帷幄
48 | 再谈开源项目:如何选择、使用以及二次开发?
49 | 谈谈App架构的演进
50 | 架构实战:架构设计文档模板
特别放送 (7讲)
架构专栏特别放送 | “华仔,放学别走!”第1期
架构专栏特别放送 | “华仔,放学别走!” 第2期
如何高效地学习开源项目 | “华仔,放学别走!” 第3期
架构师成长之路 | “华仔,放学别走!” 第4期
架构师必读书单 | “华仔,放学别走!” 第5期
新书首发 | 《从零开始学架构》
致「从0开始学架构」专栏订阅用户
结束语 (1讲)
结束语 | 坚持,成就你的技术梦想
从0开始学架构
登录|注册

07 | 复杂度来源:低成本、安全、规模

李运华 2018-05-12
关于复杂度来源,前面的专栏已经讲了高性能、高可用和可扩展性,今天我来聊聊复杂度另外三个来源低成本、安全和规模

低成本

当我们的架构方案只涉及几台或者十几台服务器时,一般情况下成本并不是我们重点关注的目标,但如果架构方案涉及几百上千甚至上万台服务器,成本就会变成一个非常重要的架构设计考虑点。例如,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/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《从0开始学架构》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(56)

  • 公号-代码荣耀
    今日心得

    低成本

    What:低成本是架构设计中需要考虑一个约束条件,但不会是首要目标。低成本本质上是与高性能和高可用冲突的,当无法设计出满足成本要求的方案,就只能协调并调整成本目标。

    How:一般通过“创新”达到低成本的目标。(1)引入新技术。主要复杂度在于需要去熟悉新技术,并且将新技术与已有技术结合;一般中小型公司基本采用该方式达到目标。(2)开创一个全新技术领域。主要复杂度在于需要去创造全新的理念和技术,并且与旧技术相比,需要有质的飞跃,复杂度更高;一般大公司拥有更多的资源、技术实力会采用该方式来达到低成本的目标。

    安全

    What:安全是一个庞大而又复杂的技术领域,一旦出问题,对业务和企业形象影响非常大。从技术的角度来讲,包括(1)功能安全-“防小偷”,减少系统潜在的缺陷,阻止黑客破坏行为;(2)架构安全—“防强盗”,保护系统不受恶意访问和攻击,保护系统的重要数据不被窃取。由于是蓄意破坏系统,因此对影响也大得多。架构设计时需要特别关注架构安全。

    How:(1)功能安全。是一个逐步完善的过程,而且往往都是在问题出现后才能有针对性的提出解决方案,与编码实现有关。(2)架构安全。传统企业主要通过防火墙实现不同区域的访问控制,功能强大、性能一般,但是成本更高。互联网企业更多地是依靠运营商或者云服务商强大的带宽和流量清洗的能力,较少自己来设计和实现。

    规模

    What:规模带来复杂度的主要原因就是“量变引起质变”,当数量超过一定的阈值后,复杂度会发生质的变化。随着业务的发展,规模带来的常见复杂度有(1)业务功能越来越多,调用逻辑越来越复杂;(2)数据容量、类型、关联关系越来越多。

    How:规模问题需要与高性能、高可用、高扩展、高伸缩性统一考虑。常采用“分而治之,各个击破”的方法策略。

    是否还有其他复杂度原因?- 可伸缩性

    当前大型互联网网站需要面对大量用户高并发访问、存储更多数据、处理更高频次的用户交互。网站系统一般通过多种分布式技术将多台服务器组成集群对外提供服务。伸缩性一般是系统可以根据需求和成本调整自身处理能力的一种能力。伸缩性常意味着系统可以通过低成本并能够快速改变自身的处理能力以满足更多用户访问、处理更多数据而不会对用户体验造成任何影响。

    伸缩性度量指标包括(1)处理更高并发;(2)处理更多数据;(3)处理更高频次的用户交互。

    其复杂度体现在(1)伸——增强系统在上述三个方面的处理能力;(2)缩——缩减系统处理能力;(3)上述伸缩过程还必须相对低成本和快速。
    2018-05-12
    88
  • RookieDBA
    老师你好,请问后续的课程会有如何画好架构图的方法探讨或者方法论么?工作中时常因为汇报要画架构图,又总觉得自己架构图画不好。有没有推荐学习的材料。谢谢

    作者回复: 4+1视图,业界标准,对着画八九不离十

    2018-05-15
    28
  • 黑客悟理
    “具备 8 个功能的系统的复杂度不是比具备 3 个功能的系统的复杂度多 5,而是多了 30,基本是指数级增长的,主要原因在于随着系统功能数量增多,功能之间的连接呈指数级增长。” 这个叫。指数级增长不合适吧,这就是一个n(n-1)/2的关系。
    2018-05-20
    12
  • 孙振超
    架构设计中最为重要的是考虑各种非功能性需求,同样的功能但不同的非功能性需求设计方案会有很大的不同,比如登陆系统,功能都是相同,但一个要求是100/s,另一个是10w/s,,这两个架构是完全不一样。在实际情况下在安全性上的考虑会弱些,需要借助于专门的安全团队去进行评估和提供建议,架构师更多的精力在性能、容量、高可用、扩展性等方面

    作者回复: 赞同,通俗的说法是功能需求和质量需求

    2018-05-29
    8
  • 张平
    内容比较理论化,有点像教科书,科普一下还行

    作者回复: 别急,一步一步来,后面会讲。而且现状就是大部分人都没有架构设计的体系理论指导,全靠自己摸索,效率很低,成长很慢

    2018-05-14
    8
  • 万里晴空
    有时间就会看一遍,然后听音频。虽然有的听不懂,但是嵌套在我们系统上看,从设计的时候有的还是没有考虑到,比如这次讲的低成本的取舍还有前几次讲的高可用。接听重复听吧!
    2018-05-12
    6
  • 卡莫拉内西
    我们政府项目的场景复杂度估计还是在安全和高可用上,其他的性能,扩展,成本相对要求较低
    2018-05-13
    5
  • 老胡
    低成本考验技术团的技术选型,架构,设计,编码能力与掌握等
    比如脸谱转成java,就少了很多事情。选择对一个技术可以减少很多成本。
    低成本与高性能没有直接冲突,比如三十台服务才能支持一万五Tps,但是设计,架构,编码优化只要五台就可以到一万五。

    dubbo,打算实现无阻塞,那性能提高一倍,哪得少多少服务。

    应该说高性能是降低成本的手段,通过增加服务提高所谓的Tps,那是增加性能。而是高性能。

    低成本的确与高可用直接犯冲,优化空间小。
    短信系统并发一千五,需要八核服务,要高可用就得两台八核的。解决是两台四核,每台七百五,如果一台挂了,另外一台可用,但是容量少了而已,服务有限流,压力都到一台也没关系。
    短信以前就是一百的Tps,一千五十台,技术技术优化就两台。

    关于安全,这只会使用大众方案,或者一些微微深入的,这点实在没啥说的。我安全原则就是严,细。

    规模,这份问题与低成本其实差不多。
    应该分业务规模与性能规模。
    深入分析业务,可以解决不少问题。
    比如十个模块,只有两三个是核心的,一些并发低,数据小,热点数据缓存把多个模块合在一起,减少复杂度。
    多个系统有很多类似的功能或者模块,可以整合在一起座位基础系统。等等

    技术,架构,设计,编码是解决低成本,规模,安全的最基础,最重要的手段。
    2018-05-13
    4
  • 苟哥
    我们现在做的项目是一个针对教培机构的一站式营销解决方案平台。有个疑问想请教老师,目前数据规模还不大,所以单机即可满足,但是接下去随着用户量、和业务数据量的增大,我应该在哪个节点去往集群的方式部署呢?有没有一个评估的方法论?

    作者回复: 对单机进行性能测试,获得单机性能的极限数据,当业务实际性能达到极限的80%时,开始考虑扩容

    2018-05-23
    3
  • 少年
    根据当前项目情况,认为可扩展性是最复杂最难处理的。
    简述:访问量在升,业务在不断变化
    难点:
    1. 业务方面,功能无法正常迭代(小公司),旧功能可能重构,新功能有时需要兼容旧功能,技术尚未实现,复杂度就显而易见
    2. 技术方面,单体架构,面向过程编程,各个模块之间依赖严重(典型的例子就是一堆left join),重构功能时代码基本全部重写。
    3. 部分公用模块(无源码),对修改关闭,对扩展也关闭,导致一些需求无法满足。

    我的解决方案:
    项目全部重构代价太大,那姑且以当前架构入手:
    1. 拒绝不合理需求,拒绝对现有功能的大修改
    2. 新功能开发,严格控制模块依赖,做好逻辑分层
    3. 针对单个的功能,逐步进行逻辑分离,最后逐步实现服务分离,逐步向分布式发展

    请老师批评指正,谢谢
    2018-05-12
    3
  • 陈问渔
    2018年,美国东部时间 2 月 28 日,GitHub 在一瞬间遭到高达 1.35Tbps 的带宽攻击。这应该才是现在现在最大的拒绝服务攻击~

    作者回复: 我写初稿的时候还没到2018年😄

    2018-10-24
    2
  • 品闲生活
    系统的复杂度 = 功能数量 + 功能之间的连接数量
    应该是乘法吧?

    作者回复: 其实我没有从数学角度论证,只是简单说明一下

    2018-05-14
    2
  • 波波安
    作为我们这种乙方公司,客户的主观意愿也是复杂度的一方面。
    目前做运营商的项目,成本考虑的较少,主要是高可用,安全性,高性能,规模化这几个方面。
    其中高可用和安全性要求最高。
    2018-05-12
    2
  • Geek_88604f
    关于规模的论述非常经典,上升到了哲学的高度。量变是质变的必要准备,质变是量变的必然结果。当规模随着业务的发展逐渐增大时复杂度逐渐增加。一旦规模超过一定的量级时复杂度就会出现指数级的上升,完全超出预计。因此要做到在规模上升的时候不断演进架构,不断重构代码,并起且做好运维监控,防微杜渐。
            软件领域的成本和硬件领域的成本有很大的不同。在硬件领域随着规模的增大成本会降低,基本上是一次性的技术成本,因为根据摩尔定律,每一美元买到的电脑性能将每隔18~24个月翻一倍。软件领域为什么会不一样呢?归根到底是软件销售模式发生了变化,以前软件的销售模式和硬件的销售模式是一致的,开发出了一个软件产品到处复制销售,每卖出一份软件产品和卖出一块CPU是等同的,卖的多成本就可以持续下降——薄利多销。现在软件的销售模式发生了很大的变化,是账号+充值+移动消费。用户侧的开销很小,只需要一个浏览器就可以了,软件能力基本在服务端,这就导致了服务端规模上升成本就上升的尴尬境地,要想降低成本必须寻找新的技术和方法,而新的方法和技术需要创新,创新后还要引入到现有的生产环节和现有的技术结合,复杂度可想而知,成本的投入是持续的。
            云化架构下安全带来的复杂度主要体现在如下两方面:一是物理部署架构的变化,同一个系统的不同子系统部署在不同的安全区域,不同的安全区域需要不同的安全策略和不同的安全技术。另一个是不同的安全区域之间的通信需要选择或研发新的协议。原本简洁的网络通讯变得复杂和难以理解。

    作者回复: 感谢你的分享,非常有见地👍

    2019-08-03
    1
  • 胖胖的程序猿
    规模是引发一切问题的根源
    1、规模小,功能简单,数据少,基本上就不会存在太大的性能问题,系统简单稳定高可用,顶多加个主从备份,不需要扩展,
    单机就能支持成本比较低
    2、规模大
         (1)功能越来越多,越来越复杂,可能引发性能问题,必要时进行系统拆分,原先设计扩展性差需要重构
         (2)业务数据大,数据的存储难度,读写速度,需要引入相关大数据技术。
         系统部署更多机器,成本上升,各系统间调用如何保证高可用

    一般而言安全方面主要由专门安全团队负责,不大考虑。
    2019-03-27
    1
  • gevin
    架构设计是要解决软件系统的复杂性,我觉得软件系统还有一个复杂性是,业务逻辑的复杂性,这个主要靠需求分析和业务架构设计来解决,这个靠软件架构设计比较难解决吧?

    从这个角度出发,是不是架构设计之初,先要分业务架构设计和软件架构设计两步走?

    作者回复: 业务逻辑复杂性属于可扩展范围,有的系统并没有业务复杂度,例如Nginx,MySQL这些中间件系统

    2018-11-01
    1
  • 日光倾城
    针对我们整个p2p平台,主要还是高可用和安全方面的考量导致的复杂度!当然我觉得针对系统的各个模块,可能侧重的点又不一样,有的侧重高性能,有的侧重可扩展。我们需要抓住模块的复杂度痛点,然后设法去解决它,老师说的六大复杂度点,值得我们结合系统深入研究

    作者回复: 是的,每个子系统都有自己的复杂度,不是说一个业务下所有系统复杂度都是一样的

    2018-05-21
    1
  • 小飞哥 ‍超級會員
    觉得后面这几节课讲的太严肃了,都有点听不懂了,虽然是很面的,但讲的氛围让人走心。
    老师能否讲课向两个人聊天一样,让人听着不那么累!

    作者回复: 如果是我们两聊天我可以根据你的习惯来交流,专栏面向的用户太多,不同用户口味不同,我只能优先保证正确性,逻辑性,条理性,对于趣味性,我还要修炼修炼😃

    2018-05-18
    1
  • 合民
    首先感谢作者的分享,学到很多思考的角度。作者是从系统技术角度分析复杂度,我想补充下系统实施的角度。随着系统的规模、技术难度的增加,实施难度也在增加,需要做的辅助工作越来越多,比如需求文档、技术文档、学习成本,如果这些辅助工作没做好,那么实施难度会越来越高,团队成员的更换成本非常高,所以我认为实施难度也是复杂度来源之一!

    作者回复: 是的,架构师要考虑团队技术实力

    2018-05-15
    1
  • Even
    我们做银行内部系统的,企业架构和老师贴出来的类似,公司的系统多了,一般都有一套模板架构,例如普通的web系统,在安全方面考虑的并不多,就是一些XSS, SQL注入等之类的问题。
    最近两年公司开始用公有云了,安全方面会多一些,例如使用VPN技术,bluecoat 代理,API的认证等方面,不知道这次有没有安全方面比较详细的讲解,谢谢老师。

    作者回复: 安全我不专业,而且安全一般由专业公司完成,较少自己完全设计和实现

    2018-05-13
    1
收起评论
56
返回
顶部