常州市天宁区建设局网站,一款可做引流的网站源码,网站开发公司会在最后面加上公司,手机笑话网站源码文章目录 #x1f343;前言#x1f334;单体架构#x1f38b;集群和分布式架构#x1f332;微服务架构#x1f38d;微服务带来的挑战⭕总结 #x1f343;前言
本篇文章将从架构的演变过程来简单介绍一下微服务#xff0c;大致分为一下几个部分
单体架构集群和分布式架… 文章目录 前言单体架构集群和分布式架构微服务架构微服务带来的挑战⭕总结 前言
本篇文章将从架构的演变过程来简单介绍一下微服务大致分为一下几个部分
单体架构集群和分布式架构微服务架构
以及微服务架构所带来的挑战。
单体架构
很多创业公司早期或者传统企业会把业务的所有功能实现都打包在⼀个项⽬,这就是单体架构.
业务的所有功能实现都打包在⼀个war包或者Jar包中,这种⽅式就称为单体架构
以电商系统举例电商系统包括⽤⼾管理,商品管理,订单管理,⽀付管理,库存管理,物流管理等等,项⽬早期我们会把这些模块都写在⼀个web项⽬中,然后统⼀部署到⼀个Web服务器中 这种架构开发简单,部署简单,⼀个项⽬就包含了所有的功能,省去了多个项⽬之间的交互和调⽤消耗。直接部署在⼀个服务器即可。
集群和分布式架构
当⽹站的⽤⼾量越来越⼤,需求也会越来越多,流量也会越来越⼤,服务可能就会⾯临以下问题:
后端服务器的压⼒就会越来越⼤,负载越来越⾼,甚⾄出现⽆法访问的情况业务场景逐渐复杂.为了满⾜⽤⼾的需求,单体应⽤也会越来越⼤.各个业务代码之间的耦合度也会越来越⾼.任何⼀个问题,都需要整个项⽬重新构建,发布.⼀个微⼩的问题,可能会导致整个应⽤挂掉
我们从以下两个⽅⾯进⾏优化:
横向:添加服务器,把单台机器变成多台机器的集群.纵向:把⼀个应⽤,按照业务进⾏拆分,拆分为多个项⽬.此架构也称为垂直架构 以单体结构规模的项⽬为单位进⾏垂直划分。也就是将⼀个⼤项⽬拆分成⼀个⼀个单体结构项⽬。项⽬和项⽬之间相对⽐较独⽴,接⼝多为数据同步功能
那什么是集群什么又是分布式呢
集群是将⼀个系统完整的部署到多个服务器上,每个服务器都能提供系统的所有服务,多个服务器通过负载均衡调度完成任务。每个服务器称为集群的节点(node)分布式是将⼀个系统拆分为多个⼦系统多个⼦系统部署在多个服务器上多个服务器上的⼦系统协同合作完成⼀个特定任务。
把他们放在一起讲那么他们肯定是有联系和区别的。
集群和分布式区别和联系如下
从概念上集群是多个计算机做同样的事,分布式是多个计算机做不同的事从功能上集群的每⼀个节点功能是相同的并且可以替代的。分布式也是多个节点组成的系统但是每个节点完成的业务是不同的⼀个节点出现问题这个业务就不可访问了从关系上分布式和集群在实践中很多时候是互相配合使⽤的。⽐如分布式的某⼀个节点,可能由⼀个集群来代替。分布式架构⼤多是建⽴在集群上的。所以实际的分布式架构设计中并不会把分布式和集群单独区分⽽是统称分布式架构
微服务架构
当我们上面所讲的电商平台的业务拆开来时会有⼀些重复的功能开发⽐如订单系统电商平台和⽀付系统都会涉及。 在分布式架构下,当部署的服务越来越多,重复的代码就会越来越多,服务的调⽤关系也会越来越复杂.
我们可以把⼀些通⽤的会被多个上层服务调⽤的共享业务提取成独⽴的基础服务组成⼀个个微⼩的服务。这就是微服务。
从这个⻆度来看,微服务架构是分布式架构的⼀种拓展,这种架构模式下它拆分粒度更⼩,服务更独⽴.可以理解为微服务是⼀种经过良好架构设计的分布式架构⽅案
那么这与分布式架构有什么区别呢
分布式服务拆分只需要拆了就行微服务指⾮常微⼩的服务更细粒度的垂直拆分,通常指不能再拆的服务
分布式架构侧重于压⼒的分散强调的是服务的分散化。微服务侧重于能⼒的分散更强调服务的专业化和精细分⼯。
从实践的⻆度来看微服务架构通常是分布式服务架构反之则未必成⽴。所以选择微服务通常意味着需要解决分布式架构的各种难题。
微服务带来的挑战
随着产品的复杂性和流量的增加,技术架构也在不断的发⽣变化。不论是早期的单体架构还是现在⼴泛使⽤的微服务架构,都是为了更好的服务产品解决问题.
微服务架构带来好处的同时,也⾯临着⼀些挑战,从单体服务转向微服务意味着管理更加复杂。
接下来我们从优势和挑战两个⽅⾯分析⼀下微服务架构
优势
易开发和维护.每个微服务负责的业务⽐较清晰,体量⼩,开发和维护成本降低.容错性⾼.⼀个服务发⽣故障,可以使故障隔离在单个服务中,不影响整体服务故障.扩展性好.每个服务都是独⽴运⾏的,我们可以结合项⽬实际情况进⾏扩展,按需伸缩.技术选型灵活.每个微服务都是单独的团队来运维,可以根据业务特点和团队特点,选择适合的技术栈.
挑战
虽然微服务具备很多的优势,但由于服务数的增加,服务治理也是我们⾯临的巨⼤挑战.服务依赖.随着服务的数量增多,服务之间的关系也会变得更加复杂.⼀个服务的更改,需要考虑对其他服务的影响.运维成本.⼀个业务流程会涉及多个微服务共同完成,有更多的服务需要译,部署,运⾏,甚⾄可能是不同的编程语⾔,不同的运⾏环境,当然也需要集群来处理故障转移等.这对于运维⼈员⽽⾔,挑战是巨⼤的.开发和测试.⼀个业务流程可能涉及多个微服务共同完成,服务调⽤引⼊⽹络延迟,不可靠的⽹络,如何进⾏容错处理等问题.这对开发和测试⽽⾔,难度也会提升.服务监控.在⼀个单体结构中,很容易实现服务的监控.因为所有功能都在⼀个服务中,微服务架构下,不仅需要对整个链路进⾏监控,还需要对每⼀个服务实现监控.负载均衡.微服务架构中的服务实例数量可能⾮常庞⼤因此需要有效的服务发现和负载均衡机制来管理请求流量和保证⾼可⽤性…
选择微服务架构的话,以上这些问题都需要我们解决,我们是⾃⼰研发还是选择市场上⽐较成熟的技术拿来⽤呢?
全球的互联⽹公司都在积极尝试⾃⼰的微服务落地⽅案。在Java领域最引⼈注⽬的就是Spring Cloud了关于Spring cloud这部分后续文章再一一介绍。
⭕总结
关于《【Spring cloud】 认识微服务》就讲解到这儿感谢大家的支持欢迎各位留言交流以及批评指正如果文章对您有帮助或者觉得作者写的还不错可以点一下关注点赞收藏支持一下
