这是来自菜鸡选手的搜罗集合. 侵权删.
一, 什么是微服务
微服务是一种用于构建应用的架构方案. 微服务架构有别于更为传统的单体式方案, 可将应用拆分成多个核心功能. 每个功能都被称为一项服务, 可以单独构建和部署, 这意味着各项服务在工作 (和出现故障) 时不会相互影响. 降低各个服务之间的耦合, 防止修改一个模块时牵一发而动全身. 目前企业常用的微服务架构主要有 SpringCloud 和 Dubbo.
二, SpringCloud 与 SpringBoot 的关系
SpringBoot 是 Spring 推出的用于解决传统框架配置文件冗余, 装配组件繁杂的基于 maven 的解决方案, 旨在快速搭建单个微服务.
SpringCloud 是解决各个微服务之间协调与配置, 服务之间的通信, 熔断, 负载均衡等整合各个微服务的框架. Spring Cloud 并不重复造轮子, 而是将市面上开发得比较好的模块集成进去, 进行封装, 从而减少了各模块的开发成本. 换句话说: Spring Cloud 提供了构建分布式系统所需的 "全家桶".
SpringCloud 依赖于 SpringBoot. 而 SpringBoot 并不依赖于 SpringCloud, 甚至还可以和 Dubbo 进行优秀的整合开发.
三, SpringCloud 常用模块 -- 服务发现
对于 Dubbo 服务指一个接口, 而对 SpringCloud 来说, 一个服务代表一个工程. 当 SpringCloud 需要调用一个服务时, 即需要调用一个工程, 需要知道工程的 ip 与端口号.
传统应用中, 服务实例的网络地址是相对静态的, 你的代码可以从一个很少更新的配置文件中读取网络地址. 在一个现代的, 基于云的微服务应用中, 这个问题就变得复杂多了, 服务实例的网络地址是动态分配的. 而且, 由于自动扩展, 失败和更新, 服务实例的配置也经常变化. 这样一来, 你的客户端代码需要一套更精细的服务发现机制.
具体内容推荐一篇博客, 清晰易懂
https://blog.csdn.net/u011277123/article/details/88994535
四, SpringCloud 常用模块 -- 客户服端负载均衡
https://blog.csdn.net/qq_20619819/article/details/81089997
负载均衡分为两种, 一种是服务端负载均衡, 一种是客户端负载均衡.
服务端负载均衡: 分为两种, 一种是硬件负载均衡, 还有一种是软件负载均衡.
重点看软件负载均衡: 主要是在服务器上安装一些具有负载均衡功能的软件来完成请求分发进而实现负载均衡, 常见的就是 Nginx.Nginx 采用的是反向代理技术, 代理服务器来接受 internet 上的连接请求, 然后将请求转发给内部网络上的服务器, 并将从服务器上得到的结果返回给 internet 上请求连接的客户端, 此时代理服务器对外就表现为一个服务器. 反向代理负载均衡技术是把将来自 internet 上的连接请求以反向代理的方式动态地转发给内部网络上的多台服务器进行处理, 从而达到负载均衡的目的.
正向代理: 客户端向代理发送一个请求并指定目标(原始服务器), 然后代理向原始服务器转交请求并将获得的内容返回给客户端. 客户端必须要进行一些特别的设置才能使用正向代理.
反向代理: 客户并不知道代理是转交请求并获得数据返回, 客户以为此服务器即原始服务器, 反向代理对外都是透明的, 访问者并不知道自己访问的是一个代理.
无论是硬件负载均衡还是软件负载均衡都会维护一个可用的服务端清单, 然后通过心跳机制来删除故障的服务端节点以保证清单中都是可以正常访问的服务端节点, 此时当客户端的请求到达负载均衡服务器时, 负载均衡服务器按照某种配置好的规则从可用服务端清单中选出一台服务器去处理客户端的请求. 这就是服务端负载均衡.
客户端负载均衡, Ribbon 是一个基于 HTTP 和 TCP 的客户端负载均衡器, 当我们将 Ribbon 和 Eureka 一起使用时, Ribbon 会从 Eureka 注册中心去获取服务端列表, 然后进行轮询访问以到达负载均衡的作用, 服务端是否在线这些问题则交由 Eureka 去维护. 那么这个时候发现这两者的机制差不多, 都是通过心跳维护有效服务清单列表, 不同之处在于清单列表的存储位置. 在 Spring Cloud 中我们如果想要使用客户端负载均衡, 方法很简单, 开启 @LoadBalanced 注解即可, 这样客户端在发起请求的时候会先自行选择一个服务端, 向该服务端发起请求, 从而实现负载均衡.
五, SpringCloud 常用模块 -- 服务网关
https://www.jianshu.com/p/6ed93de6f42a
为什么要使用网关?
API 网关的出现的原因是微服务架构的出现, 不同的微服务一般有不同的网络地址, 而外部客户端可能需要调用多个服务的接口才能完成完成一个业务需求, 如果让客户端直接与各个微服务通信, 会出现以下的问题.
1, 客户端会多次请求不同的微服务, 增加了客户端的复杂性.
2, 存在跨域请求, 在一定场景下处理相对复制.
3, 认证复杂, 每个服务都需要独立的认证.
4, 难以重构, 随着项目的迭代. 可能需要重新划分微服务. 如果客户端与微服务直接通信, 那么重构将会很复杂.
5, 某些微服务可能使用了防火墙 / 浏览器不友好的协议, 直接访问会有一定的困难.
以上的问题可以借助 API 网关来解决. API 网关是介于客户端和服务器端之间的中间层, 所有的外部请求都会先经过 API 网关这一层. 也就是说, API 网关可以完成安全, 性能, 监控等功能, 而服务提供者可以专门的完成具体的业务逻辑.
六, SpringCloud 常用模块 -- 断路器
来源: http://www.bubuko.com/infodetail-3675875.html