系统架构初探

前言

时隔多年,我重新开启了博客!也是机会,一直跟随孤尽老师组织的柚子班,学到不少东西!正如昨天一起上课的同事所说,只有上课才能警醒自己知识匮乏,需要学习!学习有四个层次,记忆理解表达融会贯通,那么写博客就是很好的总结以及表达方式!

什么是架构

听到架构,或许我们对这个词感觉很神秘,感觉搞架构的都高大上!希望大家看完这篇文章,能对架构有些了解,或者一起来交流!

架构换个名词可能大家比较容易理解,框架!做什么事情,我一点点的看,最后靠的都是死记硬背,事后都会还给老师,那么如果有结构化的进行处理,就会显得有章节有条理!大家上学快考试的时候都会总结考试点吧,你在本本上画的知识点图那就是架构。一本书,它有目录,有章节有小节,那么目录就是框架,也就是架构!所以,我们看到,架构无处不在!

大家现在经常看到微服务架构这个名词,微服务确实是一种架构!但我这里想强调的是,如果形成了惯性思维,架构是微服务,那就把自己坑了。或许,有些同学已经领会过来,我们说知识点有架构、书有架构,那我们搞开发的,架构也得针对一个问题而来!比如,针对系统业务问题来思考,有业务架构;针对系统安全建设,有稳定性架构,这里不是指单纯的说要解决XSS什么问题,而是有目标有流程有规范;针对系统扩展维护建设,有我们熟悉的系统逻辑架构!

本文呢,我们从写第一行代码开始,都是干活,最直接相关的就是系统逻辑架构,也是最容易理解的。所以呢,本文先讲讲系统逻辑架构,从目前分类来看,一般分为单体架构、SOA、微服务架构!

单体架构

在这里插入图片描述
单体架构,顾名思义,我们单体编写,说的直白点,我们想象成只有一台机器,写Controller层、业务层和DAO层。当访问压力变大,扩容的方法就是增加多台机器,机器是无状态的,前面加上接入层分配服务。

SOA

在这里插入图片描述
SOA比单体架构更进了一步。单体架构在可用性上面遇到了瓶颈,机器越来越多,系统状况无法以技术手段监控,比如很难知道现在是因为订单功能出问题还是物流功能。监控的成本太大,而且容易牵一发动全身。这时候,SOA思想出现了,建设一个ESB企业服务总线,各个功能模块拆分开,可以各自维护各自扩展。

微服务架构

在这里插入图片描述
SOA需要所有服务都放到ESB,维护性较差。微服务提出一种更好的方案,自下而上,从最基础的领域服务出发,每个基础领域服务都是一个小闭环,开发维护扩展都可以更小的粒度进行。

最后

现在的微服务架构已经相当成熟,有SpringCloud套餐,也可以自己搭建用Dubbo等,所以现在启动项目完全可以直接使用微服务架构!但是,用可以用这些框架,服务一开始不建议拆的太细,太细就需要投入细化成本,但是业务发生变化,投入的太多又浪费了!

目前先写这么多,后续计划虚拟一个业务,从头到尾验证总结!也希望大家一起多多交流!

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值