微服务的架构思想

本文部分是学习记录,B站UP主鲁斯菲尔的授课内容

https://space.bilibili.com/31137138?spm_id_from=333.788.b_765f7570696e666f.1

有自己的理解记录,如果有异议,欢迎评论指出

1. 什么是单体应用和微服务

1.1 什么是单体应用

一个项目即为一个完整的应用, 通过代码功能,业务逻辑划分模块,将项目打成war包或者jar包等进行部署

1.2 什么是微服务

微服务是一种架构思想, 通过将功能分散到各个离散的服务中心以实现对解决方案的解耦 , 从而降低系统的耦合度, 并提供更加灵活的服务支持 , 实际开发为分布式系统开发

在代码层面通俗点理解: 根据应用程序的业务需求,功能模块将其分解为多个小型可独立运行的项目,并将多个小型项目串联, 形成一套完整的互联服务应用。

为什么要使用微服务架构: 为了解决单体应用的弊端,和使用微服务架构本身的优势

1.3 代码层面单体和微服务架构示意图

2. 单体应用的总结和微服务架构的优劣势

2.1 单体应用的优缺点

• 单体应用的优点

  • 开发简单, 集中管理, 基本避免重复开发, 功能都在本地, 没有分布式的管理和调用消耗.

  • 部署简单, 所有功能都在一个war 包, 部署再一个javaEE 容器(tomcat … )

    …单体的优点还有很多,但是重点是明白单体的缺点;

• 单体应用的缺点

  • 项目代码臃肿,随着业务逻辑和时间的增加,单体应用的代码会越来越多;

  • 可用性差,当项目中一个模块出现问题,极有可能导致整个项目崩溃;

  • 扩展性差,成熟的单体应用几乎无法改变项目架构和技术选型,很难引进使用新的技术

    … 单体应用还有很多的不足之处;

2.2 微服务架构的优缺点

• 微服务架构的优点

  • 降低了系统复杂度
  • 提高了*度, 可以选用合适的技术实现功能
  • 独立开发,部署

  总结: 解决复杂程度. 每个应用体积小,关联小 独立部署；

• 微服务架构的缺点

  • 服务之间需要相互通信才能完成调用,单体new对象就能调用
  • 拆成了多个服务, 需要更多的服务管理成本
  • CAP 定理 ( 针对CAP定理产生的 BASE 理论)

3. 分布式系统

个人理解为, 微服务是一套思想,分布式系统算是微服务的实现或者说是微服务的一种

3.1 分布式系统带来的问题

分布式系统那必然有很多的服务(项目), 十几个, 几十个, 上百个也有可能

• 有关联的服务之间如何访问
• 服务挂了怎么办 (如何实现系统的高可用)
• 这么多服务, 如何去管理
• 客户端如何访问这么多的服务

3.2 如何解决分布式系统的问题

使用治理框架如 : SpringCloud

总结

构建复杂的微服务应用程序本质上是困难的。单体架构模式只适用于简单、轻量级的应用程序，如果您使用它来构建复杂应用，您最终会陷入痛苦的境地。微服务架构模式是复杂、持续发展应用的一个更好的选择。尽管它存在着缺点和实现挑战

个人总结: 微服务就是把单个应用,拆分成多个小的应用, 通过业务逻辑,需求模块等拆分都行, 这样每个小的应用服务的代码量就少了,方便维护, 需要对其他的服务提供访问路径, 给出处理数据,就像单体应用的调用方法一样即可, 也是因为拆成了多个小服务, 那么对这些服务的管理就是最大的问题