笔记整理:技术架构涵盖内容和演变过程总结



作者:小傅哥
博客:https://bugstack.cn

沉淀、分享、成长,让自己和他人都能有所收获!

一、前言

架构,说的是开发用的框架吗?

对于刚接触编程的新人来说,可能并不能很清楚的知道架构是怎么来的,都包括什么内容。如果非得说什么架构,那么可能就是目前在 IDEA 中打开的工程就是架构。

抛开技术圈内的架构而已,盖房子的图纸算不算架构、做豆腐的步骤算不算架构、结婚的流程算不算架构?归纳得出,所有的这些步骤都在计算成本、耗材、执行和产出,那么架构就可以看做是一个用于完成目标结果的指导蓝图,现在在放到技术架构的层面来看,架构就不只是我们研发人员用到的技术框架,还需要根据场景、规模,设定技术选型、实施标准、部署结构,综合来完成一个项目的交付。

  • 应用场景:你的应用场景是最先决定你采用哪种架构的,这可能会包括:电商、交易、社交、视频、音乐、出行、外卖等等,当然除了互联网中的应用场景,还会有一些基于物联网的应用,例如:PLC 应用、IO 板卡、中继器打码以及你熟悉的小区自提柜。
  • 业务规模:这决定了你的用户范围和体量,如果你是在当下正火的抖音里开发商城,那你的用户体量基数从上线之初就会特别大,但如果你还是一个初创团队小电商,那么每天的QPS维持在 5~10,可能这个阶段你就不需要有能承载多大体量的系统架构。这也类似网络上的笑话,团队初期招聘某大厂大佬,上来就是超级架构的建设,没等系统开发完呢,公司没了!
  • 服务类型:有了场景和规模的设定,接下来要考虑的内容就是整个技术实现层面的内容,服务类型可能是整个团队最初对系统拆分模块和如何支持的考量,有了业务的分层就可以划分出由各个团队来协同支持开发。当然如果是小团队那么这一环节最好缩小,哪怕把所有的功能都开发到一个系统里去,先快速验证市场是主要的。
  • 部署结构:是部署结构决定了开发模式,单体部署、集群部署、分布式部署、云环境等,这些都会决定技术的选型和框架的结构。例如不引用RPC,那么就很难实现分布式部署,如果不使用分库分表和大数据环境,也很难支撑起分布式部署下的数据应用。
  • 开发框架:MVC、DDD,这应该是研发人员最先接触到整个系统架构中的代码开发部分,也就是具体功能的具体实现层,如果是单体应用那么基本一个 MVC 结构就够了,但如果是大体量的分布式部署,那么你的系统开发里可能有的是操作数据库的,有的是专门做业务的,有的是用于支持分布式任务和消费MQ消息的。
  • 技术选型:其实开发框架,无论是 MVC 还是 DDD,都是不影响技术选型的,任何一种语言都可以放在同样的架构框架中进行开发,比如你说 Java、PHP、GO,只不过它们都是在自己语言下有自己的解决方案。

综上,就是我们研发人员在做架构设计时要考虑的核心内容,随着我们技术的不断迭代也会有更多更新的思想,就像20年热起来中台、21年热起来的低代码,都是为了更好的让架构降本增效的实施方案。

但如果想了解和学习架构,最好还是要从它是一颗小树苗时候看起,看看它是如何一点点长大的。在头脑中有了一个这样的架构体系,也能让大家更好的理解和设计你需要的架构。

二、架构演变

1. 单体架构

  • 体量:⭐
  • 技术:tomcat、weblogic、Java、Mysql、MVC
  • 描述:我的博客 bugstack.cn 基本就是这种架构,只不过开发语言不是Java的。这种结构适合体量较小的业务场景,通常都是大佬在互联网初期自研的网站,不过现在这种模型并没有过期,依旧有它的应用场景。

2. 应用与数据库分离

  • 体量:⭐
  • 技术:tomcat、weblogic、Java、DB2、MVC
  • 描述:这一阶段的拆分其实没有太多变体,主要是由于原有的单体架构应用和数据库部署在一台服务器上,导致性能不足。那么最简单高效的拆分就是把应用和数据库分离开了,让它们在各自的服务器上发挥最大性能。

3. 使用缓存抗量

  • 体量:⭐⭐
  • 技术:tomcat、weblogic、Java、Oracle、MVC、Redis
  • 描述:在这个阶段大家发现,我们需要频繁的从数据库中拉取数据,非常耗费性能。也尝试把一部分数据存放在本地内存,但在服务重启后这部分数据就没有了。因此引入了Redis这样的缓存服务,在这个阶段还是非常大的提升了整体服务的性能。

4. 多应用部署和Nginx反向代理

  • 体量:⭐⭐⭐
  • 技术:tomcat、weblogic、Java、Oracle、MVC、Redis、Nginx
  • 描述:当单个服务的承载体量已经到极限了以后,就能想到的就是把服务部署多套,因为这些服务都是做着同样的事,数据库又都是统一一套的,那么通过Nginx的反向代理,就可以把用户的请求分散到不同的服务上去,大大的减轻了服务压力。

