微服务离不开网关，就像Java程序员离不开IDEA和Eclipse一样。为什么？网关之所以对微服务如此重要，主要有以下几个原因：1、要解决API放在哪里的问题，必须知道采用微服务架构的系统本身就是由许多独立的服务单元组成的。但是，如果客户端想要调用系统，则必须通过系统提供的各种开放API来实现。问题来了，这些API应该放在哪里呢？直接放在组成系统的服务单元上可以吗？例如，在电子商务系统中，订单相关的API应该放在构成订单服务的服务单元上；风控服务的API放在构成风控服务的服务单元上。好吧，假设有一个场景，用户想在这个电子商务系统上查看产品详情。然后，可以进行查看商品详情的操作：调用商品服务API获取商品描述调用评价服务API获取相关评价调用商户服务API获取商家信息调用礼券服务API获取相关礼券...可以看到，仅仅这样一个商品查看操作，可能会调用很多服务的API。如果将这些API全部分发到各个服务单元供客户端调用，那么对于一个简单的查看商品的操作，客户端可能需要远程访问服务器数次甚至十几次。微服务也很注重把API的粒度划分的很细。也就是说，可以从商品服务中调用商品信息。商品服务调用一次是不够的，很可能需要多次调用商品服务的不同API。,以获得足够的数据。这样，客户端需要访问服务器的次数就更多了，可能十几次还不够，要几十次。这种多次访问服务器的行为会大大延迟客户端界面的响应时间，这是很不现实的。所以，把API放到各种业务相关的服务单元上，似乎是个大问题。那为什么引入网关就可以解决这个问题呢？因为引入网关相当于在客户端和微服务之间加了一层隔离。通常网关本身会和各个业务单位在同一个机房??，这样客户端在进行业务操作时，只需要访问一次网关即可。然后剩下的，网关会在同一个机房??分别访问不同的服务，然后把获取到的数据统一在网关里面，封装起来，返回给客户端。2.解决边缘功能集成问题在由微服务组成的系统中，除了必要的业务功能外，为了系统本身的健壮性和安全性，以及对微服务的管理，还必须引入一些非业务功能。微服务本身。对于这些非业务但非常重要的功能，我们统称为边缘功能。还是以电商系统为例，来看一些重要的边缘功能。假设因为我们有一个非常大的促销活动，流量太大，系统无法承受。这个时候，为了保证系统本身的稳定性，我们需要通过各种方式来消化一些无法承载的流量。一般的方法有以下三种：限流：使用令牌桶等算法，在系统外部阻断一些额外的流量，不允许其访问。降级：由于系统可能已经过载，此时，我们放弃处理一些服务和页面请求或者简单处理，比如直接返回错误报告。熔断：有时系统过载或线路有bug，降级也解决不了问题。比如缓存失效，大量请求频繁访问数据库，而这种频繁访问数据库可能会造成大量的IO操作，进而影响数据库所在的操作系统。同时，这个操作系统的其他重要服务也受到直接影响。对于这种连锁反应，我们称之为雪崩。为了防止雪崩，我们将坚决停止因缓存失效导致数据库被频繁访问的服务。这是断路器。由此可见，限流、降级、断路器等系统保护策略最适合的地方应该是有一个集中的请求入口点，就像古代普通人进城要经过城门一样城市。当系统出现问题时，只要在这个入口点做相应的操作即可。限流，直接在这个入口点限制后续的请求。降级，直接在这个入口判断请求要访问的服务或页面，直接报错。Fuse，直接在这个入口点，断开所有访问特定服务的请求，然后将后续对特定服务的访问从门口堵住。在电商系统中，有很多针对特殊场景的接口需要严格限制。比如支付接口，访问它需要鉴权和权限控制。再比如，对于系统的访问，有时候国外的用户不能访问国内的网站，这就需要限制客户端的访问IP，所以系统也需要认证和授权的功能。那么这种认证授权也是最适合放在请求的一个集中入口统一实现的。还记得我们上面提到的网关API的统一存储吗？我们只需要为这些API设置相应的权限即可。请求访问特殊场景接口时，必须通过API访问。所以，限制访问一个接口，本质上就是对具体的API进行限制，所以最好放在网关上。现实中，我们有时需要对线上流量进行镜像，转发到灰度环境。使用这些镜像流量可以用于小规模测试，更好的评估系统可以承载的最大吞吐量。因此，系统需要有一个统一的导流入口。由此可见，无论是系统需要的安全策略、认证授权，还是流量分发等功能，都应该放在统一的请求入口处，才能得到最好的实现。网关只是承担了这样一个统一请求入口的角色。因此，对于微服务而言，各种边缘功能往往以插件的形式集成在API网关中。3.解耦了一组客户端和后端微服务项目。在使用微服务模型的早期，后端往往变化非常频繁。频繁变更的原因有很多，比如业务领域划分不当，或者某个业务模块快速扩容，可能导致后端微服务发生剧变。在这种情况下，如果没有网关，很可能会出现需要随着后端的变化而强制改变客户端的情况。比如在电商系统中，我们前期很可能把风控服务做的非常小。随着业务的发展，风控服务越来越大。此时，风控服务可能会分解为决策引擎、分析中心等越来越细化的服务。在电子商务中，风控往往是下单、支付等操作的必要前置操作。如果没有网关分离客户端和微服务，客户端直接和风控服务打交道，那么风控服务的拆分必然导致API不稳定。API的变化自然会导致调用API的客户端代码发生变化。有了网关，情况就好多了。当风控服务本身变化频繁时，我们只需要改改网关的代码即可。服务器代码升级比客户端代码升级容易得多。本文转载自微信公众号“思源外”，可通过以下二维码关注。转载本文请联系思源外公众号。
