什么是架构

架构和框架的区别

框架:
1.提供了组件的开发规范，比如为laravel开发组件，就要遵循其发布包的规范
2.提供了基础的开发功能，能够快速开发项目
3.更加在意规范

架构:
在意于基础的结构

从不同的角度出发，其机构不同
下面从三个角度出发说明，其它角度请搜索架构的"4+1视图"

从业务逻辑角度出发:
订单和物流模块都需要用户登录/注册以后才能使用

从部署角度出发:
可能业务比较简单，单机就搞定了

从开发规范出发(MVC):

为什么要做架构

为了解决复杂度带来的系统问题。

复杂度来源

对高性能的追求

对高性能的追求会带来复杂度，分为单机复杂度，和集群复杂度,任务分解复杂度

单机复杂度

单机的复杂度主要体现在2方面:
1.操作系统的抉择
2.进程，线程，协程之间的抉择

集群复杂度

在于引入了任务分配机制，要将任务分配到单机上去。复杂度体现在四个方面
1.用户的请求要怎么到达分配器上(DNS轮询，智能DNS等)
2.使用什么充当任务分配器。(nginx,LVS,还是自己写一个)。
3.分配器要和多台单机服务器连接，如何进行连接的管理。
4.分配器要使用什么算法去分配(轮询，随机，还是权重？)

任务分解复杂度

任务分解，可以理解为微服务,那么怎么分也是个复杂度:
1.分的多造成调用链路变长反而影响系统性能。
2.分的少，性能提升不大。

为啥拆分后性能能够提升呢？
1.单个服务变得简单，影响性能的点变少，更容易进行针对性优化。
2.复杂的系统，很难找到哪里影响了性能。还有可能优化了A点，不经意造成B点的性能下降(可能变成负优化)。
3.更容易进行修改。只需要修改要改的服务即可。不需要改动整个系统。
4.更容易进行扩容提升性能(如计算密集型服务:增加cpu强的服务器)

对高可用的追求

计算高可用的复杂度

指的是相同的数据，经过不同的服务器处理后，结果是相同的。
这个不是问题。问题在于高可用状态的决策: 高可用状态决策方式

存储高可用

如mysql的主从，存储高可用的复杂度在于：
如何减少和规避数据不一致对业务造成的影响。
例如:对实时性要求高的服务直接从主库读取数据。

对可扩展的追求

预测变化

复杂性有3方面:
1.不能对所有的点都考虑可扩展性
2.又不能不考虑可扩展性
3.考虑了，还有可能是错的

应对变化

我们知道应对变化，就是将不变的和会变的分层。分为：变化层，稳定层
但是谁在上，谁在下也是个问题。要根据实际情况来划分。

第一种常见于:
原先支持http请求，后来要求变成rpc或grpc这种情况

第二种常见于:
原先支持mysql，后来要求支持sqlserver或oracle这种情况

变化层和稳定层按照某种规则进行调用(接口约束)
这个接口的设计也有复杂度:
1.如何定义接口，23种设计模式使用哪几种，怎么用
2.接口一经定义，就很难再修改。设计的不好，影响后续扩展

对低成本的追求

对低成本的追求并不是架构的首要目标，而是作为架构的附带约束。
大公司通过创造技术来降低成本，小公司通过引入新技术降低成本，复杂度在于:
1.哪些技术适合现在的公司
2.引入和创造技术本身就具备复杂性

安全

功能安全

复杂度在于:

1. 如对(xss,csrf,sql注入的处理)
2. 框架，组件自带的bug(如:log4j漏洞)

架构安全

1.是否使用防火墙，怎么使用

当前对DDOS攻击(耗尽出口带宽)没有什么比较好的方法，主要还是依靠运营商强大的带宽和流量清洗能力。

规模

复杂度在于:
1.当功能变多后，其交互程密集的网状结构。需要考虑进行拆分
2.当数据量上来以后，需要对数据库进行分库，分表(怎么分也是个问题)