微服务的一些基础概念

微服务的定义：    
把传统的单体架构的业务系统，打散为更细粒度的单位，每一个单位它都是可以独立的进行需求设计、开发测试、部署运维和交付的。每个单位都能做到独立的自治。这个打小的单位，就是我们所说的微服务。拆分出来的微服务之间，只能通过REST API进行协同或交互。这是网上对于微服务强调的最最关键的内容。要抓住微服务的核心，就是大拆小。拆小的每一个组件，能够做到独立的自治。

微服务的调用：
处理组件之间的接口交互，不能通过传统的紧耦合去调用，要去用轻量的接口去调用。一个组件不能去访问另一个组件的数据库。可以通过走gRPC接口，走rest api接口。通过上层轻量的api接口，实现三个微服务之间的调用。

一个微服务怎么知道另一个微服务暴露的接口地址在哪里呢？ 如何实现接口的实现和调用呢？

这时候就有一个很重要的名词，服务的注册与发现中心。当微服务A有一个接口暴露出来后，首先是注册到注册中心。 微服务B 从注册中心找到这个接口地址，然后再发起对微服务A 的调用。 微服务是一个去中心化的架构。3个微服务之间的接口调用，接口之间本身是一个点对点的调用方式。 虽然有了注册中心的存在，注册中心只是管了最基本的控制流。即使注册中心宕机了，3个组件之间由于存在地址的缓存，仍然可以发起微服务组件之间的接口调用。

如何发起对另一个微服务的接口调用呢？
在主流的微服务框架里面，消费端会有一个类似于Feign的组件，通过Feign组件发起对另一个微服务的接口调用，就好像调用了我本地的接口一样。Feign组件在中间做了一层包装和代理。

展现层，既可以有桌面端的应用，也可以有APP端的应用。APP端建议统一打包，但是桌面端的应用，每个微服务的前端建议独立打包。不仅仅实现底层微服务的解耦，对于前端仍然需要独立的打包。通过前端实现彻底的解耦。

微服务最终提供的微服务能力，首先是接入注册到微服务网关。通过微服务网关提供一个统一的http可以访问的出口地址，给前端的功能页面进行调用，这个就是微服务网关存在的关键原因。前端框架各种各样，没法通过在前端植入Feign这样的组件，直接访问微服务。

为什么有了微服务网关之后，还要有API网关呢？
微服务网关请求的颗粒度仅为微服务的粒度。API网关的接口请求流量代理是可以到API接口服务的颗粒度。这个就是微服务网关和API网关最大的一个区别。

我们总是说，微服务架构是一个完整的去中心化的架构，但整个微服务架构一涉及到前端，涉及到底层微服务的能力要统一对前端开放，这个时候必然是要引入微服务网关或者API网关。API网关的本质仍然是中心化的架构。

随着云原生和微服务的发展，类似于去中心化的微服务治理逐渐流行，我们可以把API网关本身的流量管控拦截能力，通过sidecar的方式下放到微服务的边车端。不管是微服务网关还是API网关剩余的能力，仅仅只剩下了流量的请求转发。此时用负载均衡的集群或k8s，负载均衡的能力、集群的能力完完全全可以满足需求。