架构漫谈和入门
内容管理
本文主要是自己接触架构的一些输出漫谈
cfeng 在work中某次负责了后端一个服务的上线，多个模块一起上，结果上线失败，幸运的是，没有对用户造成什么损失，但是这次失败也让cfeng 意识到可能不只是保证我们code准确无误，还需要站在整个宏观系统的角度去思量很多。
intro
cfeng现在对于架构的理解也是很模糊的，个人感觉架构不是具象的，而是抽象的一种方法论。从我们技术人员的角度来说，就是怎么样搭建我们这个系统才能让系统更高效稳定。
互联网的技术总是在不断变迁的，技术架构也是在不断变化。架构是个抽象的可大可小的一个概念，比如机器是单点还是集群，对于单体我们这个产品的模块如何划分，是分层还是其他的模式...
我们其实最容易接触的就是单体架构。这里的"单体" 说的是机器，相对单体，那么就有"分布式的架构"， 所以这里就是我们整体的机器的搭建的一种选择，流量大或小？流量小自然没必要去用分布式，因为分布式要考虑的问题也更多并且成本也更高。
分层架构
MVC模式
相信大家或多或少都听说过MVC和三层架构，这是计算机领域比较经典的架构，MVC是一种架构模式思想，而三层架构就是经典的分层架构。
j
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基于服务进行，快速进行系统的搭建。
分布式下需要考虑的问题： 高可用、高性能，高并发； 可扩展
在分布式架构下，我们可能就需要考虑很多问题：
- 如何保证高扩展性，比如业务快速扩张，如何灵活收缩。比如单体架构，本身就不具备集群，后期发展根本不适用
- 如何划分系统。 这个cfeng在work中也还有些茫， 一个重要的思想就是复用，我们要避免多个系统中冗余功能，把公共的大量使用的可聚合功能抽离成一个单独的子系统， 比如告警系统就可以抽离还有其他的比如支付平台、消息平台、物流平台、监控平台都是可以作为公共系统的
- 如何正确改造。系统review过程的改造可能很复杂，我们要正确的优化业务流程，明确目的，不能反向操作
- 分层体系的设计。微服务的拆分带来扩展性的同时也带来了复杂度，比如下单成功之后给用户加积分，如果是在一个系统，直接整个一个事务就可以了，但是现在可能拆分成不同的系统对应不同的dataBase，那么就需要有分布式事务的解决方案，比如一些补偿机制，状态机回调和消息队列的方式进行解耦保证最终状态一致性。
在大数据时代，同时出现的就是云原生架构，云原生之前的文章简述过，关键技术就是容器化、微服务、快速交付和Dev&ops，同时随着人工智能的快速发展，产品或多或少都集成AI进行赋能。像精准化营销，个性化推荐，人工智能机器人。【we 需要不断的去拥抱变化】