（架构设计）架构学习总结

Posted 2021-04-10 多元思维的开发者

架构设计：

1、架构演进：

1、单体	这是最原始的架构，将系统的所有功能都集中在一个工程中。 对于小应用，这是非常快捷；但是耦合强。
2、垂直架构	垂直架构与单体一样，都是将所有的功能都集中在一个系统项目中，一旦遇到系统的瓶颈，就在物理层面进行优化。
3、SOA	SOA：面向服务架构。以系统提供的服务为单位，设计、开发系统，将大系统按照服务进行分模块。
4、微服务	微服务是SOA的强化版，其核心思想也是面向服务。而微服务就是体现在一个微字，将系统服务原子化，单一职责化。尽可能的让一个模块、或子系统只负责一个功能或者是一类功能。

2、架构考虑因素：

1、正确性	确保基于当前架构设计，功能输出结果是正确的。当然，也有些业务场景是不需要绝对的正确，例如：天气预测结果
2、安全性	考虑系统可能面临或者常见的安全攻击，尤其是对于一些涉及金钱、商业机密数据，更是需要考虑；还有反爬虫，请求过滤之类等等。 例如：在哪些场景需要加密通讯，数据库的哪些业务数据需要脱敏、以及常见的CSRF、XSS和SQL攻击；定制网关，进行安全管理、风险控制。
3、高可用	定义系统可用级别（多少个9），而高可用一般都是依靠集群来保证的。然后，分析架构中哪一层需要集群化，最后进行压力测试、稳定性测试（连续、周期性、突发性测试）。 还可以对集群进行负载测试、性能测试，看看集群的运行是健康，资源最大化利用。
4、高性能	高性能最直观的感受和衡量标准就是RT了，请求响应速度越快越好，提高用户体验。
5、扩展性	扩展性，指如何在不改变原有代码、模块的基础上，对系统进行功能扩展。这也就是开放闭合原则。
6、伸缩性	伸缩性指的是集群的扩容和缩容，如何无感改变集群规模或者将扩容缩容的影响程度降到最低。这个对线上突发的洪峰具有很大的意义，能够及时缓解集群负载。
7、可维护性	可维护性，一般是指对当前系统进行功能无差异维护。主要体现在代码层面、代码的可读性、类的设计、模块的划分都对维护性具有相当的影响。
8、其他	除了上面考虑因素之外，还可能需要考虑搭建部署成本和难易程度，系统规模和复杂度以及技术选型和搭配等

3、架构分层：

代理层	用于反向代理，负载均衡。负责对请求进行重定向和分流作用。 常用：nginx，以及高级一点就是lvs + Nginx实现高可用的代理层甚至DNS也可以纳入此中
应用层	主要搭建平台、部署应用系统，对内外提供业务服务，一般地应用服务都以集群形式存在
存储层	数据落地存储，持久化；可以建立数据仓库用于数据挖掘，搜索层和缓存层的数据源。 常用mysql等关系型数据库、HBase等非关系型数据库以及分布式文件系统DFS
缓存层	用于常查询业务数据的缓存，提高查询响应速度。数据的来源主要是存储层，常用Redis。
搜索层	提供搜索服务，从存储层或MQ队列中的数据建立索引，提供应用层进行搜索。 常用：elasticsearch、solar
中间层	中间层是介于代理层和应用层之间，所以我称它中间层。主要提供静态资源请求和MQ消息缓存服务。 1、静态资源请求服务：主要体现在图片、视频、文件等不会轻易变化的静态资源的请求处理。这些静态资源会有相应的应用提供处理服务：例如FastDFS。 2、MQ：主要用于削峰、失败隔离、异步调用的作用。例如：kafka、RabbitMQ
监控层	主要负责各个层的系统运行日志的采集、处理，形成直观的监控数据并展示。 常用的：ELK、Flume和logstash

在大多数的公司，主要是对代理层、MQ层、缓存层、应用层、存储层的搭建和开发。对于监控层和搜索层，要么使用集成的，要么就是没有应用场景。其中，最主要还是对应用层的开发。首先会对应用层的业务进行模块划分、然后集群化提高系统可用性。

4、架构设计原则：

合适原则	这个主要体现在技术选型和搭配上，系统的搭建和开发主要是需要结合业务场景和技术或语言特性来综合考虑，甚至还需要对团队人员、项目进度和资源调配来快抉择；并不是业界主流才是最优最好的选择。
简单原则	这个简单实际的意思是：架构层次分明易懂、易替换、易扩展、模块或组件之间依赖关系简单。 可以归类为： 1、结构简单：模块数量适中、依赖关系简单、架构层次分明 2、逻辑简单：模块、组件系统单一职责化
演化原则	演化就是指系统会随着业务场景的变化而不断调整架构，因为业务场景不可能一成不变，很多时候也很难考虑以后可能会出现的场景；因此，系统的架构也不可能永远不变。 能做到的就是，分析好当前的业务场景、并尽可能考虑到未来（1~3年）业务场景变化趋势，从而设计出适合当前场景的架构系统；并结合时间推进，对系统的架构持续跟进和调整（有用的保留和优化、无用的去除、留有应对变化的plan B）。