架构设计流程

识别复杂度

之前说了为什么做架构：解决系统的复杂度
复杂度都找不到，做什么架构？
找到复杂度后，给复杂度排优先级顺序进行解决。
复杂度之间可能会有冲突，比如要求可用性,那么数据要写入磁盘，而磁盘写入会影响系统性能，要进行一定的取舍。
还有可能出现一种极端的情况:解决完复杂度1，解决复杂度2发现，不推翻复杂度1的解决方案无法解决复杂度2。但这现实中很少遇到，因为一个复杂度的解决方案有多种，选一种不用推翻复杂度1的解决方案即可。就算倒霉要推翻复杂度1的方案，那么新的方案要同时能够解决复杂度1和复杂度2。

设计备选方案

应该设计几个方案？

3~5个。数量适中，过多(浪费精力),过少(考虑不周)

不同的设计方案怎么进行对比?

不同的方案差异化要明显。

错误示例:
方案1:consul每五秒健康检查一次
方案2:consul每一秒健康检查一次
然后花费大量时间去论述五秒和一秒的区别。这应该归属于细节(架构方案确定后再去做的步骤)，而不是架构方案

注意事项

之前一直强调不要一上来就要设计最优(贪大贪全)。
什么简单原则，合适原则，演进原则全丢(这样是不对的)

要选择新的技术吗？

方案，不要只局限于自己熟悉的技术，闭关锁国的结果你是知道的

架构方案需要非常详细吗？

我们是做架构选型和设计，非常详细的内容是在架构确定后再做的(需要时间)。
虽然不用非常详细，但是架构师一定要熟悉关键的细节点。

方案选择

错误的选择方式

1.选择最简单的
2.选择最牛的
3.选择自己最熟悉的
4.让领导去选，反正我不背锅

正确的选择方式

应该从多个维度进行评估(如:性能，可用性，成本，研发周期，可扩展,复杂度等出发)

假设当前单体遇到瓶颈了，提供了两种方案进行比较。
1.单纯的增机器，形成集群
2.微服务

单体图

集群图

微服务图

维度	集群	微服务	谁比较好
性能	后期mysql会成为性能瓶颈	每个服务基本独立的mysql	微服务优于集群
复杂度	nginx做负载均衡	除了nginx做网关，还需要进行系统拆分，数据库拆分	集群优于微服务
成本	增加web服务器	增加web服务器和mysql服务器，web和mysql可以装在一台机器上	集群略优于微服务
扩展	单体代码逻辑复杂，难扩展	各个微服务单独扩展	微服务优于集群
可用性	mysql故障则整体故障	单个服务故障不会影响整体	微服务优于集群

评估完以后，我我们应该怎么进行选择:
1.谁优点数量多我选谁(这是错误的，每个维度的重要性是不同的)
举个例子：之前北京协和医院录取一个本科生
A:学校优于B,分数：390，论文:普通水平
B:分数:330,论文因子:3.7(博士论文水平)
按照优点数量多，那么应该录取A。但实际录取了B

有人说，看了上面的例子。增加一个权重
但是权重这种东西，是有人的主观性的。
比如同一个东西，有人认为值100，有人认为值50。

正确的选择应该是按照优先级。选择符合当下的(合适)。
回到单体和微服务。你第二天上班，发现系统有点吃力了。
你难不成要去拆分微服务吗？一天给你开发个新模块都不够，当然选择增加机子。
但不是说这样就完事了。你都到这个体量了，该拆分微服务了，赶紧叫公司招兵买马。

体量的选择

当确认完架构方案后，需要思考下按照什么体量做。
一般是按照当前规模的2～4倍做，比如当前QPS1000，那么我照着4000的干。
但是当前规模已经很大了，按照2倍做就行了，当前QPS10000，那么我按照着20000万干。
因为当基数大了以后，发展速度会变慢

详细的设计方案

架构选择结束后，就要出详细的设计方案了(要落地)
落地的话要求架构师要对关键的细节点有深入了解,比如说nginx的负载均衡使用什么算法(轮询，加权，hash等)
极端情况下，可能存在架构师遗漏关键技术点导致整体架构不可用或者开发周期过长。为了防止这种情况，可以采用下面解决方案：
1.采用架构师团队，集思广益,防止遗漏
2.分步骤，分阶段，分系统来降低复杂性(将复杂拆分为简单，防止遗漏关键细节)