加入收藏 | 设为首页 | 会员中心 | 我要投稿 威海站长网 (https://www.0631zz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 站长资讯 > 动态 > 正文

存储技术将迎来一场革命

发布时间:2021-02-11 12:41:17 所属栏目:动态 来源:互联网
导读:针对单体应用,非功能性需求的做法: 性能需求:使用缓存改善性能 并发需求:使用集群改善并发 读写分离:数据库地读写分离 使用反向代理和cdn加速 使用分布式文件和分布式数据库 单体架构的应用比较容易部署、测试, 在项目的初期,单体应用可以很好地运行

针对单体应用,非功能性需求的做法:

  • 性能需求:使用缓存改善性能
  • 并发需求:使用集群改善并发
  • 读写分离:数据库地读写分离
  • 使用反向代理和cdn加速
  • 使用分布式文件和分布式数据库

单体架构的应用比较容易部署、测试, 在项目的初期,单体应用可以很好地运行。然而,随着需求的不断增加, 越来越多的人加入开发团队,代码库也在飞速地膨胀。慢慢地,单体应用变得越来越臃肿,可维护性、灵活性逐渐降低,维护成本越来越高。下面是单体架构应用的一些缺点:

  • 复杂性高:以一个百万行级别的单体应用为例,整个项目包含的模块非常多、模块的边界模糊、 依赖关系不清晰、 代码质量参差不齐、 混乱地堆砌在一起。可想而知整个项目非常复杂。每次修改代码都心惊胆战, 甚至添加一个简单的功能, 或者修改一个Bug都会带来隐含的缺陷。
  • 技术债务:随着时间推移、需求变更和人员更迭,会逐渐形成应用程序的技术债务, 并且越积 越多。“ 不坏不修”, 这在软件开发中非常常见, 在单体应用中这种思想更甚。已使用的系统设计或代码难以被修改,因为应用程序中的其他模块可能会以意料之外的方式使用它。
  • 部署频率低:随着代码的增多,构建和部署的时间也会增加。而在单体应用中, 每次功能的变更或缺陷的修复都会导致需要重新部署整个应用。全量部署的方式耗时长、 影响范围大、 风险高, 这使得单体应用项目上线部署的频率较低。而部署频率低又导致两次发布之间会有大量的功能变更和缺陷修复,出错率比较高。
  • 可靠性差:某个应用Bug,例如死循环、内存溢出等, 可能会导致整个应用的崩溃。
  • 扩展能力受限:单体应用只能作为一个整体进行扩展,无法根据业务模块的需要进行伸缩。例如,应用中有的模块是计算密集型的,它需要强劲的CPU;有的模块则是IO密集型的,需要更大的内存。由于这些模块部署在一起,不得不在硬件的选择上做出妥协。
  • 阻碍技术创新:单体应用往往使用统一的技术平台或方案解决所有的问题, 团队中的每个成员 都必须使用相同的开发语言和框架,要想引入新框架或新技术平台会非常困难。

架构演进路程:单体应用→分布式应用服务化→微服务

4.1. 单体应用

企业一开始业务比较简单,只应用某个简单场景,应用服务支持数据增删改查和简单的逻辑即可,单体应用可以满足要求。

典型的三级架构,前端(Web/手机端)+中间业务逻辑层+数据库层。这是一种典型的Java Spring MVC或者Python Django框架的应用。其架构图如下所示:
 

  • 系统级:即整个系统内各部分的关系以及如何治理:分层
  • 应用级:即单个应用的整体架构,及其与系统内单个应用的关系等。
  • 模块级:即应用内部的模块架构,如代码的模块化、数据和状态的管理等。
  • 代码级:即从代码级别保障架构实施。

战略设计与战术设计

基于架构金字塔,我们有了系统架构的战略设计与战术设计的完美结合:

  • 战略设计:业务架构用于指导架构师如何进行系统架构设计。
  • 战术设计:应用架构要根据业务架构来设计。
  • 战术实施:应用架构确定以后,就是技术选型。
 

(编辑:威海站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    热点阅读