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

精选留言(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