微服务概念

微服务概念简介

要把传统的单体架构的业务系统打散为更细力度的单位，每一个单位它都是可以独立的进行需求设计开发测试部署和交付。每个单位都能够做到独立的自治。这个打小的单位，就是我们所说的“微服务”。
同时，每一个微服务之间，都只能通过轻量的 rest API 接口进行协同或者交互。
核心就是大拆小，拆小的每一个组件都能做到独立自治

例子——简易采购系统

一、传统的单体架构

原本在单体应用的展现层，仍然可以看到三个独立的一级菜单
但是在逻辑层可以看到这三个组件是紧耦合在一起的，无法拆开独立部署，同时，整个系统的数据库也是一起使用一个大的数据库，这就是传统的单体架构。

二、微服务架构

传统的单体架构转移到微服务架构，核心的变化点在于：

1. 每个微服务都可以进行独立的设计开发打包部署
2. 按照微服务进行数据库的拆分
3. 关于大量的业务接口和数据交互：通过上层轻量的API接口实现三个微服务之间的调用和数据交互，例如gRPC接口、rest api接口；不能直接访问对方的数据库，也不能直接从底层的函数接口去走。
   
   那招标中心如何知道基础数据暴露的接口地址？从而实现接口的调用呢？
   ：此处核心内容： 通过服务的注册和发现中心

当基础数据中心有一个供应商的接口暴露出来后，首先是注册到注册中心，招标中心是从注册中心找到这个接口地址，再发起对供应商接口的调用。

所以说微服务是去中心化的架构，也就是说三个微服务之间的接口调用，
接口之间本身是点对点的调用方式，但虽然有注册中心，但是注册中心只是管最基础的控制流，也就是说，即使注册中心宕机了，三个组件之间由于存在地址缓存，仍然可以发起接口调用。
像网络的ARP缓存

前端的应用，有桌面BS，也有APP的形式，APP的形式只能独立打包，但是对于桌面BS的前端，仍然需要独立的打包，实现一个彻底的解耦。

那么问题来了，我还要去调用招标中心提供的API接口，前端有各种主流的前端开发框架，对于APP又有APP端的前端开发方法，那我再前端对API接口调用的时候，前端开发框架五花八门，在前端这里是没有办法植入一个类似于feign这种服务调用的代理组件的，也就是前端调用后端只能通过http的API方式进行调用，所以这里会引入一个东西，叫微服务网关。

也就是说，需要接入注册到微服务网关，通过网关提供一个统一的，http能够访问的出口地址，给前端的功能页面进行调用。

继续提问，为什么有了微服务网关还需要API网关，前端去调用后端的时候，如果仅仅是微服务网关，它的整个流量的请求代理，只能到微服务的这个粒度，也就是比如到招标中心的这个粒度。
但是当你用了API网关的时候，那整个接口流量的代理，是可以到一个个API接口服务的粒度的。这就是微服务网关和API网关最大的一个区别。

在整个微服务架构中，我们经常都在说它是一个完整的去中心化的架构，但是整个微服务架构一涉及到前后端，一涉及到你底层微服务的能力要统一地对外进行开放，那么这个时候必然需要引入微服务网关或者是API网关，而API网关的本质仍然是一个中心化的架构。
当然，随着云原生和微服务的发展，我们可以看到，类似于去中心化的微服务治理，逐渐流行起来，所以说在其流行起来以后，我们可以把API网关本身的流量管控拦截能力，本身API网关的能力也通过sidecar方式下放到一个个微服务的边车端，那么此时，不管是微服务网关还是API网关它剩余的能力，仅仅只剩下了流量的请求转发。那这个时候，你用我们所说的负载均衡的集群，或者直接用kubernetes负载均衡的能力、集群的能力，完全就可以满足需求。

这些就是我们所说的传统的单体架构转到微服务架构以后最最核心的一些关键内容。

学习完毕。

learn from 人月聊IT
以下为视频学习链接人月聊ITbilibili原视频讲解