重庆联通的网站建设网站后台登陆口

一、识别复杂度

举例：设计一个亿级用户平台设计，直接对标腾讯的 QQ，按照腾讯 QQ的用户量级和功能复杂度进行设计，高性能、高可用、可扩展、安全等技术一应俱全，一开始就设计出了 40 多个子系统，然后投入大量人力开发了将近 1 年时间才跌跌撞撞地正式上线。上线后发现之前的过度设计完全是多此一举，而且带来很多问题：

1、系统复杂无比，运维效率低下，每次业务版本升级都需要十几个子系统同步升级，操作步骤复杂，容易出错，出错后回滚还可能带来二次问题。
2、每次版本开发和升级都需要十几个子系统配合，开发效率低下。
3、子系统数量太多，关系复杂，小问题不断，而且出问题后定位困难。
4、开始设计的号称 TPS 50000/ 秒的系统，实际 TPS 连 500 都不到。

由于业务没有发展，最初的设计人员陆续离开，后来接手的团队，无奈又花了 2 年时间将系统重构，合并很多子系统，将原来 40 多个子系统合并成不到 20 个子系统，整个系统才逐步稳定下来。

系统稳定性不高，经常出各种莫名的小问题；系统子系统数
量太多，系统关系复杂，开发效率低；不支持异地多活，机房级别的故障会导致业务整体不可用。如果同时要解决这些问题，就可能会面临这些困境：
要做的事情太多，反而感觉无从下手。
设计方案本身太复杂，落地时间遥遥无期。
同一个方案要解决不同的复杂性，有的设计点是互相矛盾的。例如，要提升系统可用性，就需要将数据及时存储到硬盘上，而硬盘刷盘反过来又会影响系统性能。
因此，正确的做法是将主要的复杂度问题列出来，然后根据业务、技术、团队等综合情况进行排序，优先解决当前面临的最主要的复杂度问题。

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

二、设计备选方案

第一种常见的错误：设计最优秀的方案。

第一种常见的错误：设计最优秀的方案。
1、备选方案的数量以 3 ~ 5 个为最佳。
2、备选方案的差异要比较明显。
3、备选方案的技术不要只局限于已经熟悉的技术。

第三种常见的错误：备选方案过于详细。

三、评估和选择备选方案

在完成备选方案设计后，如何挑选出最终的方案了，一般存在原因，举例：
1、每个方案都是可行的，如果方案不可行就根本不应该作为备选方案。
2、没有哪个方案是完美的。例如，A 方案有性能的缺点，B 方案有成本的缺点，C 方案有新技术不成熟的风险。
3、评价标准主观性比较强，比如设计师说 A 方案比 B 方案复杂，但另外一个设计师可能会认为差不多，因为比较难将“复杂”一词进行量化。因此，方案评审的时候我们经常会遇到几个设计师针对某个方案或者某个技术点争论得面红耳赤。
最后出现：最简派、最牛派、最熟派、领导派

列出我们需要关注的质量属性点，然后分别从这些质量属性的维度去评估每个方案，再综合挑选适合当时情况的最优方案。