什么是微服务架构

什么是微服务架构

你考虑过吗？什么是微服务，为什么越来越多的企业，为了使自己构建的应用满足客户的期望，而和微服务架构进行整合呢？

微服务，又叫微服务架构，是一种软件架构方式。它将应用构建成一系列按业务领域划分模块的、小的自治服务。

在微服务架构中，每个服务都是自我包含的，并且实现了单一的业务功能。

简单来说，就是将一个系统按业务划分成多个子系统，每个子系统都是完整的，可独立运行的，子系统间的交互可通过HTTP协议进行通信（也可以采用消息队列来通信，如RoocketMQ，Kafaka等）。

所以，不同子系统可以使用不同的编程语言实现，使用不同的存储技术。但是，因为子系统服务数量越多，管理起来越复杂，因此需要采用集中化管理，例如Eureka，Zookeeper等都是比较常见的服务集中化管理框架；同时，使用自动化部署（如Jenkins）减少人为控制，降低出错概率，提高效率。

微服务架构区别于传统的单体软件架构，是一种为了适应当前互联网后台服务的「三高需求：高并发、高性能、高可用」而产生的的软件架构。

一.单体应用架构

与微服务相对的另一个概念是传统的单体式应用程序( Monolithic application )，单体式应用内部包含了所有需要的服务。而且各个服务功能模块有很强的耦合性，也就是相互依赖彼此，很难拆分和扩容。

说在做的各位都写过单体程序，大家都没意见吧？给大家举个栗子，刚开始写代码你写的helloworld程序就是单体程序，一个程序包含所有功能，虽然 helloworld 功能很简单。

1. 单体应用程序的优点

• 开发简洁，功能都在单个程序内部，便于软件设计和开发规划。
• 容易部署，程序单一不存在分布式集群的复杂部署环境，降低了部署难度。
• 容易测试，没有各种复杂的服务调用关系，都是内部调用方便测试。

2. 单体应用程序的缺点

单体程序的缺点一开始不是特别明显，项目刚开始需求少，业务逻辑简单，写代码一时爽，一直爽。噩梦从业务迭代更新，系统日益庞大开始，前期的爽没有了，取而代之的是软件维护和迭代更新的无尽痛苦。

由于单体式应用程序就像一个大型容器一样，里面放置了许多服务，且他们都是密不可分的，这导致应用程序在扩展时必须以「应用程序」为单位。

当里面有个业务模块负载过高时，并不能够单独扩展该服务，必须扩展整个应用程序（就是这么霸道），这可能导致额外的资源浪费。

此外，单体式应用程序由于服务之间的紧密度、相依性过高，这将导致测试、升级有所困难，且开发曲线有可能会在后期大幅度地上升，令开发不易。相较之下「微服务架构」能够解决这个问题。

1:系统启动慢，一个进程包含了所有的业务逻辑，涉及到的启动模块过多，导致系统的启动、重启时间周期过长;

2:系统错误隔离性差、可用性差，任何一个模块的错误均可能造成整个系统的宕机;

3:可伸缩性差:系统的扩容只能只对这个应用进行扩容，无法结合业务模块的特点进行伸缩。

4: 线上问题修复周期长:任何一个线上问题修复需要对整个应用系统进行全面升级。

5: 跨语言程度差

6: 不利于安全管理，所有开发人员都拥有全量代码。

小型项目适合单体应用架构. 比如:OA办公系统。管理类的项目 仓库管理系统。

二、微服务应用

微服务架构论文: https://martinfowler.com/articles/microservices.html

译文: https://blog.csdn.net/qq_42261668/article/details/102839758

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

一个项目被拆分若干个项目
每个项目可以独立运行
每个项目可以使用不同的语言开发
每个项目可以拥有独立的数据库
项目与项目之间可以通信[http协议]

1.**解读微服务特点:**

1:微服务是一种项目架构思想(风格)

2:微服务架构是一系列小服务的组合（组件化与多服务)

3:任何一个微服务，都是一个独立的进程(独立开发、独立维护、独立部署)

4:轻量级通信http协议(跨语言,跨平台)

5:服务粒度(围绕业务功能拆分—模块拆分【系统管理服务】【日志服务】【焦虑测试】【抑郁测试系统】)

2. 微服务架构的优势

1.易于开发和维护
一个微服务只关注一个特定的业务功能，所以它的业务清晰、代码量较少。开发和维护单个微服务相对比较简单，整个应用是由若干个微服务构建而成，所以整个应用也会维持在可控状态;

⒉.单个微服务启动较快
单个微服务代码量较少，所以启动会比较快;

3.局部修改容易部署
单体应用只要有修改，就要重新部署整个应用，微服务解决了这样的问题。一般来说，对某个微服务进行修改，只需要重新部署这个服务即可;

4.技术栈不受限
在微服务中，我们可以结合项目业务及团队的特点，合理地选择技术栈

5.按需伸缩

焦虑系统访问量大，只需要对焦虑系统进行扩展

3. 微服务架构的缺点(挑战)

1、服务太多，导致服务间的依赖错综复杂，运维难度大

2、微服务放大了分布式架构的系列问题

• 分布式事务(seata)

• 分布式锁怎么处理(redisson) ,

• 服务注册与发现(nacos) .

• 依赖服务不稳定(sentinel)导致服务雪崩怎么办?

3、运维复杂度陡增，部署数量多、监控进程多导致整体运维复杂度提升。

如何解决上面的挑战----springcloud

4.SpringCloud与微服务关系

• Springcloud为微服务思想提供了完美的解决方案

• Springcloud是一些列框架的集合体（不同的框架解决微服务面临的不同的挑战)

springcloud提供了两款模式:第一种netflix公司 第二款：alibaba-阿里巴巴。

5.SpringBoot和SpringCloud关系

• SpringBoot专注于快速方便的开发单个个体微服务。
• SpringCloud是关注全局的微服务协调、整理、治理的框架，它将SpringBoot开发的单体整合并管理起来。
• SpringBoot可以离开SpringCloud独立使用开发项目，但是SpringCloud离不开SpringBoot，属于依赖关系。