单体架构,集群架构,SOA架构,分布式微服务架构

打印 上一主题 下一主题

主题 991|帖子 991|积分 2973

演变过程

一. 单体应用架构
为什么要用单体架构?
   单体架构的特点就是:所有的业务功能都在一个项目里面 逻辑也简单 还不贵 得当于小型项目。
  在以前盘算机才刚刚普及的时间,那个时间根本上都是单体项目架构,由于简单还实用,那个年代能上网的才有多少人无非都是家里有钱的或者是体制内的上个班以前是喝杯茶看看报纸现在是喝杯茶看看电脑,以是能够真正上的了网的人很少,那么用单体应用架构完全够了
那么单体架构又是什么呢?
   一个范例的单体应用就是将所有的业务处置惩罚功能都放在一个工程中,最终颠末编译、打包,摆设在一台服务器上。
  普通点讲就是你整个项目都运行在一个web应用服务器上,然后这整个web应用服务器又运行在一个服务器上

但是随着时代的发展盘算机的普及 越来越多的人有了可以上网的权利 这个时间 单体架构的弊端出来了
举个栗子:
   某企鹅 在它刚创建的那时间根本上是没什么人用的大概顶多500应该,后面随着越来越多人有电脑,在加上我们某马哥坚韧不拔的陪用户谈天
某企鹅的使用用户也越来越多了起来,但也随之带来的就是单体架构的弊端
  用户越来越多,访问量越来越大,也就是CPU运行内存打满,服务器响应痴钝,带宽被用尽,一开始我们是采取的更新服务器硬件设置 和提升带宽
   带宽是什么?
宽带是一种相对的描述方式,频带的范围愈大,也就是带宽愈高时,能够发送的数据也相对增加。譬如说在无线电通信上,频率范围比较窄的带宽只能发送摩尔斯电码,发送高质量的音乐就必要较大的带宽。
好比说你这个服务器最大能接受的带宽是多少 然后如果访问量大于你这个临界点就会404 或者 ○加载中
  这个时间我们是怎么解决的呢?
垂直扩容 更新服务器设置和提升带宽,
好解决完了老板非常开心给嘉奖你5000奖金,然后你开开心心的拿着奖金开始摸鱼了
但这只是能缓解我们的燃眉之急…
由于当时的服务器硬件设置也就那样,就算你把服务器升到顶配也还是会有一个天花板 万一你的访问量到了天花板呢?凌驾了服务器所能承受的访问量呢 如果1000万人访问会怎么样怎么办…
程度扩容(集群架构)
分流,将许多服务器集中起来一起举行同一种服务,在客户端看来就像是只有一个服务器,主要是分散压力。
   相称于同一个工程代码拷贝多份摆设到多台服务器,每台服务器单独独立摆设运行。
  他是怎么解决我们的前面两个问题的呢?
设置多台服务器多台服务器都拥有自己独立的ip地址,那这肯定很麻烦如果是按照记ip地址才能访问的话你肯定要记许多0.0.0.0 — 255.255.255.255
以是我们提供了一个东西叫 ”域名“ ,域名代理了所有服务器的IP地址,提供一个同一的访问地址给外界举行访问
但这个时间又有了一个问题所有的用户都访问我这一个域名 那我怎么举行分配呢?

负载均衡
   负载均衡(Load
Balance)是分布式体系架构设计中必须思量的因素之一,它通常是指,将哀求/数据【匀称】分摊到多个操作单位上实行,负载均衡的关键在于【匀称】。
  负载均衡又分为硬件负载均衡和软件负载均衡
硬件负载均衡是靠负载均衡器来实现的,他的作用是在服务器之前加粗样式,在外边有哀求对服务器举行访问的时间是先通过硬负载均衡来确定好分配到集群服务器中哪个服务器上
   负载均衡设备:将用户访问的哀求,根据负载均衡算法,分发到集群中的一台处置惩罚服务器。(一种把网络哀求分散到一个服务器集群中的可用服务器上去的设备)

  软件负载均衡器有:Lvs ,Nginx,Haproxy
   指在服务器的操作体系上,安装软件,来实现负载均衡,如Nginx负载均衡。它的优点是基于特定环境、设置简单、使用机动、本钱低廉,可以满意大部门的负载均衡需求。
  软件负载均衡是靠软件来的,他是作用在服务之前的从硬负载均衡之后进入到具体的服务器中 在面对集群服务中我们通过软负载均衡来确定好哀求分发到哪个具体的服务上

好解决完了老板非常开心给嘉奖你1万奖金,然后你开开心心的拿着奖金又开始摸鱼了
但这个时间又有一个问题出来了如果我有一个亿的用户呢?
难不成还用这头脑去解决问题?
那如果我一个亿的用户,市面上好的服务器我们来大概一下一台好的服务器咱们就算他200万好吧,一台好的可以解决五百万的用户量,算算多少钱
这应该有几个小目标了吧,这你 这钱都进老板兜里了难不成还让他掏出来这他肯定是不乐意的呐对吧。
老板说 这你要搞欠好你就可以走人了,怎么办咱也没办法为了不被卷铺盖咱只能想办法呗
SOA架构

什么是SOA架构这东西每个人的明白都不一样但是每个人的明白都差不多比较抽象
我的明白来说就是
把一个项目按照功能来拆分成对多个独立的项目,
在根据使用频仍的业务服务来对其举行集群架构
这里支付用户访问量比其他的多的多以是我们就可以使用集群架构

