为什么需要微服务
对于传统的服务，从表现层来看，它们的关系并不会十分的紧密，如：一个服务拥有采购层，基础层与招标层，从表现层看，三者是独立存在的，而当进入到逻辑层时，三者便会表现得密不可分，而它们三者又会指向同一个数据库，这样的高解耦的结构对于需求设计开发时时比较的不利的。因此，我们就需要将各个服务打散成各个颗粒，使得每个单位都能进行独立的开发测试部署交付，而这种将各个服务打散的服务便是微服务。
微服务
相对于一般的服务，微服务将各个服务分隔开，即招标微服务，基础微服务，采购微服务，三者相对独立，包括三个服务的数据库也是独立开来的。
微服务的数据调用
由于微服务使得各个服务的独立，因此各个服务直接就不再能使用高耦合的方式进行数据的调用，此时，我们可以使用GRPC，rest API的接口进行数据的调用。这时便会出现各个服务直接要如何得到其他服务暴露的接口的地址这时候就需要使用服务的注册和发现中心。
服务的注册和发现中心
当某一个服务的接口暴露出来以后，他首先会将这个接口注册到注册中心，而当其他服务要进行调用的时候，该服务便会去到注册中心去寻找所需要的服务的接口，然后再根据这个接口对目标服务发起调用。
要注意的是，由于微服务是一个去中心化的结构方式，因此这个注册中心的作用仅仅只是作为一个控制的中心，即使这个注册中心遇到一些事故发生了宕机，对于其下的各个微服务也并没没有太大的影响，因为在各个微服务之间还存在着一些缓存，这些缓存可以使得各个微服务之间还能继续进行调用。
前端与后端之间的调用
对于后端各个服务直接的调用，除了需要目标服务的rest API的接口，也同时需要在发起端设置诸如feign的API接口对发出数据进行一个包装处理。然而，对于前端，由于前端开发框架的不统一，使得我们不能对其植入一个统一的Feign接口而是只能使用HTTP，此时，我们必须使用一个 微服务网关 来统一的提供一个统一的出口的地址，但是若是使用微服务网关，其流量也只能到达微服务的层面而不能到达API的层面，因此，此时便可以使用 API网关 使得前端的流量能到达API的层面。
