4.架构设计流程

4.架构设计流程

1.识别复杂度

确定了系统面临的主要复杂度问题，进而明确了设计方案的目标

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

2.设计备选方案

例如：高可用的主备方案、集群方案，高性能的负载均衡、
多路复用，可扩展的分层、插件化等技术，
绝大部分时候我们有了明确的目标后，按图索骥就能够找到可选的解决方案。

设计备选方案。架构设计备选方案的工作更多的是从需求、团队、技术、
    资源等综合情况出发，对主流、成熟的架构模式进行选择、组合、调整、创新。
1. 几种常见的架构设计误区
    (1)设计最优秀的方案。不要面向“简历”进行架构设计，而是要根据“合适”、“简
        单”、“演进”的架构设计原则，决策出与需求、团队、技术能力相匹配的合适方案。
    (2)只做一个方案。一个方案容易陷入思考问题片面、自我坚持的认知陷阱。
2. 备选方案设计的注意事项
     (1)备选方案不要过于详细。备选阶段解决的是技术选型问题，而不是技术细节。
     (2)备选方案的数量以 3~5个为最佳。
    (3)备选方案的技术差异要明显。
    (4)备选方案不要只局限于已经熟悉的技术。
3. 问题思考
    由于文中已经从开源、自研的角度提出了架构设计方案；为此，
    从架构设计三原则出发，也可考虑第四个备选方案：
    上云方案，该方案是直接采用商业解决方案，就好比阿里前期采用IOE类似。
如果是创业公司的业务早、中期阶段，
    可直接考虑采用阿里云/腾讯云，性能、HA、伸缩性都有保证。
此外，在文中备选方案1 - 开源方案中，如果从提供另外一种视角看问题的角度出发，
    个人会更加倾向于RabbitMQ。首先，RabbitMQ与Kafka都同样具备高可用、
    稳定性和高性能，但是，通过一些业界测试比较，RabbitMQ比Kafka更成熟、更可靠；
    其次，在高性能指标方面，Kafka胜出，kafka设计的初衷是处理日志，
    更适合IO高吞吐的处理。但是，对于“前浪微博”系统的QPS要求，
    RabbitMQ同样可以驾驭。为此，综合来看，会更加倾向于RabiitMQ。
    最后，通过本文再结合自己做技术最大的感悟是：做事情永远都要有B方案。

3.评估和选择备选方案

按优先级选择，即架构师综合当前的业务发展情况、团队人员规模和技能、
业务发展预测等因素，将质量属性按照优先级排序，首先挑选满足第一优先级的，
    如果方案都满足，那就再看第二优先级……以此类推。

4.详细方案设计–将方案涉及的关键技术细节给确定下来

简单来说，详细方案设计就是将方案涉及的关键技术细节给确定下来。
将所要实现的功能点所使用的技术进行拆分 细化其中的关键技术 并最终确定方案。