课堂笔记：web项目为什么要用微服务/分布式开发

why:

一体化架构的问题

难以扩展

一体化架构应用只能通过在负载均衡器后面放置整个应用程序的多个实例来进行水平扩展。如果应用中的特定服务需要扩展，则没有简单的选项。我们需要完整地扩展应用程序，这显然会造成不必要的资源浪费。

相比之下，基于微服务的应用程序允许我们根据需要独立扩展单个服务。如果需要缩放服务B，则可以有10个实例，同时保持其他实例，并可以根据需要随时更改。

交付时间长

一体化架构在单个应用的任何部分/层中进行的任何更改都需要构建和部署整个应用程序。个人开发人员还需要下载整个应用程序代码来修复和测试，而不仅仅是受影响的模块，这就影响到了持续部署的效率。

而在微服务架构中，如果仅在一百个微服务中的一个中需要改变，则仅构建和部署改变的微服务，没有必要部署一切。我们甚至可以在短时间内多次部署。

应用复杂性

过去，随着应用规模的增长（功能、功能等），团队也会相应扩张，应用很快就就会变得复杂和交织在一起。随着不同的团队不断修改代码，维护模块化结构慢慢变得越来越困难，并慢慢导致像意大利面一样交织的代码。这不仅会影响代码质量，还会影响整个组织。

在基于微服务的应用中，每个团队都在单独的微服务上工作，代码会有序很多。

故障级联

如果没有正确设计，一体化应用的一部分失败可能会级联并导致整个系统崩溃。

在基于微服务的架构的情况下，我们可以使用断路器来避免这种故障。

陷入某种技术/语言

使用一体化架构，意味着被某种已实现的技术/语言锁定。如果需要更改技术/语言，则必须重写整个应用程序。

使用微服务，每个服务可以根据需求和业务以不同的技术或语言实现。任何改变服务技术/语言的决定都只需要重写该特定服务，因为所有微服务都是相互独立的。

小结

简单来说，使用微服务架构会获得以下好处：

• 
  独立开发部署服务
• 
  速度和敏捷性
• 
  更高的代码质量
• 
  获得围绕业务功能创建/组织的代码
• 
  提高生产力
• 
  更容易扩展
• 
  自由（在某种程度上）选择实施技术/语言
   

what:

微服务：一种软件开发技术- 面向服务的体系结构（SOA）架构样式的一种变体，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）。每个服务都围绕着具体业务进行构建，并且能够独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据上下文，选择合适的语言、工具对其进行构建。

when:

如果您正在构建的应用程序有一个相当清晰的领域，未来会演进到一个相当的规模，在项目开始就会配置大型的团队，并且你对团队的技术有信心，你在分布式设计方面有一些经验或者至少有一些素养，同时又能获得管理层方面对于失败和学习的支持和容忍，那么微服务会是一个很好的选择。

where:

集中式的，应用的公司单体服务或简单的分布式服务已经无法满足快速迭代的业务的项目，可以使用微服务。

who:

规模决定一切

你的系统有多少人在开发？五个？十个？五十？一百？还是一千？如果你的应用程序、平台、应用程序套件或其他任何东西，有超过 500 人在开发，那么我认为，你大可以放心使用微服务。但是，如果你的应用程序开发工程师不足 100 人，那么别采用。

how:

参见Spring Cloud 工具集。

Spring-Cloud

微服务架构工具集，提供了搭建微服务架构所需用的各种工具，借由这些工具，开发人员可以快速的搭建一个微服务架构。

Spring Cloud 为开发者提供了工具来快速构建分布式系统中的一些常见模式（例如配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性令牌、全局锁、领导选举、分布式会话，集群状态）。分布式系统协调存在一些通用模式，使用 Spring Cloud 开发人员可以快速建立实现这些模式的服务和应用程序。它们在任何分布式环境中都能很好地工作，包括开发人员自己的笔记本电脑、裸机数据中心以及 Cloud Foundry 等托管平台。

Spring Cloud称为 伞形项目，由多个子项目组成，留意三个子项目

• spring-cloud-netflix spring-cloud第一个子项目，应用广泛

• • 服务发现：spring-cloud-netflix-eureka
  • 负载均衡：ribbon

• • 服务容错：hystrix
  • 配置管理：archius

• • 服务调用：feign
  • 服务网关： zuul

• spring-cloud-alibaba 阿里巴巴出品，国产，中文，符合中国国情，在国内采用比较多

• • 服务发现：spring-cloud-alibaba-nacos
  • 服务容错：sentinel

• • 配置管理：nacos
  • 服务调用：dubbo

• • 分布式事务：seata
  • 消息队列：rocketmq

• spring-cloud官方组件

• • 服务网关：spring-cloud-gateway
  • 服务调用：openfeign

>>>同一个问题，可以有不同的解决方案，使用不同的组件来解决相同的问题

项目技术选型

• 服务发现： nacos
• 负载均衡： ribbon

• 服务容错：sentinel
• 配置管理：nacos

• 服务调用：openfeign
• 服务网关： spring-cloud-gateway

• 分布式事务：seata
• 消息队列：rocketmq

• 搜索引擎： elasticsearch
• 服务追踪： zipkin

• 部署：docker + k8s

>>> 选用不同子项目的不同组件来搭建架构，不同组件之间是兼容的（都在spring-cloud之下）

spring-cloud vs spring-boot 版本兼容性

Release Train	Boot Version
2020.0.x aka Ilford	2.4.x, 2.5.x (Starting with 2020.0.3)
Hoxton	2.2.x, 2.3.x (Starting with SR5)
Greenwich	2.1.x
Finchley	2.0.x
Edgware	1.5.x
Dalston	1.5.x