架构漫谈和入门
本文主要是自己接触架构的一些输出漫谈
cfeng 在work中某次负责了后端一个服务的上线,多个模块一起上,结果上线失败,幸运的是,没有对用户造成什么损失,但是这次失败也让cfeng 意识到可能不只是保证我们code准确无误,还需要站在整个宏观系统的角度去思量很多。
cfeng现在对于架构的理解也是很模糊的,个人感觉架构不是具象的,而是抽象的一种方法论。从我们技术人员的角度来说,就是怎么样搭建我们这个系统才能让系统更高效稳定。
互联网的技术总是在不断变迁的,技术架构也是在不断变化。架构是个抽象的可大可小的一个概念,比如机器是单点还是集群,对于单体我们这个产品的模块如何划分,是分层还是其他的模式…
我们其实最容易接触的就是单体架构。这里的“单体” 说的是机器,相对单体,那么就有“分布式的架构”, 所以这里就是我们整体的机器的搭建的一种选择,流量大或小?流量小自然没必要去用分布式,因为分布式要考虑的问题也更多并且成本也更高。
相信大家或多或少都听说过MVC和三层架构,这是计算机领域比较经典的架构,MVC是一种架构模式思想,而三层架构就是经典的分层架构。
MVC 架构模式:
MVC: Model View Controller
View 视图: 负责页面的展示和用户的交互功能,从XX系统命令式交互到网页都是这个概念
Controller 控制器: 控制器就是接受视图传来的请求并选择一个Model模型进行处理,处理完之后再返回给视图。 【Spring的controller就更容易理解】
Model 模型 : 模型持有数据,状态和逻辑,接受数据进行处理返回最终的结果
Layered Architecture 是互联网的经典架构。我们最熟知的计算机网络七层模型就是一种分层的思想。 分层体现了高内聚低耦合的概念,各层各司其职,围绕本层的职责范围做事,这样就将一个大问题进行了逐步的拆分。并且不容易出错。
像计算机网络分层模型一样,这里给出一个四层的分层架构模型【关键就是不同的layer】:
应用在流量小的时候,只需要单体架构就可以达到效果。但是就算是在单体架构时,应用内部使用分层架构思想也能提升工作效率
随着时代发展,流量增加,简单使用单体架构就能完成功能变得很理想化。应用变得越来越复杂。 然后就出现了分布式微服务,将单个应用拆分成了多个应用,并且集群部署,通过网络通信
将不同的应用组织起来。
应用数量的增加,也就需要出现分布式架构,一些分布式的组件,比如负载均衡,分布式缓存解决方案、分布式链路通信,分布式事务,分布式配置中心、注册中心等开始出现。we需要考虑的东西也越来越多 ----- 应用通信、服务治理、持续集成。
同时一个应用可能会分化成一些关键的模块: 比如XX呼叫中心、告警中心、监控中心…这些整体的技术和模块就像一块块积木,我们需要考虑如何去搭建这些积木才能让整个结构屹立不倒。
整体上讲,在如今前后端分离大流行的时代,整个架构技术可以分为前端【接入层】技术和后端【服务层】技术,同时在云技术盛行的当下,还有就是我们的运维端【技术保障层】
cfeng之前的博客过了一遍Vue3并实现了一个简易的博客demo,前端也早已不是简单的html + css + JavaScript了,各种前端框架像Vue、React都是使用很广泛的。
并且前端是一个泛概念,不只是包含基础的PC前端,像移动OS、跨平台、小程序等和用户进行交互的都属于前台的概念范围。
cfeng在work发现官网的前台只适配了PC端,移动端打开不符合预期,需要泛【大】前端的概念
前端最核心就是保证用户的体验,不管说页面的响应速度还是页面的美观等。
由于cfeng 目前的重心还是在服务端,前端的理解不深,这部分都以后有就会再谈。
服务端主要就是业务处理效率和准确。前端传入的数据后台要正确的进行相应的响应。很多时候数据抽象一下基本就是那么几种:任务、内容、订单。
数据通过接入层传递给后端之后,可能会激活很多不同的模块和相关中间件进行配合。后台就需要应对这些复杂性,同时要特别考虑使用中间件的配合和整个系统的可靠性。
对于现在的分布式架构,各种各样中间件层出不求,中间件为调用提供了很好的封装性,让使用变得容易,但是cfeng认为只有自己理解如何实现中间件我们才能更好的处理问题。 之前文章我们主要分享了Spring Cloud下面的相关的中间件解决方案,但是都是迅速的过了一遍,后续可能会对这些内容进行深耕。
后台的一个重要点就是事务,像交易系统或者任务系统都有大量的面向事务的存储场景,分布式环境下可能会出现分库分表,分库带来的就是分布式事务的考量。
接入层主要服务用户的交互体验,服务端主要支撑数据处理,运维端就需要保证产品能够稳定的为用户带来优质的体验。
随着单体架构向分布式架构演进,运维的复杂度也在迅速上升,这也是需要考虑的高可用
,在高可用架构下,需要具有强大的监控能力和故障恢复能力。
运维端的常见技术就是Docker 、K8s等和云原生相关的技术,K8s把IaaS和PaaS融为一体,为应用治理提供了各种解决方案。
监控系统的关键在于及时发现问题,定位问题往往比解决问题更加困难。当然业内也有相关的解决方案:(cfeng之前work中是产品自己监控自己),像Hickwall用于指标监控,CAT可以监控调用链路,CLog可以管理日志,还有Zabbix、Prometheus…
还有就是网络的相关问题,比如网络阻塞,比如机房物理破坏…这些都需要做好相应的预警方案。
架构本身就是一种方法论,在不同的业务阶段,不同的时代背景可能体现不同的架构方案。比如在数据量小的单体架构时代就不需要考虑三高问题。
后续在大流量时代,分布式架构下服务分层,各层服务进行隔离化和透明化,方便进行解耦和部署,同时拆分之后可以进行集群扩展; 集群就更好的配合高可用,各个业务系统通过SOA基于服务进行,快速进行系统的搭建。
分布式下需要考虑的问题: 高可用、高性能,高并发; 可扩展
在分布式架构下,我们可能就需要考虑很多问题:
在大数据时代,同时出现的就是云原生架构,云原生之前的文章简述过,关键技术就是容器化、微服务、快速交付和Dev&ops,同时随着人工智能的快速发展,产品或多或少都集成AI进行赋能。像精准化营销,个性化推荐,人工智能机器人。【we 需要不断的去拥抱变化】