php网站开发教程网,如何做自媒体和网站签约赚点击,爱看视频的网站,济宁那家做网站最好文章目录 识别复杂度识别复杂度实战 架构设计的本质目的是为了解决软件系统的复杂性#xff0c;所以在我们设计架构时#xff0c;首先就要分析系统的复杂性。只有正确分析出了系统的复杂性#xff0c;后续的架构设计方案才不会偏离方向#xff1b;否则#xff0c;如果对系… 文章目录 识别复杂度识别复杂度实战 架构设计的本质目的是为了解决软件系统的复杂性所以在我们设计架构时首先就要分析系统的复杂性。只有正确分析出了系统的复杂性后续的架构设计方案才不会偏离方向否则如果对系统的复杂性判断错误即使后续的架构设计方案再完美再先进都是南辕北辙做的越好错的越多、越离谱。
识别复杂度
架构的复杂度主要来源于“高性能”“高可用”“可扩展”等几个方面但架构师在具体判断复杂性的时候不能生搬硬套认为任何时候架构都必须同时满足这三方面的要求。
实际上大部分场景下复杂度只是其中的某一个少数情况下包含其中两个如果真的出现同时需要解决三个或者三个以上的复杂度要么说明这个系统之前设计的有问题要么可能就是架构师的判断出现了失误即使真的认为要同时满足这三方面的要求也必须要进行优先级排序。
例如如果一个系统的复杂度本来是业务逻辑太复杂功能耦合严重架构师却设计了一个TPS达到50000/秒的高性能架构即使这个架构最终的性能再优秀也没有任何意义因为架构没有解决正确的复杂性问题。
曾经有个“亿级用户平台”失败的案例设计对标腾讯的QQ按照腾讯QQ的用户量级和功能复杂度进行设计高性能、高可用、可扩展、安全等技术一应俱全一开始就设计出了40多个子系统然后投入大量人力开发了将近1年时间才跌跌撞撞地正式上线。上线后发现之前的过度设计完全是多此一举而且带来很多问题
系统复杂无比运维效率低下每次业务版本升级都需要十几个子系统同步升级操作步骤复杂容易出错出错后回滚还可能带来二次问题。每次版本开发和升级都需要十几个子系统配合开发效率低下。子系统数量太多关系复杂小问题不断而且出问题后定位困难。开始设计的号称TPS 50000/秒的系统实际TPS连500都不到。
由于业务没有发展最初的设计人员陆续离开后来接手的团队无奈又花了2年时间将系统重构合并很多子系统将原来40多个子系统合并成不到20个子系统整个系统才逐步稳定下来。
如果运气真的不好接手了一个每个复杂度都存在问题的系统那应该怎么办呢答案是一个个来解决问题不要幻想一次架构重构解决所有问题。例如这个“亿级用户平台”的案例后来接手的团队其实面临几个主要的问题系统稳定性不高经常出各种莫名的小问题系统子系统数量太多系统关系复杂开发效率低不支持异地多活机房级别的故障会导致业务整体不可用。如果同时要解决这些问题就可能会面临这些困境
要做的事情太多反而感觉无从下手。设计方案本身太复杂落地时间遥遥无期。同一个方案要解决不同的复杂性有的设计点是互相矛盾的。例如要提升系统可用性就需要将数据及时存储到硬盘上而硬盘刷盘反过来又会影响系统性能。
因此正确的做法是将主要的复杂度问题列出来然后根据业务、技术、团队等综合情况进行排序优先解决当前面临的最主要的复杂度问题。“亿级用户平台”这个案例团队就优先选择将子系统的数量降下来后来发现子系统数量降下来后不但开发效率提升了原来经常发生的小问题也基本消失了于是团队再在这个基础上做了异地多活方案也取得了非常好的效果。
对于按照复杂度优先级解决的方式存在一个普遍的担忧如果按照优先级来解决复杂度可能会出现解决了优先级排在前面的复杂度后解决后续复杂度的方案需要将已经落地的方案推倒重来。这个担忧理论上是可能的但现实中几乎是不可能出现的原因在于软件系统的可塑性和易变性。对于同一个复杂度问题软件系统的方案可以有多个总是可以挑出综合来看性价比最高的方案。
即使架构师决定要推倒重来这个新的方案也必须能够同时解决已经被解决的复杂度问题一般来说能够达到这种理想状态的方案基本都是依靠新技术的引入。例如Hadoop能够将高可用、高性能、大容量三个大数据处理的复杂度问题同时解决。
识别复杂度对架构师来说是一项挑战因为原始的需求中并没有哪个地方会明确地说明复杂度在哪里需要架构师在理解需求的基础上进行分析。有经验的架构师可能一看需求就知道复杂度大概在哪里如果经验不足那只能采取“排查法”从不同的角度逐一进行分析。
识别复杂度实战
我们假想一个创业公司名称叫作“前浪微博”。前浪微博的业务发展很快系统也越来越多系统间协作的效率很低
例如
用户发一条微博后微博子系统需要通知审核子系统进行审核然后通知统计子系统进行统计再通知广告子系统进行广告预测接着通知消息子系统进行消息推送……一条微博有十几个通知目前都是系统间通过接口调用的。每通知一个新系统微博子系统就要设计接口、进行测试效率很低问题定位很麻烦经常和其他子系统的技术人员产生分岐微博子系统的开发人员不胜其烦。用户等级达到VIP后等级子系统要通知福利子系统进行奖品发放要通知客服子系统安排专属服务人员要通知商品子系统进行商品打折处理……等级子系统的开发人员也是不胜其烦。
新来的架构师在梳理这些问题时结合自己的经验敏锐地发现了这些问题背后的根源在于架构上各业务子系统强耦合而消息队列系统正好可以完成子系统的解耦于是提议要引入消息队列系统。经过一分析二讨论三开会四汇报五审批等一系列操作后消息队列系统终于立项了。其他背景信息还有
中间件团队规模不大大约6人左右。中间件团队熟悉Java语言但有一个新同事C/C很牛。开发平台是Linux数据库是MySQL。目前整个业务系统是单机房部署没有双机房。
针对前浪微博的消息队列系统采用“排查法”来分析复杂度具体分析过程是
这个消息队列是否需要高性能
我们假设前浪微博系统用户每天发送1000万条微博那么微博子系统一天会产生1000万条消息我们再假设平均一条消息有10个子系统读取那么其他子系统读取的消息大约是1亿次。
1000万和1亿看起来很吓人但对于架构师来说关注的不是一天的数据而是1秒的数据即TPS和QPS。我们将数据按照秒来计算一天内平均每秒写入消息数为115条每秒读取的消息数是1150条再考虑系统的读写并不是完全平均的设计的目标应该以峰值来计算。峰值一般取平均值的3倍那么消息队列系统的TPS是345QPS是3450这个量级的数据意味着并不要求高性能。
虽然根据当前业务规模计算的性能要求并不高但业务会增长因此系统设计需要考虑一定的性能余量。由于现在的基数较低为了预留一定的系统容量应对后续业务的发展我们将设计目标设定为峰值的4倍因此最终的性能要求是TPS为1380QPS为13800。TPS为1380并不高但QPS为13800已经比较高了因此高性能读取是复杂度之一。注意这里的设计目标设定为峰值的4倍是根据业务发展速度来预估的不是固定为4倍不同的业务可以是2倍也可以是8倍但一般不要设定在10倍以上更不要一上来就按照100倍预估。
这个消息队列是否需要高可用性
对于微博子系统来说如果消息丢了导致没有审核然后触犯了国家法律法规则是非常严重的事情对于等级子系统来说如果用户达到相应等级后系统没有给他奖品和专属服务则VIP用户会很不满意导致用户流失从而损失收入虽然也比较关键但没有审核子系统丢消息那么严重。
综合来看消息队列需要高可用性包括消息写入、消息存储、消息读取都需要保证高可用性。
这个消息队列是否需要高可扩展性
消息队列的功能很明确基本无须扩展因此可扩展性不是这个消息队列的复杂度关键。
为了方便理解这里我只排查“高性能”“高可用”“扩展性”这3个复杂度在实际应用中不同的公司或者团队可能还有一些其他方面的复杂度分析。例如金融系统可能需要考虑安全性有的公司会考虑成本等。
综合分析下来消息队列的复杂性主要体现在这几个方面高性能消息读取、高可用消息写入、高可用消息存储、高可用消息读取。
