【微服务】消息队列与微服务之微服务详解

微服务

单体架构

• 传统架构（单机系统），一个项目一个工程：比如商品、订单、支付、库存、登录、注册等等，统一部署，一个进程
• all in one的架构方式，把所有的功能单元放在一个应用里。然后把整个应用部署到一台服务器上。如果负载能力不行，将整个应用进行水平复制，进行扩展，然后通过负载均衡实现访问。
• Java实现：JSP、Servlet，打包成一个jar、war部署
• 易于开发和测试:也十分方便部署;当需要扩展时，只需要将war复制多份，然后放到多个服务器 上，再做个负载均衡就可以了。
• 如果某个功能模块出问题，有可能全站不可访问，修改Bug后、某模块功能修改或升级后，需要停掉整个服务，重新整体重新打包、部署这个应用war包，功能模块相互之间耦合度高,相互影响,不适合当今互联网业务功能的快速迭代。
• 特别是对于一个大型应用，我们不可能吧所有内容都放在一个应用里面，我们如何维护、如何分工合作都是问题。如果项目庞大，管理难度大
• Web应用服务器：开源的tomcat、jetty、glassfish。商用的有weblogic、websphere、Jboss

SOA

1. SOA（Service Oriented Architecture）是由多个服务组成的分布式系统
2. 各个子系统之间没有采用统一的通信标准,导致系统间通信与数据交互变得异常复杂
3. 各个服务之间通过ESB(Enterprise Service Bus)进行通信,ESB是一个由大量规则和原则集成的软件架构，可以将一系列不同的应用序集成到单个基础架构中，由于没有好的开源方案，只能使用商业公司的产品,因此成本很高
4. 此外ESB属于重量级产品，部署规划异常笨重
5. ESB的单点依赖和商业ESB的费用问题反而成为了所有服务的瓶颈

微服务

https://www.martinfowler.com/microservices/