但是你把每个实际业务都区分成独立的项目时间,但各个业务总会有那么一些交互的地域 好比说你 用户要看他这个用户的订单是不是用户管理就和订单管理交互起来了。
这些交互的地域相互调用非常凌乱,这个时间前辈开发了EJB EJB里面实践了业务总线这个概念,这个经验黑白常名贵的他资助我们把这些交互的地域同一起来了,在EJB1版本到2版本的时间也可以算是不成功的但也又是成功的,不成功是由于性能欠好业务总线太过笨重,好是他提供了名贵的实际经验。
好了这个时间你解决了集群架构的缺点 老板又又给你嘉奖了你又又可以开开心心摸鱼了
过了几天由于业务总线太过于笨重有时间服从和不弄SOA差不多 老板又来找你了
你又开始了你那苦逼的生存…
分布式微服务架构

为了解决前面提到的业务总线过于笨重的问题,分布式微服务架构去掉了业务总线去掉了中心化。
   分布式微服务架构也是当前行内开发软件的头脑,指针对现阶段互联网配景下所必要的架构
  

而且相比于前面而言
   微服务是真正的分布式的、去中心化的。把所有的“思索”逻辑包罗路由、消息解析等放在服务内部,去掉一个大一统的 ESB,服务间轻通信,是比SOA更彻底的拆分。
分布式微服务架构强调的重点是业务体系必要彻底的组件化和服务化,原有的单个业务体系会拆分为多个可以独立开发,设计,运行和运维数据的小应用,这些小应用之间通过服务完成交互和集成。

  可以分为六个组件

  • 业务接入层:
   (哀求的分发):服务间路由和调理网关
  

  • 业务服务层:
   各个功能模块服务 好比:支付,用户,订单
  

  • 服务注册中心:
   提供服务的注册和发现以及编排和管理的功能,维护一个可用分的服务列表,当你在服务层上线了一个服务后必须要先在服务注册中心注册一下 和我们签到是一个意思 至于为什么后面会讲 我在这里就不多说了
  

  • RPC:
   (远程工程的调用):每个独立的服务项目之间的调用
  

  • 设置中心:
   将设置的参数同一管理的场所
  

  • 消息中心介:
   记任命户发起的哀求,各个服务可以通过定时任务或者自由访问消息中心介中的哀求。
  服务器雪崩:
服务器雪崩是一个很严峻的问题,是怎么来的呢?
由于你支付管理的这个服务器,天灾人祸了 总而言之就是挂掉了没了访问不了,怎么办你这个支付管挂掉了,那么必要哀求支付管理来举行数据交互的时间就哀求不到,如果是订单管理购买个东西肯定有订单 对吧肯定要支付但是你支付这个时间挂掉了怎么办?
哀求肯定是哀求不到了,就和几个月之前的b站一样的效果
而然你这个时间尚有大概革新一下 没有雪中送炭还来了一波补刀 你每革新一次就多了一个哀求在加上不大概就你一个访问不到而是所有人都访问不到那么哀求就会越来越多越来越多 到最后订单管理也撑不住了哀求堆积太多了 凌驾了他所能接受的范围 以是他也挂掉了,然后蝴蝶效应他后面的噼里啪啦也全部挂掉了 爽不爽起不腾飞
那么有问题肯定就有解决的办法,俗话说得好只要头脑不滑坡,方法总比困难多 那么到底怎么解决呢?
三大剑客


  • 熔断
   当他发现了某个服务器挂掉的时间就把他的电路断开,不要让他可以继续访问,也不让正常的流程去访问这个挂掉的服务
  

  • 降级
   找一个替代品 可以是支付管理的备份,也可以是其他正常的服务
  

  • 限流
   字面意思 主要是限制访问数量 辅助前面两个 来给服务器雪崩提供解决时间
  分布式微服务框架


CAP理论是什么?为什么想实现可维护列表必要CAP

而也由于分布式微服务架构 是一个真正的分布式架构项目里的功能模块都是独立开来的包罗数据也是独立的,这就会造成什么效果数据差别步,如果我
用户管理修改了年龄但由于我其他的功能模块是独立的数据以是就差别步这就是一个很严峻的问题那么…
咱们就要用到CAP理论了


  • C 数据一致性:
   分为强数据一致性和最终数据一致性,强数据一致性就是当你在某个服务中修改了数据 那么其他服务就必须将数据同步(数据同步时会造成短暂的不可访问状态),最终一致性 字面意思 就是最终提交的数据我要他是数据同步
不管你前面改了啥 反正我最后提交的时间要数据同步提交
  

  • A 可用性
   提供业务访问的可用时间,就是你服务是不是可用不停开着可用不停访问
一般都是999 99999 如许子 一个星期停那么一两个小时或者一个月停那么一两个小时 可以率99%
  

  • P 分区容错率(必须满意)
   会容忍某个服务不可用 但是不影响整体服务器的运行
  可以看出来 可用性和数据一致性 是互斥的 由于你想要数据一致性就必须要停一会服务 让他数据同步 如许就会降低可用性 以是我们一般都是在这两个选择一个 然后在选上一个必选的分区容错率
对于新手而已 Spring Cloud 他的服务注册中心是用的Eureka 而Eureka 所选择的是AP 也就是先可用性和分区容错率
我只是把我知道的总结出来当做条记防止以后不记得了可以看看以是接待各位大哥辅导小弟那里写的欠好
有时间会持续更新…


免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

x
回复

使用道具 举报

0 个回复

倒序浏览

快速回复

您需要登录后才可以回帖 登录 or 立即注册

本版积分规则

卖不甜枣

金牌会员
这个人很懒什么都没写!
快速回复 返回顶部 返回列表