Micro -Service不能没有门户，就像Java程序员不能没有想法和Eclipse一样。为什么？
网关对于微服务如此重要的原因是以下原因：
您知道，采用微服务体系结构本身的系统由许多独立服务单元组合在一起。要调用该系统，必须通过系统提供的各种开放函数API来实现客户端。
问题到了，这些API放在哪里？是否可以将其直接放在构成系统的服务单元上？
例如，在一组电子商务系统中，与订单相关的API放置在订单服务的服务单位上；风险控制服务的API放置在风险控制服务的服务单位上。
好的，我们假设有这样的场景，并且用户想检查有关此E -Commerce系统的产品详细信息。然后，此产品详细信息的此操作可能是：
可以看出，仅仅是这样的产品观看操作，您就可以称呼许多服务的API。
如果所有这些API都散布在各种服务单元上供客户致电，那么一个简单的操作（例如查看产品）可能需要远程访问几次甚至超过十二台服务器。
Micro -Service员工本人非常关注API的粒度，也就是说，从商品服务中调用产品信息可能足以获取足够的数据。
通过这种方式，客户端需要更多的次数访问服务器，并且可能不足以进行超过十几次。
对服务器的多次访问将大大延迟客户端的接口响应时间，这是非常不现实的。
因此，将API放在与各种业务有关的服务单元上，似乎问题很大。
那么，为什么网关的引入可以解决这个问题呢？
由于网关的引入等同于在客户端和微服务之间添加一层隔离。这样，当客户端开展业务时，您只需要访问网关。然后，其余的物质将由网关在同一服务室中分别访问，然后封装在网关中获得的数据并将其返回到客户端。
在微服务系统中，除了必要的业务功能外，还必须为该系统自己的强大和安全性以及微服务本身的管理而引入一些非企业的功能。对于这些非企业和重要功能，我们集体指的是边缘函数。
以电子商务系统为例，让我们看一些重要的边缘功能。
假设由于我们进行了非常大的促销活动，流量太大，并且系统无法携带。这次，为了确保系统本身的稳定性，我们需要消化一些无法携带的流量通过各种方式。有三种一般方法：
可以看出，系统中最合适的部分保证了当前限制，降级和保险丝等策略，应该是有一个集中的请求入口，就像在古代一样，普通百姓需要越过城市大门。
当系统是问题时，只需在此入口点进行相应的操作即可。
在电子商务系统中，有许多特殊场景接口需要严格限制。
例如，付款接口需要身份验证和权限控制。在另一个示例中，对于系统访问，有时外国人无法访问国内网站，这需要限制对客户的访问，因此系统还需要认证和授权功能。
这种认证和授权也是最适合要求的集中入口处的认证。
还记得我们上面提到的网关的API吗？我们只需要为这些API制作相应的权威设置。当要求访问特殊方案接口时，我们必须通过API访问它。因此，对接口的访问本质上仅限于特定的API，因此将其放入网关不合适。
实际上，有时我们需要使用在线交通镜将其转发到灰色环境中。这些镜子的流量可以用于小规模的测试中，并且可以更好地评估系统可以携带的最大吞吐量。由于该系统需要进行统一的转移条目。
可以看出，无论是保证策略，认证授权还是系统所需的流量转移，都应将其放在统一的请求入口上以获得最佳实施。网关恰巧扮演了这样的统一请求的角色入口。
因此，在微服务中，Lin Lin的经文功能通常通过插头的形式整合在API网关中。
在使用微服务的早期，后端变化通常非常频繁。
经常发生变化的原因有很多，例如业务领域的不适当划分。就像业务模块迅速扩展一样，它可能会导致后端微服务发生严重变化。
在这种情况下，如果没有网关，则可能需要随着后端的更改而被迫更改客户。
例如，在电子商务系统中，我们很可能在早期的风险控制服务中很小。随着业务的发展，风险控制服务变得越来越大。目前，风险控制服务可能被分解为更详细的服务，例如决策引擎和分析中心。
在电子商务中，风险控制通常是订购和付款的必要预处，如果没有门户来分开客户和微服务，客户直接处理风险控制服务，那么风险控制服务将不稳定，并且API的更改自然会导致更改以调用API客户端代码。
使用网关，情况会好得多。当风险控制服务本身经常变化时，我们只需要更改网关的代码。服务器代码的升级要比客户端代码升级要容易得多。
原来的;https://juejin.cn/post/7111238246947880967