Spring Cloud微服务的概念是什么

本文向您展示了Spring Cloud微服务的概念。内容简洁易懂。它一定会让你的眼睛发光。希望通过这篇文章的详细介绍，你能有所收获。

单体架构

10-1010在软件设计中，我们经典的三层架构被频繁使用。

1.表示层：用于直接与用户交互，通常是页面、UI等。

2.业务逻辑层(service):用于处理业务，如用户从表示层输入消息后，业务逻辑层逻辑处理后的相关操作；

3.数据访问层(dao):用于与数据库交互；

在单个应用程序中，我们将把这三层放在一个项目中，最后通过war包将它们发布到服务服务器的Tomcat web-app中。可以说是一个非常方便的设计理念！

简介

单体应用的优点是：

1、性价比很高，通常只需要一台服务器就可以运行项目；

2.开发速度相对较快，运维相对简单，项目框架相对简单清晰，适合小规模应用开发。

单体应用的缺点是：

1.所有与业务相关的操作都放在一台服务器上。如果项目中某个业务出现bug，如果不急着发现，会导致整个项目瘫痪，最终宕机，这对于一个大型网站来说，无疑是一个致命的问题。

2.当业务变得越来越复杂，单个应用的代码量就会增加，导致最终代码的可读性和可维护性越来越差，最终只能重构；

3.当用户越来越多的时候，单个应用的并发是有限的；

可以看出，在应用初期，单个应用在成本、开发时间、运维等方面都有优势。但是随着业务量和用户的增加，单一应用所暴露出来的弊端也很明显，所以在现在完全互联网的时代，单一应用已经不适应时代的发展了！

00-101010

优劣

微服务最初由Martin Fowler在2014年的一篇文章中提出。简单来说就是把单个程序开发成微服务的项目，每个服务都在自己的流程中运行，通常采用HTTP RESTful API的通信风格，独立部署！

微服务

1.微服务单元按业务划分：

多少服务是“微”是一个很难定义的概念，可以从三个方面来定义：

1.根据代码数量定义

2、根据开发时间的长短来定义。

3.根据业务规模划分。

按业务划分的微服务是主流。每个微服务都是独立部署的，并在流程中独立运行。微服务单元是高度模块化的模块，提供稳定的模块边界，服务与服务之间没有任何耦合.

2.微服务通过HTTP相互通信。

微服务通过简单的HTTP调用，更常见的是RESTful API风格，实现了服务独立于语言和平台。例如，用JAVA编写的微服务可以消费用Python编写的服务。

服务之间的通信也可以通过轻量级的消息总线来实现，比如乌合之众MQ、Kafaka等。服务之间的通信是通过发布-订阅设计模式实现的。

服务之间通信的数据格式一般使用json和xml，它们独立于语言和平台。总的来说，json更加高效和轻量级。另一种是使用Protobuf序列化数据。这种方法比json要轻，但是可读性很差，需要反序列化才能理解，所以Protobuf常用于通信协议和数据存储。

3.微服务的数据库独立性

该服务将有自己独立的数据库，数据库之间没有连接。这样做的好处是，随着业务的不断扩展，数据库相对独立，数据量不会太大，易于维护。

但接下来的问题是如何解决分布式事务问题；(这将在后面介绍)

4.微服务的自动部署

一个大项目中会有很多微服务。如果让人家手动部署，难免会出错。然而，随着技术的发展，docker的容器化技术的出现以及微服务自动部署的出现，微服务的部署变得越来越容易。

5.集中式服务管理

随着服务的增加，服务管理变得越来越麻烦，因此需要集中管理。市场上主流的框架是Spring Cloud提供的Eureka注册中心，用于注册和发现服务。此外，动物园管理员和执政官是优秀的服务集中管理框架。

6.分布式体系结构

分布式系统是集群部署的，通常是多台计算机共同完成一个微服务的部署，而分布式架构是通过HTTP进行通信的，所以我们的微服务可以建立在相隔千里的两台不同的计算机上，对空间没有任何约束。

微服务架构是分布式架构，分布式架构比单一架构更复杂。主要需要确定服务的独立性和准可靠性，以及分布式事务、全局锁、全局Id等。这些都需要分布式系统来考虑。

7.引信机构

为了防止服务中的bug导致系统资源耗尽而导致的雪崩效应，系统应该有一个针对微服务的熔断机制；

fuse机制是指：当微服务出现bug时，在请求失败次数达到一定阈值后，微服务会通过fuse断开与服务主体的连接，并快速返回要显示的错误消息，然后在一段时间后重新连接测试，从而重复一个机制来保护整个系统的安全运行。

Spring Cloud中提供了Hystrix，实现了服务的融合。

什么是微服务

微服务的优势：

/>1、服务进行拆分，每个服务只是负责小小的一块内容，这让复杂问题简单化，开发、维护单个服务较为简单；
2、微服务的系统是分布式的系统，服务与服务之间没有任何耦合，随着业务的增加，我们可以根据业务再拆分服务，这让微服务系统具备很强大横向扩展能力；
3、微服务之间完全通过HTTP协议来进行通信，单个微服务内部高度耦合，服务与服务之间完全独立；
4、重写单个微服务的业务代码变得较为简单；
5、微服务在CAP理论中采用的是AP架构，具有高可用（Availability）和分区容错（Partition tolerance）的特点，高可用体现在系统7*24小时不断的服务，它要求系统具有大量的服务器集群配置，分区容错性也让系统更加的健壮。

微服务的劣势：
1、微服务的复杂度比单体服务更为复杂，更难拆分，这让我们的服务的架构设计上应该设计出一个很棒的架构！
2、分布式的事务处理，如何处理分布式事务是一个业界所一直存在的问题，一般的处理方式是分为两阶段的提交:

第一个阶段：服务通过发起一个分布式事务，交给事务协调器TC进行处理，事务调节器TC通过向所有参与该事物的服务节点发送处理事务的准备操作，所有的参与节点执行准备操作，将Undo和Redo信息写进日志中，并且向事务管理器返回准备操作是否成功；
第二阶段：事务协调器TC在一定的时间阈值收集所有节点的准备操作是否成功，如果都成功，则通知所有的节点执行提交操作，如果有一个失败了，则执行回滚操作！

微服务的设计原则

1、如果在LAMP单体架构够用的情况下，就该使用LAMP，因为它开发速度快，性价比高，但是随着业务的发展，用户的激增，可以考虑把数据库读写分离、加缓存、加复杂均衡服务、将应用集群化部署等等，如果还不够解决效率，那就可以考虑使用分布式系统，例如微服务的系统架构。
2、微服务在设计的时候一定要考虑到三大难题，服务故障的传播性、服务的划分、分布式事务的处理。总之，微服务的设计是渐进的，并且是随着业务发展而发展的！

上述内容就是Spring Cloud微服务的概念是什么，你们学到知识或技能了吗？如果还想学到更多技能或者丰富自己的知识储备，欢迎关注行业资讯频道。