本文介绍了系统架构从单体应用到微服务的演变，重点探讨了微服务架构的优缺点、常见问题和解决方案。Spring Cloud作为微服务治理方案，其中Spring Cloud Alibaba提供了服务注册、发现、流量控制等组件，成为微服务开发的重要工具。
目录
3、SpringBoot、SpringCloud、SpringCloudAlibaba版本对应关系
一、系统架构演变
随着互联网的发展，网站应用的规模也在不断的扩大，进而导致系统架构也在不断的进行变化。 从互联网早起到现在，系统架构大体经历了下面几个过程: 单体应用架构--->垂直应用架构--->分布 式架构--->SOA架构--->微服务架构，当然还有悄然兴起的Service Mesh(服务网格化)。 接下来我们就来了解一下每种系统架构是什么样子的， 以及各有什么优缺点。
（一）单体应用架构
互联网早期，一般的网站应用流量较小，只需一个应用，将所有功能代码都部署在一起就可以，这 样可以减少开发、部署和维护的成本。
比如说一个电商系统，里面会包含很多用户管理，商品管理，订单管理，物流管理等等很多模块， 我们会把它们做成一个web项目，然后部署到一台tomcat服务器上。
优点： 项目架构简单，小型项目的话， 开发成本低 项目部署在一个节点上， 维护方便
缺点： 全部功能集成在一个工程中，
对于大型项目来讲不易开发和维护；
项目模块之间紧密耦合，单点容错率低，单节点数据会丢失；
无法针对不同模块进行针对性优化和水平扩展；
（二）垂直应用架构
随着访问量的逐渐增大，单一应用只能依靠增加节点（即集群）来应对，但是这时候会发现并不是所有的模块 都会有比较大的访问量. 还是以上面的电商为例子， 用户访问量的增加可能影响的只是用户和订单模块， 但是对消息模块 的影响就比较小. 那么此时我们希望只多增加几个订单模块， 而不增加消息模块. 此时单体应用就做不到了，垂直应用就应运而生了。
- 用户量越来越大，网站的访问量不断增大，导致后端服务器的负载越来越高。
- 用户量大了，产品需要满足不同用户的需求来留住用户，使得业务场景越来越多并且越来越复杂。
- 当服务器的负载越来越高的时候，如果不进行任何处理，用户在网站上操作的响应会越来越慢，甚至出现无法访问的情况，对于非常注重用户体验的互联网产品来说，这是无法容忍的。
业务场景越多越复杂，意味着war包中的代码量会持续上升，并且各个业务代码之间的耦合度也会越来越高，后期的代码维护和版本发布涉及的测试和上线，也会很困难。举个最简单的例子，当你需要在库存模块里面添加一个方法时，带来的影响是需要把整个商城重新测试和部署，而当一个war包有几GB的大小时，部署的过程也是相当痛苦的。
因此，我们可以从两个方面进行优化:
- 通过横向增加服务器，把单台机器变成多台机器的集群。
- 按照业务的垂直领域进行拆分，减少业务的耦合度，以及降低单个war包带来的伸缩性困难问题。
所谓的垂直应用架构，就是将原来的一个应用拆成互不相干的几个应用，以提升效率。如图所示，我们把商城系统按照业务维度进行了垂直拆分:用户子系统，库存子系统，商品子系统，每个子系统由不同的业务团队负责维护并且独立部署。同时，我们针对Tomcat服务器进行了集群部署，也就是把多台Tomcat服务器通过网络进行连接组合，形成一个整体对外提供服务。这样做的好处是能够在改变应用本身的前提下，通过增加服务器来进行水平扩容从而提升整个系统的吞吐量。
需要注意的是，图1-2中针对数据库进行了垂直分库，主要是考虑到Tomcat服务器能够承载的流量大了之后，如果流量都传导到数据库上，会给数据库造成比较大的压力。 这样拆分完毕之后，一旦用户访问量变大，只需要增加用户系统的节点就可以了，而无需增加其他系统节点。
优点： 系统拆分实现了流量分担，解决了并发问题，而且可以针对不同模块进行优化和水平扩展 一个系统的问题不会影响到其他系统，提高容错率。
缺点： 系统之间相互独立， 无法进行相互调用 系统之间相互独立， 会有重复的开发任务。
（三）分布式架构
当垂直应用越来越多，重复的业务代码就会越来越多。这时候，我们就思考可不可以将重复的代码 抽取出来，做成统一的业务层作为独立的服务，然后由前端控制层调用不同的业务层服务呢？ 这就产生了新的分布式系统架构。它将把工程拆分成表现层和服务层两个部分，服务层中包含业务 逻辑。表现层只需要处理和页面的交互，业务逻辑都是调用服务层的服务来实现。
优点： 抽取公共的功能为服务层，提高代码复用性
缺点： 系统间耦合度变高，调用关系错综复杂，难以维护
（四）SOA架构（面向服务）
在分布式架构下，当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加 一个调度中心对集群进行实时管理。此时，用于资源调度和治理中心(SOA Service Oriented Architecture，面向服务的架构)是关键
如图所示，提取出了用户服务、库存服务、商品服务等多个共享服务。在SOA中，会采用ESB(企业服务总线)来作为系统和服务之间的通信桥梁，ESB本身还提供服务地址的管理、不同系统之间的协议转化和数据格式转化等。调用端不需要关心目标服务的位置，从而使得服务之间的交互是动态的，这样做的好处是实现了服务的调用者和服务的提供者之间的高度解耦。
主要解决的问题：信息孤岛
优点: 使用注册中心解决了服务间调用关系的自动调节
缺点:
- 服务间会有依赖关系，一旦某个环节出错会影响较大( 服务雪崩 )
- 服务关心复杂，运维、测试部署困难
（五）微服务架构
微服务架构在某种程度上是面向服务的架构SOA继续发展的下一步，它更加强调服务的"彻底拆分"。
业务系统实施服务化（SOA）改造之后，原本共享的业务被拆分形成可复用的服务，可以在最大程度上避免共享业务的重复建设、资源连接瓶颈等问题。那么被拆分出来的服务是否也需要以业务功能为维度来进行拆分和独立部署，以降低业务的耦合及提升容错性呢?
微服务就是这样一种解决方案，从名字上来看，面向服务(SOA)和微服务本质上都是服务化思想的一种体现。如果SOA是面向服务开发思想的雏形，那么微服务就是针对可重用业务服务的更进一步优化，我们可以把SOA看成微服务的超集，也就是多个微服务可以组成一个SOA服务。伴随着服务粒度的细化，会导致原本10个服务可能拆分成了100个微服务，一旦服
扫一扫
6685
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
