草庐IT

【架构师】零基础到精通——架构发展

架构师Cool 2024-01-06 原文

博客昵称:架构师Cool
最喜欢的座右铭:一以贯之的努力,不得懈怠的人生。
作者简介:一名Coder,软件设计师/鸿蒙高级工程师认证,在备战高级架构师/系统分析师,欢迎关注小弟!
博主小留言:哈喽!各位CSDN的uu们,我是你的小弟Cool,希望我的文章可以给您带来一定的帮助
百万笔记知识库, 所有基础的笔记都在这里面啦,点击左边蓝字即可获取!助力每一位未来架构师!
欢迎大家在评论区唠嗑指正,觉得好的话别忘了一键三连哦!😘

架构演进

1、单体应用架构(Monoliths)

互联网早期,一般的网站应用流量较小,只需一个应用,将所有功能代码都部署在一起就可以,这样可以减少开发、部署和维护的成本。比如说一个电商系统,里面会包含很多用户管理,商品管理,订单管理,物流管理等等很多模块,我们会把它们做成一个web项目,然后部署到一台tomcat服务器上。

1-1、优点

  • 项目架构简单,小型项目的话, 开发成本低
  • 项目部署在一个节点上, 维护方便

1-2、缺点

  • 全部功能集成在一个工程中,对于大型项目来讲不易开发和维护
  • 项目模块之间紧密耦合,单点容错率低
  • 无法针对不同模块进行针对性优化和水平扩展

2、垂直应用架构(Vertical)

随着访问量的逐渐增大,单一应用只能依靠增加节点来应对,但是这时候会发现并不是所有的模块都会有比较大的访问量。还是以上面的电商为例子, 用户访问量的增加可能影响的只是用户和订单模块, 但是对消息模块的影响就比较小. 那么此时我们希望只多增加几个订单模块, 而不增加消息模块. 此时单体应用就做不到了, 垂直应用就应运而生了。所谓的垂直应用架构,就是将原来的一个应用拆成互不相干的几个应用,以提升效率。比如我们可以将上面电商的单体应用拆分成:

  • 电商系统(用户管理 商品管理 订单管理)
  • 后台系统(用户管理 订单管理 客户管理)
  • CMS系统(广告管理 营销管理)

这样拆分完毕之后,一旦用户访问量变大,只需要增加电商系统的节点就可以了,而无需增加后台和CMS的节点。

2-1、优点

  • 系统拆分实现了流量分担,解决了并发问题,而且可以针对不同模块进行优化和水扩展
  • 一个系统的问题不会影响到其他系统,提高容错率

2-2、缺点

  • 系统之间相互独立, 无法进行相互调用
  • 系统之间相互独立, 会有重复的开发任务

3、分布式架构(Distributed)

即分布式架构当垂直应用越来越多,重复的业务代码就会越来越多。这时候,我们就思考可不可以将重复的代码抽取出来,做成统一的业务层作为独立的服务,然后由前端控制层调用不同的业务层服务呢?

这就产生了新的分布式系统架构。它将把工程拆分成表现层和服务层两个部分,服务层中包含业务逻辑。表现层只需要处理和页面的交互,业务逻辑都是调用服务层的服务来实现。

3-1、优点

  • 抽取公共的功能为服务层,提高代码复用性

3-2、缺点

  • 系统间耦合度变高,调用关系错综复杂,难以维护

4、面向服务化架构(SOA)

在分布式架构下,当服务越来越多,容量的评估,小服务资源的浪费等问题逐渐显现,此时需增加一个调度中心对集群进行实时管理。此时,用于资源调度和治理中心(SOA Service Oriented Architecture,面向服务的架构)是关键。

4-1、优点

  • 使用注册中心解决了服务间调用关系的自动调节

4-2、缺点

  • 服务间会有依赖关系,一旦某个环节出错会影响较大( 服务雪崩 )
  • 服务关心复杂,运维、测试部署困难

5、微服务架构(Micro Service)

微服务架构在某种程度上是面向服务的架构SOA继续发展的下一步,它更加强调服务的"彻底拆分"。

5-1、优点

  • 更好的开发规模
  • 更快的开发速度
  • 支持迭代开发或现代化增量开发
  • 充分利用现代软件开发生态系统的优势(云、容器、 DevOps、Serverless)
  • 支持水平缩放和细粒度缩放
  • 小体量,较低了开发人员的认知复杂性

5-2、缺点

  • 更高数量级的活动组件(服务、数据库、进程、容器、框架)
  • 复杂性从代码转移到基础设施
  • RPC 调用和网络通信的大量增加
  • 整个系统的安全性管理更具有挑战性
  • 整个系统的设计变得更加困难
  • 引入了分布式系统的复杂性

