微服务架构的核心关键点

• 微服务需要考量的核心技术点
• 微服务的治理
• 微服务的负载均衡
• 微服务的统一入口
• 微服务的容错
• 微服务的统一配置
• 微服务的监控

微服务需要考量的核心技术点

微服务的治理

当我们架构微服务应用时首先遇到的问题是服务之间的通信（服务调用），那么服务之间的调用就会有服务的生产者和服务的消费者之分。因此作为服务消费者如何访问并调用服务提供者提供给的服务，作为服务提供者如何让服务消费者知道并消费是我们首要考虑的问题。在微服务架构下，同一个微服务可能同时存在多个实例，并且这些微服务还在不停的上线、下线，那么他们如何相识、相知进行通信呢？使用物理地址显然不行，应为不知道服务提供者到底在那台机器，服务当前是否仍然在线，如果服务不在线进行调用岂不是造成调用失败？
对此业界的解决方案是服务治理（服务注册于发现）。通过服务发现消费者在不知道服务物理地址的情况下通过服务名称就可以进行调用。服务注册，可以让服务提供者在上线时将所提供的服务信息注册到治理服务器中，供消费者使用。

微服务的负载均衡

对于负载均衡通常是用户请求入口的负载均衡，但在微服务中负载均衡不止指的是用户请求入口的负载均衡也包括微服务实例之间调用的负载均衡。对于传统的负载均衡方案无法应变微服务应用实例的快速变化。因此业界提出了客户端的负载均衡，也就是常说的软负载。其核心思想就是在服务消费者的本地保存一份服务者列表。这份服务者列表通常是从服务治理服务器上同步下来的，然后通过某种软负载机制决定每次服务调用时所使用的具体服务实例。从而实现微服务之间的负载均衡。

微服务的统一入口

微服务是众多的，而且大部分都是的对外提供某种接口的。所以对于前端来说一个完整的功能可能调用很多个微服务接口那么这种不不合理的。我们可以通过门户的模式解决这个问题，使多个服务聚合成一个接口对外开放。

微服务的容错

微服务应用是一种高度的分布式架构应用，个微服务之间的调用更是通过网络来通信的，而且一个用户请求往往涉及多个微服务。我们知道网络通信是不可靠的，那么怎么防止由于一个服务调用失败而导致的服务雪崩效应呢？
在业界对微服务的容错提出了服务熔断、服务降级处理，这些模式可以有效地防止微服务调用失败而引起的连锁反应。

微服务的统一配置

对于微服务架构，我们可能面临成数十个甚至上百个应用，可以预见变更一个配置数据时的难度，又是我们还希望某个应用可以独立进行更改，从而造成更大的混乱。因此微服务的统一配置需要提前考虑。

微服务的监控

微服务场景下线上排错和分析日志将会是有很大的难度，应用上线后日志多由服务实例自己管理，如何将分散的多个日志之间的调用串联起来，形成一个完整的请求调用链，将会时一个巨大的挑战。