10 | 架构设计流程：识别复杂度

精选留言(63)

• 

  pk

  文中有一句话：TPS 1780 并不高。这个结论怎么来的？作者经验丰富，见过很高的TPS。 但作为新手，如何衡量这个性能要求高还是不高呢？

  作者回复: 对于架构师来说，常见系统的性能量级需要烂熟于心，例如nginx负载均衡性能是3万左右，mc的读取性能5万左右，kafka号称百万级，zookeeper写入读取2万以上，http请求访问大概在2万左右。
  具体的数值和机器配置以及测试案例有关，但大概的量级不会变化很大。
  
  如果是业务系统，由于业务复杂度差异很大，有的每秒500请求可能就是高性能了，因此需要针对业务进行性能测试，确立性能基线，方便后续架构设计做比较。

  2018-05-21

   1

   107
• 

  公号-代码荣耀

  识别复杂度心得
  
  架构设计由需求所驱动，本质目的是为了解决软件系统的复杂性；为此，我们在进行架构设计时，需要以理解需求为前提，首要进行系统复杂性的分析。具体做法是：
  
  （1）构建复杂度的来源清单——高性能、可用性、扩展性、安全、低成本、规模等。
  
  （2）结合需求、技术、团队、资源等对上述复杂度逐一分析是否需要？是否关键？
  
  “高性能”主要从软件系统未来的TPS、响应时间、服务器资源利用率等客观指标，也可以从用户的主观感受方面去考虑。
  
  “可用性”主要从服务不中断等质量属性，符合行业政策、国家法规等方面去考虑。
  
  “扩展性”则主要从功能需求的未来变更幅度等方面去考虑。
  
  （3）按照上述的分析结论，得到复杂度按照优先级的排序清单，越是排在前面的复杂度，就越关键，就越优先解决。
  
  需要特别注意的是：随着所处的业务阶段不同、外部的技术条件和环境的不同，得到的复杂度问题的优先级排序就会有所不同。一切皆变化。

  2018-05-19

   2

   53
• 

  XP

  感觉这个专栏定位是扫盲，留言的读者都是老司机

  作者回复: 应该是兄台水平高，所以觉得定位是扫盲，实际上很多人不知道这些内容，上网搜索也搜不到的

  2018-05-19

  

   44
• 

  云辉

  复杂度问题，还有是方案简单，但是沟通协调成本高，跨部门了，请问华仔，你们是自己推动，还是技术PMO推动。

  作者回复: 架构师推动是主要的，架构师需要五项全能：技术，沟通，推动，管理，撕逼😃😃😃

  2018-05-20

   1

   28
• 

  空档滑行

  说下之前改造的一个系统，当时是这个系统从其他系统同步数据，经过一整套流程后将数据拆解到本地库的各个业务表中。
  原来的系统是一个单机多线程程序，到了大促的时候延时非常厉害，因为马上又要大促了，首先想到的是扩展性的问题，于是就做了无状态服务拆分，可以横向扩展。在这过程成因为要控制单个同步实体任务的并发在处理幂等性上也花很大的功夫。做完这个后，又对非关键流程做了消息解耦，提高主流程的处理速度。
  系统上线后运行稳定，但是到了大促当日发现速度提升很有限，将机器扩展到10台速度只提升了2-3倍，而且数据库和应用压力都很小。
  后来分析下来瓶颈竟然是在数据库中间件上。其他系统大量的慢sql导致中间件处排队严重。
  现在想起来，其实还是改造前优先级没搞清楚，根据之前的经验就把问题归结到扩展性上，投入了大部分精力在扩展性和可用性上，而没有对原来单机系统的性能做完整的测试和评估。其实当时做一个单机程序的压测大概就可以判断出问题所在(改造过程中也发现老的程序确实有bug)。还有就是高性能的优先级远大于扩展性和可用性，因为这个系统重启的影响非常小。改造的时候过于理想化的，想做一个各个方面均衡完善的架构

  作者回复: 所以系统复杂度识别是非常重要的，也没那么容易

  2018-05-20

  

   18
• 

  三月沙@wecatch

  专栏本身的牛逼之处在于系统化，相似概念其实在日常架构中已经多有涉及，但是专栏用自己独有的方法论浅显易懂的论述了这些概念以及它们的关系，值得在缺乏经验的团队广而告之

  2018-05-29

  

   12
• 

  herome

  最近在做一个平台化的crm系统，也就是公司各个业务线都可以接入 ，或者外面的业务线也能接入。但是我们在开发过程中，比如查看商家等级列表这个接口，以前所有的接入方，都是查看就是查看，但是有个主要对接方提出了个需求是，查看后如果不存在 就插入一个默认等级。，但是其他对接方没有这样的需求，也就说原接口不能变，如果没有其他接入方我直接修改原来的接口即可，根本不考虑兼容。类似的问题数不胜数， 我们每次要么是if else这种代码走不同的逻辑，要么是 新写个接口，现在我们的代码的维护已经很混乱了，一个简单的逻辑，如查看等级列表，我就要维护好几套接口，好几套逻辑。 有想过变成可配置化的，但是没有好的思路。华哥对这方面有好的建议吗？😂

  作者回复: 试试设计模式的策略模式或者职责链模式

  2018-05-19

  

   12
• 

  黑客悟理

  留言全是干货……

  2018-05-26

  

   11
