什么是微服务架构🍉

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

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

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

在这里插入图片描述
简单来说，就是将一个系统按业务划分成多个子系统，每个子系统都是完整的，可独立运行的，子系统间的交互可通过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)。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理，服务可用不同的语言开发，使用不同的数据存储技术。