5-3、微服务定义

  • 一组小的服务

    原来的单块服务都是业务能力大而全的打包在一个单块中,微服务主张把这些单块服务进行拆分,形成一个个小的独立的服务。这里有个最大的特点是“小”,那么纠结要小到什么程度才为之小,很多同学都会纠结这个小的点,因为这个小并没有特别和明确的规定,所以这也就引申出了现在很多DDD领域驱动设计来指引微服务的拆分,但基本上一个微服务能让一个开发人员能够独立的理解,基本上就称为一个微服务,具体有多少行代码并不是很关键。

  • 独立的进程

    微服务是运行在独立的进程当中,例如java程序部署在tomcat,也可以部署在容器docker中,容易本身也是一种进程,所以微服务可以以进程的方式去扩展。

  • 轻量级的通讯

    微服务主张使用轻量级去构建通讯机制,例如http,固定消息格式和减少消息格式,服务之间不耦合,让通讯尽量轻量。

  • 基于业务能力

    微服务是基于业务能力进行构建,例如有用户服务,登陆服务,商品服务,基于这些业务能力去构建这些微服务。

  • 独立部署

    微服务被拆分开后,每个团队独立维护自己的微服务,开发,迭代自己的微服务,是可以独立的去部署,团队之间是不需要特别的去协调,这些对业务开发维护可以做到更加的敏捷,轻量,快速。

  • 无集中式管理

    原来单体服务是需要整个技术团队是需要独立的架构团队去管理,统一架构,统一技术栈,统一存储,微服务就不太一样,微服务主张每个团队根据自己的技术需要,选择自己最熟悉,最高效解决问题的技术栈,甚至选择不同存储方式。