• 

  huayu00

  “http请求访问大概在2万左右”
  请问这个是指什么，数字怎么得来的？

  2018-06-23

  

   7
• 

  joyafa

  我现在做的是交易转发网关，性能瓶颈很大一部分也受上级券商网关影响，系统无状态，无数据库操作，因为涉及到交易，对可用性要求很高，需要能快速处理客户端的请求，经过多次压测，也没有排查出自身系统问题出在哪里，对系统压测，以及测试得到的数据该怎么分析，怎么找出问题所在？

  作者回复: 网关的性能可以参考nginx的性能，如果你们的测试数据和nginx做网关差异很大，那可能是并发模型甚至记日志这些不起眼的操作给拖慢了，如果差不多，那基本就是性能极限了

  2018-05-31

  

   4
• 

  renwotao

  公司架构日志占了百分之二十的cpu，有什么好的解决方案吗

  作者回复: 日志压缩，采样，隔离

  2018-06-13

  

   3
• 

  Sir Peng

  华仔，架构师要具备的五项全能中，"撕逼"能在哪种情况中得已体现？

  作者回复: 说服别人重构，选择方案等很多时候要撕逼😂😂

  2018-05-24

  

   3
• 

  行下一首歌

  微服务架构，是解决了什么复杂性问题呢

  作者回复: 可扩展

  2018-05-21

  

   3
• 

  DullBird

  分析现在做的采集系统，主要是控制单系统融合了（前端业务，任务调度,分发，自实现系统内缓存，采集机状态管理，数据入库功能）。采集机主要实现了所有的采集功能，采集机是集群的。业务性能要求比较低，页面基本没什么人访问，后台业务主要分采集项，频繁的一点就任务A是10分钟1W个任务（不间断），任务B是4小时内完成2W个任务，分析业务不是瓶颈，但是2W个任务由于依赖客户提供的登入方式实际采集耗时在10小时左右（这点问题应该需要协调客户处理或者换方式实现）。
      主要复杂度在于系统的耦合性，控制单系统功能太多了，想添加一个任务逻辑的复杂模块，很难加。想拆分成子系统（分为前端子系统，缓存子系统，采集机管理子系统，数据入库子系统，任务调度子系统。前二个优先级比较高，后面的可以等需要的时候拆分），把单系统内的调用替换成rpc框架的系统间调用，但是系统间调用比原来的调用多了一种超时状态。原来的系统状态性比较强，如果远程调用的不确定性，可能需要业务改为无状态的。那么需要改动的量比较大。（rpc调用异常的处理方式了结的比较少，希望老师给点指点，谢谢）。
      其次复杂度在于高可用，我们的系统宕机时间没有那么严格，但是需要在一定时间内切换，30分钟即可。采集机集群通过任务轮询，已经实现了高可用。但是控制单系统做高可用有一个问题是单系统实现了内部的缓存，如果不把缓存抽离出来就会有一致性问题。然后实现主备，单节点可用，出了故障另外一台设备升级为主节点，通过协商的方式。（脑裂的情况暂不考虑，客户的内网相对稳定。通过监控人工来恢复。）

  2018-05-20

  

   3
• 

  彡工鸟

  个人看法，在顶层上看一个系统，确实会有高可用，高性能，可扩展等等多个复杂度的要求，而且可能还真的无法分出个优先级。这样就落到都要抓，都要硬，最终无法分出个主次，导致设计四不像的系统出来。针对这种情况，是否就应该动用子系统一说，将系统拆分到一定的粒度，可以聚焦到一个，或者至多两个复杂度上？而子系统自然有子系统的架构设计，技术选型来针对性地解决其复杂度问题

  作者回复: 这是一种思路，比较适合业务系统，中间件系统就不太适合这种方式

  2018-05-20

  

   3
• 

  xiaoya

  我是个新手，听一遍就忘了。记住的不多😭不开心。是我接触的太少不太重视这些吧，这些很关键?这么多理论的东西，嗨，我心性太差了。一口老想都吃掉，结果都不好。认识自己驾驭自己，一点点

  作者回复: 我也是从新手过来的，坚持就有收获，不要求一次就全部听懂了，

  2018-08-02

  

   2
• 

  张国胜

  高可用和高扩展两块有问题。高可用问题提现在，整个系统很脆弱，容易出现某块的性能故障，如数据库的io暴涨导致所有业务访问出现问题。或者发送验证码的业务出现故障，导致用户无法下单，但没有验证码实际上可以不用与是否下单成功相关联。出现问题后，由于业务复杂，难以排查问题。
  高扩展问题提现在，整个系统都是为了完成业务功能在写，基本没有抽象和设计模式，导致业务很难扩展，基本上就在之前的基础上来回改。

  2018-06-28

  

   2
• 

  何晓亮

  留言中提到了常见系统性能量级，问一下windows系统的量是怎么样的？

  2018-06-26

  

   2
• 

  重剑

  太棒了，对于我这种菜鸟来说讲的很好！

  2018-05-29

  

   2
• 

  Ryan Feng

  tps、qps一般用什么测？我看你的tps是qps十倍，意思就是多少子系统就是多少倍？这个数据不考虑网络通讯和系统复杂度差异吗？

  作者回复: 这是假设的，具体业务具体分析，可以用压测工具测试系统的能力，用监控系统监控线上的实际数值

  2018-05-23

  

   2