• 微服务属于SOA的子集,SOA可以认为面向服务的1.0版本,微服务可以认为是面向服务的2.0版本
• 微服务化的核心就是将传统的一站式应用，根据业务拆分成一个一个的服务，彻底消除强耦合，每一个微服务提供单个业务功能，一个服务只做一件事。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等
• 从技术角度讲每个微服务就是一种小而独立的处理过程，类似与进程的概念，能够自行单独启动或销毁
• 微服务架构（分布式系统），各个模块/服务，各自独立出来，“让专业的人干专业的事”，独立部署。分布式系统中，不同的服务可以使用各自独立的数据库。
• 服务之间采用轻量级的标准的通信机制,通常是基于HTTP的RESTful (Representational State Transfer 表述性状态转移）API
• 微服务设计的思想改变了原有的企业研发团队组织架构。传统的研发组织架构是水平架构，前端、后端、DBA、测试分别有自己对应的团队，属于水平团队组织架构。而微服务的设计思想对团队的划分有着一定的影响，使得团队组织架构的划分更倾向于垂直架构，比如用户业务是一个团队来负责，支付业务是一个团队来负责。但实际上在企业中并不会把团队组织架构拆分得这么绝对，垂直架构只是一种理想的架构
• 微服务的实现框架有多种，不同的应用架构，部署方式也有不同

微服务的优缺点

微服务优点：

• 每个服务足够内聚，足够小，代码容易理解。这样能聚焦一个简单唯一的业务功能或业务需求。
• 开发简单、开发效率提高，一个服务可能就是专业的只干一件事，微服务能够被小团队单独开发，这个小团队可以是2到5人的开发人员组成
• 微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。
• 微服务能使用不同的语言开发
• 易于和第三方集成，微服务运行容易且灵活的方式集成自动部署，通过持续集成工具，如: Jenkins、Hudson、Bamboo
• 微服务易于被一个开发人员理解、修改和维护，这样小团队能够更关注自己的工作成果，无需通过合作才能体现价值
• 微服务允许你利用融合最新技术。微服务只是业务逻辑的代码，不会和HTML/CSS或其他界面组件混合，即前后端分离
• 每个微服务都有自己的存储能力，一般都有自己的独立的数据库，也可以有统一数据库

微服务缺点:

• 微服务把原有的一个项目拆分成多个独立工程，增加了开发、测试、运维、监控等的复杂度
• 微服务架构需要保证不同服务之间的数据一致性，引入了分布式事务和异步补偿机制，为设计和开发带来一定挑战
• 开发人员和运维需要处理分布式系统的复杂性，需要更强的技术能力
• 微服务适用于复杂的大系统，对于小型应用使用微服务，进行盲目的拆分只会增加其维护和开发成本

常见的微服务框架

https://cn.dubbo.apache.org/zh-cn/index.html
https://spring.io/projects/spring-cloud

• Dubbo

  • 阿里开源贡献给了ASF，目前已经是Apache的顶级项目
  • 一款高性能的Java RPC服务框架，微服务生态体系中的一个重要组件
  • 将单体程序分解成多个功能服务模块，模块间使用Dubbo框架提供的高性能RPC通信
  • 内部协调使用 Zookeeper，实现服务注册、服务发现和服务治理

• Spring cloud

  • 一个完整的微服务解决方案，相当于Dubbo的超集

• 微服务框架，将单体应用拆分为粒度更小的单一功能服务

  • 基于HTTP协议的REST风格实现模块间通信

Spring Boot 和 Spring cloud

Spring Boot

Spring Boot是一个用于简化和加速Java应用程序开发的框架。它是由Spring团队开发的，基于Spring框架构建的一个轻量级、开箱即用的框架。
Spring Boot旨在简化传统的Spring应用程序开发过程，通过自动配置和约定优于配置的原则，使得开发人员能够更快地构建独立的、生产级别的Spring应用程序。它提供了许多开箱即用的特性和功能，包括：

• 自动配置：Spring Boot根据应用程序的依赖和配置自动配置应用程序的各种组件，如数据源、Web服务器、安全性等。这大大简化了配置的过程。
• 起步依赖：Spring Boot提供了一系列的"起步依赖"，它们是预配置的依赖项集合，可以快速启动特定类型的应用程序。例如，使
  用"spring-boot-starter-web"起步依赖可以快速构建一个基于Web的应用程序。
• 嵌入式服务器：Spring Boot内置了常见的嵌入式服务器，如Tomcat、Jetty和Undertow，使得应用程序可以独立运行，无需额外安装和配置外部服务器。
• 简化的配置：Spring Boot使用约定优于配置的原则，通过提供合理的默认配置来简化应用程序的配置。开发人员只需关注需要修改的配置部分，而不必处理繁琐的全局配置。
• Spring Boot提供了Actuator模块，可以通过HTTP或JMX暴露应用程序的健康状况、指标和其他运行时信息，便于监控和管理应用程
  序。

总的来说，Spring Boot使得Java开发人员能够更快速、更简单地构建独立的、生产级别的应用程序。它提供了许多便利的功能和特性，使得
开发人员可以专注于业务逻辑的实现，而不必花费过多时间和精力在繁琐的配置和集成上。

Spring Cloud

Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。Spring Cloud并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

Spring Cloud的本质是在Spring Boot 的基础上，增加了一堆微服务相关的规范，并对应用上下文( Application Context )进行了功能增强。

既然Spring Cloud是规范那么就需要去实现，目前Spring Cloud规范已有Spring官方，Spring Cloud Netflix，Spring Cloud Alibaba等实现。通过组件化的方式，Spring Cloud将这些实现整合到一起构成全家桶式的微服务技术栈。
Spring Cloud和Spring Boot是两个相互关联但又独立的项目。它们都属于Spring生态系统，用于简化和加速Java应用程序的开发过程。下面是它们之间的关系：

• Spring Boot：Spring Boot是构建独立、自包含的、可以立即运行的Spring应用程序的框架。它通过提供自动配置、约定优于配置和简化的开发体验，简化了Spring应用程序的搭建和配置过程。Spring Boot减少了繁琐的配置，使得开发者可以更专注于业务逻辑的实现。Spring Boot可以独立使用，也可以与其他Spring项目一起使用。

• Spring Cloud：Spring Cloud是用于构建分布式系统和微服务架构的工具集合。它提供了一系列的功能和库，用于解决分布式系统中的常见问题，如服务注册与发现、负载均衡、断路器、配置管理等。Spring Cloud构建在Spring Boot之上，并使用Spring Boot的自动配置机制来简化微服务的开发和部署。Spring Cloud提供了许多用于构建可伸缩、弹性和可靠的分布式系统的库和工具。

因此，可以说Spring Cloud是建立在Spring Boot之上的一个框架，它利用了Spring Boot的简化开发和配置的能力，为构建分布式系统提供了额外的功能和工具。使用Spring Boot和Spring Cloud可以帮助开发者更轻松地构建和部署微服务架构，并解决分布式系统开发中的常见挑战

微服务还是单体

https://martinfowler.com/bliki/MonolithFirst.html
https://www.toutiao.com/article/7173261841408360990/?log_from=c8d3dfbf573b3_1670416613668

单体在绝大部分时候是更好的选择，即单体优先
在微服务大行其道的今天，其实已经有很多大师或者有务实的研发者已经意识到微服务在研发过程中，可能不是你想要的银弹，很多时候起到了反作用。

软件大师“Martin Fowler”在2015年就提出的“单体优先”（Monolith First）的思想。
Martin Fowler发现所有成功的微服务都遵循了通用的模式：

• 几乎所有成功的微服务故事，都是从一个变得太大而被分解的单体开始的。
• 几乎所有我听说过的从头开始构建为微服务系统的系统都以严重的麻烦告终。

这种模式导致Martin Fowler的许多同事认为：“你不应该用微服务开始一个新的项目，即使你确信你的应用程序将足够大，值得这么做…”

单体优先：

单体允许你探索系统的复杂性和组件的边界；
当复杂性增加时裂变出微服务；
当你边界和服务管理的业务知识增加时裂变出更多的微服务。
直接微服务:
直接使用微服务架构风险太大。

微服务是一种有用的架构，但即使是它们的拥护者也说使用它们会产生显著的“微服务附加费”，这意味着它们只对更复杂的系统有用。
这种附加费，本质上是管理一套服务的成本，将拖慢团队的速度，让使用单体应用成为更简单的选择。
这成为了“单体优先”策略的有力论证，即使你认为它可能会在以后从微服务架构中受益，你也应该在最初使用单体来构建应用。
通过先建立一个单体，你可以在使用微服务设计之前弄清楚什么是正确的边界。这也给了你时间来开发更好粒度的微服务。

单体优先策略一：模块化单体
合乎逻辑的方法是仔细设计一个单体应用，注意软件内部的模块化，包括 API 边界和数据存储方式。
做好这一点之后，从单体应用转向微服务是一件相对简单的事情。

单体优先策略二：边缘剥离
一种更常见的方法是从单体开始，逐渐剥离边缘的微服务。
这种方法可以在微服务架构的核心留下一个实质性的单体。
大多数新的开发都发生在微服务中，而单体是相对静止的。

单体优先策略三：整体替换
很少有人把这种做法看成是一种值得骄傲的做法，然而把单体作为一种牺牲性的架构来建造是有好处的。
不要害怕建造一个你会丢弃的单体应用，特别是如果一个单体应用能让你快速进入市场。

单体优先策略四：粗粒度服务
从几个粗粒度的服务开始，这些服务比你最终得到的微服务要大。
使用这些粗粒度的服务来习惯与多个服务一起工作。
同时享受这样一个事实，即这种粗粒度减少了你必须做的服务间重构的数量。
然后，随着边界的稳定，分解为更细粒度的服务。

“单体优先”的思想，目前已逐渐开始成为是业界普遍共识。现在已经属于后微服务时代!
在一个人数不多、资金不是无限充裕，需要快速将产品推向市场的团队，建议使用“单体优先”的实现方式。
在很多团队中，使用微服务其实是一种Hype Driven Development（炒作/简历驱动开发），不是为了真正为了解决业务问题。
使用“单体优先”，是一个务实的选择！试想如果是你自己创业，你会是选择“单体”还是“微服务”，那么请为你的企业进行务实的选择。

原文地址：https://blog.csdn.net/weixin_74814027/article/details/144043986

免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！