分布式架构和微服务架构？Springcloud已经没人用了吗

大家好，关于分布式架构和微服务架构很多朋友都还不太明白，今天小编就来为大家分享关于Springcloud已经没人用了吗的知识，希望对各位有所帮助！

ee架构软件有哪些

1、传统三层架构(allinone项目)

传统三层架构大致可以分为表现层，业务层和持久层（数据访问层）。其中表现层负责接受请求和转发请求。业务层负责处理请求（注：事务管理，日志记录等AOP类型的操作均封装在这一层）。持久层主要负责数据库与实体之间的操作。

struts典型的mvc三层架构：模型层，视图层，控制层。

SpringMVC中的MVC指的是什么：当一个请求到达服务器时，由中央控制器DispatcherServlet（控制层）查找要访问的controller，然后controller->调用service->调用dao，之后将获取的数据返回到jsp页面（视图层）。

即：严格来说在SpringMVC中控制器是DispacterServlet,模型层是controller（即该模型层又可以看成一个MVC架构）,视图层是jsp页面。

另外，利用框架可以简化各层的开发：表现层使用SpringMVC或者struts2,持久层使用Mybatis或Hibernate，使用spring管理表现层，业务层和持久层三层之间的关系

2、集群架构(属于水平拓展)

由于传统的三层架构中存在许多问题，比如业务层中的不同模块占用系统资源相差太大，导致占用系统资源，可以使用集群解决问题。（相当于备份多个文件，多台服务器反问的是同一个项目资源，集群架构的目的也是为了系统资源的高可用性。）

在集群架构中存在一个重要的角色就是反向代理服务器，他的任务是实现负载均衡，接收用户请求，转发到目标服务器，其中反向代理服务器可以使用nginx实现（简单来说也就是一个实现负载均衡的算法）。

3、分布式架构（垂直拆分）

分布式架构特点：多个模块完成一个功能，每个模块又可以搭建集群，从而实现高可用。

4、微服务架构（垂直划分）

根据产品的业务功能模块划分服务的种类，客户端可以通过基于HTTP或者RPC的方式调用微服务，目的是为了降低所产生的性能开销。同时每个模块仍然可以搭建集群，从而实现高可用。

4.1SOA架构

是当服务过多时，服务之间调用关系复杂混乱，不利于维护。

使用dubbo。使用rpc协议进行远程调用，直接使用socket通信。传输效率高，并且可以统计系统之间的调用关系，调用次数。（由于dubbo阿里公司已经停止更新，建议使用springcloud）。

4.2Dobbo

如果服务与服务之间存在调用，dobbo可以通过名字去鉴别因为编码时每个模块之间都有调用关系，且该关系也被dobbo掌握。

4.3SpringCloud

SpringCloud是一个基于SpringBoot实现的服务治理工具包；SpringBoot专注于快速、方便集成的单个微服务个体；SpringCloud关注全局的服务治理框架。

软件产品架构中什么是单体架构、SOA架构、微服务架构

软件产品架构是不断迭代演化的，从单体服务架构发展到现在的服务化、微服务的架构。

单体架构就是所有的业务模块都是耦合在一个项目中，开发、部署都在一起；如果其中一个模块需要上线升级，那么所有模块都要一起启停；

在早期，单体架构的项目团队成员需要是“全栈”，因为前端、后端、数据库都是一波人负责，后来开始进行了逻辑分层，团队也分成了前端UI团队、后端和DBA团队，每个团队都有自己负责的职责。

然而随着业务逻辑越来越复杂，模块和模块之间的耦合度越来越高；另外随着用户和数据量的增多，单体架构也不再能够支撑高并发和大数据。

为了解决上面的问题，SOA出现了。

SOA代表了面向服务的架构，SOA将应用程序的业务模块进行拆分，形成独立的应用系统，系统和系统之间通过明确的接口串联起来；

每个系统内部结构和逻辑发生改变，并不影响对外提供的服务，只要保持接口不变，服务内部对外是透明的；

SOA架构中，服务定义标注的接口，可以提供给多个调用方使用，增加了服务的重用性。

SOA架构时代有两个很重要技术实现方式：WebService和ESB：前者提供了标准的数据传输协议，后者实现了服务编排和协议转换。

但是随着用户和数据量的进一步增长，SOA也暴露出来一些缺点，比如SOAP协议、XML较重；服务管理不完善；ESB本身就比较重，而且它本身算是一个单点，在软件架构中，单点意味着风险。

