江苏龙网

  1. 首页 > 人文 > >

技术编程微服务架构的核心关键点


针对构建微服务架构时需要考量的核心关键点 ， 总结如图所示
技术编程微服务架构的核心关键点
本文插图
微服务架构的核心关键点
- 微服务的服务治理 -
当我们架构微服务应用时首先遇到的一个问题是 ， 作为消费者如何访问并调用服务提供者所提供的服务 ， 作为服务提供者如何能让服务消费者知道并进行消费 。 在传统应用开发时 ， 通常是在开发语言层面上解决这个问题 ， 可能我们从来也没有考虑过这个问题 ， 甚至可以说这个问题在传统开发时根本不存在 。 但在微服务架构下 ， 同一个微服务可能同时存在多个实例 ， 并且这些微服务实例还在不停上线、下线 ， 那么它们如何相知、相识并进行通信呢？使用物理地址显然不行 ， 因为不知道服务提供者到底在哪台服务器 ， 服务当前是否仍然在线 ， 如果服务不在线还进行调用岂不是造成调用失败？
此外 ， 对于微服务架构应用来说还有一个重要考量因素：快速水平扩展 。 在进行快速扩展时我们不可能预先知道所有的服务实例地址并告知服务消费者 ， 而且也无法确定有哪些、有多少消费者会来消费 。
业界对于此问题典型的解决方案就是服务治理（服务注册及服务发现） 。 通过服务发现 ， 消费者可以在预先不知道服务提供者物理地址的情况下 ， 仅通过相应的服务名称就可以实现服务调用 。 服务注册机制 ， 可以让服务提供者在上线时将所提供的服务信息注册到服务治理服务器中 ， 供服务消费者使用 。 当服务下线时将自己从服务治理服务器中注销 ， 避免服务消费者调用而造成的异常 。
- 微服务的负载均衡 -
对于负载均衡 ， 传统应用通常会在用户请求的入口通过负载均衡设备（如F5等）或通过Ngnix反向代理方式实现负载均衡 。 但在微服务架构下负载均衡不仅仅指的是用户请求入口 ， 还包含了微服务之间的调用 。 如果此时再采用之前传统的解决方案 ， 显然是不合适的：一是传统的负载均衡设备配置非常复杂；二是微服务应用实例在快速变化 。
因此 ， 针对微服务之间的负载均衡需要另谋出路 。 因此业界提出了客户端负载均衡的概念 ， 也称之为软负载均衡 。 核心思想就是在服务消费者（也就是客户端）保存有一份服务者列表 ， 这份服务者列表通常是从服务治理服务器中动态获取 ， 也可以采用固定配置方式 ， 然后通过某种负载均衡策略来决定每次服务调用时所使用的具体服务实例 ， 从而实现微服务之间的负载均衡 。
- 微服务的统一入口 -
微服务是众多的 ， 而且大部分都会对外提供某种服务接口 。 对于前端或者第三方开发者来说 ， 一定不愿意与多个服务地址打交道 。 那么如何将这么多微服务入口统一到一个入口进行管理呢？可能首先映入你脑海的就是门户模式 ， 通过门户模式可以有效地隐藏后端的复杂性 ， 对客户提供统一访问入口 。 对于微服务也是 ， API服务网关就是为微服务提供了一个统一入口 ， 并能够附加一些路由规则 ， 使得不同的微服务通过路由规则提供一致的访问入口 。
- 微服务的容错 -
微服务架构的应用是一种高度分布式架构应用 ， 各微服务之间的调用更是通过网络来完成 ， 而且一个用户的请求往往需要涉及多个微服务 。 我们知道网络访问是不可靠的 ， 那么如何在一个微服务不可用时不会影响其他微服务及调用者 ， 以及如何有效防止服务调用失败而引起的“雪崩效应”呢？如何在一个服务不可用时能够对用户更加友好 ， 使整个应用非常具有弹性呢？这些是实施微服务架构时一个非常重要的话题 。
在业界 ， 针对微服务架构的容错提出了断路器、服务降级等模式 ， 这些模式都可以有效防止微服务调用失败而引起的连锁反应 ， 并且在必要时可以通过这些模式主动实施应用的降级处理 ， 从而保证核心业务的正常运行 。


推荐阅读


上一篇：李孝利|唯饭写感谢信，感谢自家爱豆被“欺负”，还有了代理满足感？

下一篇：2020ChinaJoy逛展指南|2020ChinaJoy逛展指南：这些新变化您一定要知晓