有关【架构师】零基础到精通——架构发展的更多相关文章

  1. ruby - Ruby 和 Ruby on Rails 中的三层架构 - 2

    我是一名决定学习Ruby和RubyonRails的ASP.NETMVC开发人员。我已经有所了解并在RoR上创建了一个网站。在ASP.NETMVC上开发,我一直使用三层架构:数据层、业务层和UI(或表示)层。尝试在RubyonRails应用程序中使用这种方法,我发现没有关于它的信息(或者也许我只是找不到它?)。也许有人可以建议我如何在RubyonRails上创建或使用三层架构?附言我使用ruby​​1.9.3和RubyonRails3.2.3。 最佳答案 我建议在制作RoR应用程序时遵循RubyonRails(RoR)风格。Rails

  2. ruby-on-rails - 具有六边形架构和 DCI 模式的框架和数据库适配器 - 2

    我尝试用Ruby设计一个基于Web的应用程序。我开发了一个简单的核心应用程序,在没有框架和数据库的情况下在六边形架构中实现DCI范例。核心六边形中有小六边形和网络,数据库,日志等适配器。每个六边形都在没有数据库和框架的情况下自行运行。在这种方法中,我如何提供与数据库模型和实体类的关系作为独立于数据库的关系。我想在将来将框架从Rails更改为Sinatra或数据库。事实上,我如何在这个核心Hexagon中实现完全隔离的rails和mongodb的数据库适配器或框架适配器。有什么想法吗? 最佳答案 ROM呢?(Ruby对象映射器)。还有

  3. 企业大数据发展面临问题之存算分离技术思考 - 2

    文章目录概述背景为何要存算分离优势**应用场景**存算分离产品技术流派华为JuiceFSHashDataXSKY概述背景Hadoop一出生就是奔存算一体设计,当时设计思想就是存储不动而计算(code也即是代码程序)动,负责调度Yarn会把计算任务尽量发到要处理数据所在的实例上,这也是与传统集中式存储最大的不同。为何当时Hadoop设计存算一体的耦合?要知道2006年服务器带宽只有100Mb/s~1Gb/s,但是HDD也即是磁盘吞吐量有50MB/s,这样带宽远远不够传输数据,网络瓶颈尤为明显,无奈之举只好把计算任务发到数据所在的位置。众观历史常言道天下分久必合合久必分,随着云计算技术的发展,数据

  4. 设计一个亿级高并发系统架构 - 12306火车票核心场景DDD领域建模 - 2

    “架设一个亿级高并发系统,是多数程序员、架构师的工作目标。许多的技术从业人员甚至有时会降薪去寻找这样的机会。但并不是所有人都有机会主导,甚至参与这样一个系统。今天我们用12306火车票购票这样一个业务场景来做DDD领域建模。”开篇要实现软件设计、软件开发在一个统一的思想、统一的节奏下进行,就应该有一个轻量级的框架对开发过程与代码编写做一定的约束。虽然DDD是一个软件开发的方法,而不是具体的技术或框架,但拥有一个轻量级的框架仍然是必要的,为了开发一个支持DDD的框架,首先需要理解DDD的基本概念和核心的组件。一.什么是领域驱动设计(DDD)首先要知道DDD是一种开发理念,核心是维护一个反应领域概

  5. ruby - 写密集型特征的架构 - 2

    我在当前项目中使用由Oracle数据库和memcached支持的RubyonRails。有一个非常常用的功能,它依赖于单个数据库View作为数据源,并且该数据源内部有其他数据库View和表。这是一个虚拟数据库View,能够从一个地方访问所有内容,而不是物化数据库View。大多数情况下,如果用户正在使用他们希望更新的功能,那么让数据保持最新很重要。从这个View获取数据时,我将安全表内部连接到View(安全表不是View本身的一部分),其中包含一些我们用来在更细粒度级别上控制数据访问的字段。例如,安全表有user_id,prop_1,prop_2列,其中prop_1,prop_2是数据库

  6. 中国民用飞机制造行业市场现状规模及发展战略规划报告2021-2027年 - 2

    中国民用飞机制造行业市场现状规模及发展战略规划报告2021-2027年详情内容请咨询鸿晟信合研究院!【全新修订】:2022年2月【撰写单位】:鸿晟信合研究研究【报告目录】第1章:中国民用飞机制造行业发展综述1.1民用飞机制造行业概述1.1.1民用飞机的概念1.1.2飞机制造的概念1.1.3民用飞机的分类1.2民机制造行业周期特性1.2.1影响行业周期的因素(1)GDP增速分析(2)运量增量分析(3)飞机更替分析(4)航空公司获利水平1.2.2行业现阶段周期分析1.2.3行业现阶段景气分析1.3民机制造信息化分析1.3.1信息化技术应用状况分析(1)MDO技术应用分析(2)供应链协同研发分析(3

  7. ruby - 模块化、基于组件的 Sinatra 应用程序的架构 - 2

    我正在开发一个包含大约10个不同功能组件的Sinatra应用程序。我们希望能够将这些组件混合并匹配到应用程序的单独实例中,完全从config.yaml文件配置,如下所示:components:-route:'/chunky'component_type:FoodListercomponent_settings:food_type:baconmax_items:400-route:'places/paris'component_type:Mappercomponent_settings:latitude:48.85387273165654longitude:2.340087890625-

  8. 【哈士奇赠书活动 - 20期】-〖从程序员到架构师〗 - 2

    文章目录⭐️赠书活动-《从程序员到架构师》⭐️编辑推荐⭐️作者简介⭐️赠书活动→获奖名单⭐️赠书活动-《从程序员到架构师》内容简介:《从程序员到架构师:大数据量、缓存、高并发、微服务、多团队协同等核心场景实战》分为数据持久化层场景实战、缓存层场景实战、基于常见组件的微服务场景实战、微服务进阶场景实战和开发运维场景实战5个部分。基于对十余个架构搭建与改造项目的经验总结,介绍了大数据量、缓存、高并发、微服务、多团队协同等核心场景下的架构设计常见问题及其通用技术方案,包含冷热分离、查询分离、分表分库、秒杀架构、注册发现、熔断、限流、微服务等具体需求下的技术选型、技术原理、技术应用、技术要点等内容,将

  9. Ruby 插件架构 - 2

    我想要一个非常基本的小型基础程序示例,它读入两个插件并注册它们。这两个插件以相同的方式以不冲突的方式挂接到基础程序。就此而言,我对任何编程语言的元编程都很陌生,我不确定从哪里开始。 最佳答案 我已经研究这个问题一段时间了。我尝试了很多不同的方法来做这件事,并征求了很多人的建议。我仍然不确定我所拥有的是否是“正确的方法”,但它运作良好并且很容易做到。在我的例子中,我专门查看配置并引入配置插件,但原理是相同的,即使我的术语特定于cnfiguration。在非常基础的层面上,我有一个配置类,里面什么都没有——它是空的。我还有一个Confi

  10. 汽车车灯的发展趋势 - 2

    汽车车灯的发展和光源的发展也是息息相关的,光源从煤油灯——》乙炔灯——》白炽灯——》卤素灯——》放电灯——》LED灯——》激光灯——》像素化光源,可以说一步步的越来越进步,而车灯的发展也从白炽灯 ——》卤素灯——》氙气灯——》LED灯。比如有一款车使用的Matrix矩阵式全LED大灯头灯就是多LED灯组,由37颗LED灯组成,由日行灯、转向灯、近光灯、远光灯、角灯组成,转弯时可实现增强照明,泊车可增强照明,  可以说汽车照明系统已经从满足一些基本功能转向了个性化智能化及豪华体验上了。最近激光大灯也出来了,原理是激光发光二极管的蓝光灯将会贯穿前大灯单元内有荧光的荧光粉材料,将其转换成一个扩散的白

随机推荐