微服务架构的核心关键点

针对构建微服务架构时需要考量的核心关键点，总结如图所示

微服务架构的核心关键点

-    微服务的服务治理     -

当我们架构微服务应用时首先遇到的一个问题是，作为消费者如何访问并调用服务提供者所提供的服务，作为服务提供者如何能让服务消费者知道并进行消费。在传统应用开发时，通常是在开发语言层面上解决这个问题，可能我们从来也没有考虑过这个问题，甚至可以说这个问题在传统开发时根本不存在。但在微服务架构下，同一个微服务可能同时存在多个实例，并且这些微服务实例还在不停上线、下线，那么它们如何相知、相识并进行通信呢？使用物理地址显然不行，因为不知道服务提供者到底在哪台服务器，服务当前是否仍然在线，如果服务不在线还进行调用岂不是造成调用失败？

此外，对于微服务架构应用来说还有一个重要考量因素：快速水平扩展。在进行快速扩展时我们不可能预先知道所有的服务实例地址并告知服务消费者，而且也无法确定有哪些、有多少消费者会来消费。

业界对于此问题典型的解决方案就是服务治理（服务注册及服务发现）。通过服务发现，消费者可以在预先不知道服务提供者物理地址的情况下，仅通过相应的服务名称就可以实现服务调用。服务注册机制，可以让服务提供者在上线时将所提供的服务信息注册到服务治理服务器中，供服务消费者使用。当服务下线时将自己从服务治理服务器中注销，避免服务消费者调用而造成的异常。

-    微服务的负载均衡     -

对于负载均衡，传统应用通常会在用户请求的入口通过负载均衡设备（如F5等）或通过Ngnix反向代理方式实现负载均衡。但在微服务架构下负载均衡不仅仅指的是用户请求入口，还包含了微服务之间的调用。如果此时再采用之前传统的解决方案，显然是不合适的：一是传统的负载均衡设备配置非常复杂；二是微服务应用实例在快速变化。

因此，针对微服务之间的负载均衡需要另谋出路。因此业界提出了客户端负载均衡的概念，也称之为软负载均衡。核心思想就是在服务消费者（也就是客户端）保存有一份服务者列表，这份服务者列表通常是从服务治理服务器中动态获取，也可以采用固定配置方式，然后通过某种负载均衡策略来决定每次服务调用时所使用的具体服务实例，从而实现微服务之间的负载均衡。

-    微服务的统一入口     -

微服务是众多的，而且大部分都会对外提供某种服务接口。对于前端或者第三方开发者来说，一定不愿意与多个服务地址打交道。那么如何将这么多微服务入口统一到一个入口进行管理呢？可能首先映入你脑海的就是门户模式，通过门户模式可以有效地隐藏后端的复杂性，对客户提供统一访问入口。对于微服务也是，API服务网关就是为微服务提供了一个统一入口，并能够附加一些路由规则，使得不同的微服务通过路由规则提供一致的访问入口。

-    微服务的容错     -

微服务架构的应用是一种高度分布式架构应用，各微服务之间的调用更是通过网络来完成，而且一个用户的请求往往需要涉及多个微服务。我们知道网络访问是不可靠的，那么如何在一个微服务不可用时不会影响其他微服务及调用者，以及如何有效防止服务调用失败而引起的“雪崩效应”呢？如何在一个服务不可用时能够对用户更加友好，使整个应用非常具有弹性呢？这些是实施微服务架构时一个非常重要的话题。

在业界，针对微服务架构的容错提出了断路器、服务降级等模式，这些模式都可以有效防止微服务调用失败而引起的连锁反应，并且在必要时可以通过这些模式主动实施应用的降级处理，从而保证核心业务的正常运行。

-    微服务的统一配置     -

单体应用中可以直接在所开发项目中进行配置管理。而在微服务架构中，一个应用被拆成众多的微服务，并由不同的团队负责，而这些微服务中会存在一些共同的配置数据，如果还是分散在各个项目中分别进行管理，那么面对数十个、上百个应用实例，可以预见变更一个配置数据时的难度。此外，我们也不希望某个应用实例可以独立进行变更，从而造成更大的混乱。因此，如何统一对配置进行管理和发布更新，就需要在构建微服务之初进行思考。

-    微服务的监控     -

微服务的灵活和强大也为开发者带来了“噩梦”一般的调试和跟踪分析体验。单体架构下所有的应用都在一起，根本不存在难以调试的问题。对于调用和跟踪分析的重要性不言而喻，特别是当应用正式上线时，通过日志分析可以快速定位到问题所在。

而在微服务场景下调试将难以进行，因为一个用户请求会涉及多个微服务应用，要在多个应用下统一进行调试将会非常困难。应用上线后，日志多由服务实例自己管理，如何将分散在多个日志之间的调用串联起来，形成一个完整的请求调用链，将是另外一个非常大的挑战。因此，针对这个问题及需求，业界在微服务监控中提供了日志聚合、日志可视化分析、调用链跟踪等解决方案，都可为我们所构建的微服务应用的运维提供强有力的武器。

-    微服务的部署     -

在动辄几十个甚至上百个服务实例在线，并且不断上线、下线的场景下，开发者一定不愿意通过手工构建和部署这些服务实例。此时，开发者更愿意将这些处理交付给自动化工具去做，一方面可以提升工作效率，另一方面通过自动化的方式才能够保障所构建和部署的服务实例一致化。因此，业界针对这种需求提出了相应的解决方案，包括通过构建—发布管道来构建自动化发布流程。可以通过Docker工具来快速部署，通过k8s来构建自动化部署编排等。