5. 数据库读写分离

  • 体量:⭐⭐⭐
  • 技术:tomcat、weblogic、Java、Oracle、MVC、Redis、Nginx
  • 描述:数据库的读写分离设计,更多的是因为某些业务场景需要大量的事务性写入,影响到需要读操作的业务。但读写分离的设计并没有太大程度上提升系统性能,因为很大程度的读操作已经使用 Redis 抗住。不过这样的设计思路却为后续的架构模型提供了新的思路。

6. 应用分组部署

  • 体量:⭐⭐⭐⭐
  • 技术:tomcat、weblogic、Java、Oracle、MVC、Redis、Nginx
  • 描述:所有业务都开发在一个应用上所能承载的用户体量已经到极限了,那么接下来最好架构方式就把不同的业务拆分为不同的应用,这些应用都配有自己的数据库,也分别部署在自己的服务器内。这样一来就大大提升了整体的负载能力。

7. 应用分库设计

  • 体量:⭐⭐⭐⭐
  • 技术:tomcat、weblogic、Java、Oracle、MVC、Redis、Nginx、MyCat
  • 描述:当应用按照不同的业务各自系统拆分以后,接下来的瓶颈就在于已经独立的应用用户体量依旧很大,对应的数据库热连接数持续增高。所以在当前条件下,开始设计应用分库操作,同时后可能也会在这个阶段引入分表操作。这样一来单个应用的负载能力又得到了一大截的提升,但是拆库以后也需要引入分布式事务、数据汇总等其他技术的使用,来解决拆库新增的问题。

8. RPC 分布式部署

  • 体量:⭐⭐⭐⭐⭐
  • 技术:tomcat、weblogic、Java、Oracle、MVC、Redis、Nginx、MyCat、RPC、LVS/F5
  • 描述:在系统不断的再精细化设计以后,其实某些服务并不需要持续的连库操作,它们可能更多的是业务逻辑的包装,同时这些数据库层的操作应用属于底层系统,那么就可以把这样系统用于连库操作,而上层服务通过RPC框架来连接这样的服务。那么,现在就可以通过分布式部署的方式,提升整体的服务性能。

9. 应用细分和网关引入

  • 体量:⭐⭐⭐⭐⭐
  • 技术:tomcat、weblogic、Java、Oracle、MVC、Redis、Nginx、MyCat、RPC、LVS/F5、网关、MQ、分布式任务、Elasticsearch
  • 描述:从上到下的整个架构演变过程,我们不断的拆分应用、单独部署一直到应用细分,都是在不断的提升应用服务的能力,让各自应用体负责独立的事情。这个阶段已经开始体现出微服务的能力了,同时这个阶段也引入了上层的网关统一接入和下层的数据使用能力。

10. 低代码编程和可复用

  • 体量:⭐⭐⭐⭐⭐
  • 技术:tomcat、weblogic、Java、Oracle、MVC、Redis、Nginx、MyCat、RPC、LVS/F5、网关、MQ、分布式任务、Elasticsearch、SDK、低代码、支撑服务
  • 描述:在目前这个阶段服务框架基本已经可以很好的支撑用户体量,所以也开始考虑如何更高效的开发和交付问题。那么也就引入了服务编排、服务治理以及通用的模块、组件和中间件。而这些设计其实压缩来看基本就是以前你开发的一个应用而已,不过把所有非业务逻辑的通用性功能不断的拆分出来了,再通过这些细分的组件和服务能力的编排,提供所需接口,这样一来也就大大的提升了可持续交付集成的效率。

三、架构图下载

有小伙伴反馈看了架构图,也有了点自己的想法,但是动手画的时候就很懵,不知道从哪开始。那么小傅哥把画的架构图原稿分享给大家,可以让感兴趣的小伙伴下载使用。

下载:https://download.csdn.net/download/Yao__Shun__Yu/15567125

四、总结

  • 本章也是小傅哥在整理系列架构内容资料的一个总结,让新人码农对架构有一个从小到大的认识。在总结整理时也结合现在的架构简化了一部分内容,因为只有剥丝抽茧的看懂最主干的内容,大家才好不断的扩展枝叶。
  • 从演变的过程我们可以看到,业务体量会影响部署,部署形态会改变架构,架构会呼应开发方式,最终语言只是当前最合适某种架构的工具,各项技术栈的运用也是为了技术需求而存在。
  • 最后,就是如果你也想让图表达出你的意思,那么可以尝试画一画、总结总结,找到一种能适合你表达出结果的画图结构。

五、系列推荐

本站声明:网站内容来源于网络,如有侵权,请联系我们,我们将及时处理。

  • 分享:
评论
还没有评论
    发表评论 说点什么