在微服务的架构中，各个微服务可以独立开发，独立部署；微服务之间通常使用Restful风格的API通信，传输格式也通常选择JSON；

微服务是SOA架构的延续，它们和单体应用相比，大大提高了系统的负载能力，解决了应用高并发的需求；

服务和服务之间的耦合度也被降低，并且项目团队可以被拆分成多个小团队，每个微服务都可以进行敏捷开发部署；

每个团队的技术栈也可以不相同，只要遵守接口协议即可。

至于微服务和SOA架构的区别，我是这样理解的：SOA架构和微服务架构都属于分布式架构，分布式的思想就是把不同的业务模块，部署在不同的服务器上，以应对高并发的问题；SOA是一种分布式架构，把业务系统分成多个子系统，提供不同的服务，再通过服务组合、编排实现业务流程；微服务是SOA的升华，如果非要说点儿不同的，那么微服务更加强调服务的细分和专业，去ESB总线、去中心化，部署粒度更细，服务扩展更灵活。

当然SOA、微服务的出现，在解决一些问题的时候，也带来了另外一部分的问题，比如增加了网络开销、服务依赖性、增加了测试运维难度、数据一致性问题等等。

微服务架构和分布式架构的区别

微服务架构是指将一个大型的应用程序拆分成多个小型独立的服务，每个服务都有自己的功能和特点，并可以独立部署和运行，彼此之间通过API进行通信和交互。微服务架构的优点是系统解耦、服务可维护，可伸缩性好等。而分布式架构则是指将一个应用程序分布式地部署在多个物理节点上，每个节点拥有自己的计算资源和存储资源，各节点之间通过网络传输数据和协同工作。分布式架构的优点是可以充分利用多节点的资源，提高系统的容错性和可靠性，但开发和维护难度也相应增加。简单说，微服务架构更注重服务的拆分和解耦，而分布式架构更注重整个系统的资源利用和协同工作。

微服务和分布式的区别

1、含义不同

微服务架构：微服务架构风格是一种将一个单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制(通常用HTTP资源API)。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理，服务可用不同的语言开发，使用不同的数据存储技术。

分布式和微服务区别

1、含义不同

微服务架构：微服务架构风格是一种将一个单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制(通常用HTTP资源API)。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理，服务可用不同的语言开发，使用不同的数据存储技术。

分布式架构：分布式系统是若干独立计算机的集合，这些计算机对用户来说就像单个相关系统，即整个系统是由不同的计算机组成，而用户是无感知的，就像访问一台计算机一样。这里强调的是系统由不同物理上分离的计算机（服务器）组成。

2、概念层面不同

微服务架构：微服务是设计层面的东西，一般考虑如何将系统从逻辑上进行拆分，也就是垂直拆分。微服务可以是分布式的，即可以将不同服务部署在不同计算机上，当然如果量小也可以部署在单机上。

分布式架构：分布式是部署层面的东西，即强调物理层面的组成，即系统的各子系统部署在不同计算机上。

3、解决问题不同

微服务架构：微服务解决的是系统复杂度问题：一般来说是业务问题，即在一个系统中承担职责太多了，需要打散，便于理解和维护，进而提升系统的开发效率和运行效率，微服务一般来说是针对应用层面的。微服务如果用在其它系统，如存储系统感觉怪怪的，就像说Mysql集群是微服务的，总觉得哪里不舒服。

分布式架构：分布式解决的是系统性能问题：即解决系统部署上单点的问题，尽量让组成系统的子系统分散在不同的机器上进而提高系统的吞吐能力。

4、部署方式不同

微服务架构：微服务的应用可以部署在是同一个服务器，不一定是分散在多个服务器上。微服务架构是一项在云中部署应用和服务的新技术。微服务架构是一种架构模式，它将一个复杂的大型应用程序划分成多个微服务，这些小型服务都在各自独立的进程中运行。

分布式架构：分布式是将一个大的系统划分为多个业务模块,这些业务模块会分别部署到不同的机器上，通过接口进行数据交互。

5、耦合度不同

微服务相比分布式服务来说，它的粒度更小，服务之间耦合度更低，由于每个微服务都由独立的小团队负责，因此它敏捷性更高，分布式服务最后都会向微服务架构演化，这是一种趋势，不过服务微服务化后带来的挑战也是显而易见的，例如服务粒度小，数量大，后期运维将会很难。

关于分布式架构和微服务架构到此分享完毕，希望能帮助到您。