从零开始学习微服务：如何使用服务路由？

什么是服务路由？我的理解是，服务路由是指服务消费者发起服务调用时，必须按照特定的规则选择服务节点，以满足某些特定的需求。 那么服务路由有哪些应用场景呢？具体规则是什么？ 服务路由的应用场景 根据我的实践经验，服务路由主要有以下应用场景： 群组通话。一般来说，为了保证服务的高可用性，实现异地多活的需求，一项服务往往部署在多个数据中心。出于节省成本的考虑，一些企业可能不仅部署在私有机房，还使用公有云。部署，甚至使用多个公有云部署。服务节点也会根据不同的数据中心划分为不同的组。这时候对于服务消费者来说，选择呼叫哪个组时就必须有相应的路由规则。 灰度发布。在服务上线发布过程中，一般需要先在少量服务节点上发布服务，然后验证功能是否正常。如果正常，则继续扩大发布范围；如果不正常，需要排查问题，解决问题后继续发布。这个过程称为灰度发布，也称为金丝雀部署。 流量切换。在业务线路运营过程中，我们经常会遇到一些不可抗力因素导致业务失败，比如某个机房的光缆被挖掉，或者火灾等事故导致整个机房无法使用。这时就需要按照一定的指令，将原来调用本机房服务的流量切换到其他正常机房。 阅读和写作分离。对于大多数互联网业务来说，读多于写，因此在部署服务时，读和写可以分开部署。所有写接口可以部署在一起，而读接口则部署在另一个节点上。 以上四种应用场景在实际业务中非常常见。服务路由可以通过各种规则来实现。那么服务路由的规则是什么呢？ 服务路由规则 根据我的实践经验，服务路由主要有两种规则：一是条件路由，二是脚本路由。 1.条件路由 条件路由是基于条件表达式的路由规则。下面以条件路由为例，给大家详细讲解一下它的用法。 条件://0.0.0.0/dubbo.test.interfaces.TestService?category=routers&dynamic=true&priority=2&enabled=true&rule=" + URL.encode(" 主机 = 10.20.153.10=> 主机 = 10.20.153.11")这里的“condition://”代表这是一条用条件表达式写的路由规则。具体规则是 主机 = 10.20.153.10 => 主机 = 10.20.153.11 分隔符“=>”前面是服务消费者的匹配条件，后面是服务提供者的过滤条件。当服务消费者节点满足匹配条件时，后续的过滤规则将在服务消费者上执行。那么上面表达式的含义就是IP为“10.20.153.10”的服务消费者都调用IP为“10.20.153.11”的服务提供者节点。 如果服务消费者的匹配条件为空，则表示应用于所有服务消费者，就像下面的表达式一样。 => 主机！= 10.20.153.11 如果服务提供者的过滤条件为空，则表示禁止服务消费者的访问，如下表达式。 主机=10.20.153.10=> 下面我就通过一些Dubbo框架中的条件路由来给大家讲解一下条件路由的具体应用场景。 排除服务节点 => 主机！= 172.22.3.91 一旦线上应用该路由规则，所有服务消费者将无法访问IP为172.22.3.91的服务节点。该路由规则一般用于预发机排除线上流量、移除故障节点的场景。 。 白名单和黑名单功能 主机！= 10.20.153.10,10.20.153.11 => 该路由规则意味着，除了IP地址为10.20.153.10和10.20.153.11的服务消费者外，其他服务消费者都不能发起服务调用。主要用于白名单访问逻辑。例如，一个后台服务只允许某些机器可以访问。在这种情况下，访问权限可以由机器控制。 主机 = 10.20.153.10,10.20.153.11 => 同理，这条路由规则意味着除了IP地址为10.20.153.10和10.20.153.11的服务消费者不能发起服务调用外，其他服务消费者都可以发起服务调用，这就实现了黑名单功能。例如，您在网上经常遇到一些呼叫者无论有意还是无意地进行无理呼叫，从而影响了服务的稳定性，可以通过黑名单功能将其暂时屏蔽。 机房隔离 主机 = 172.22.3.* => 主机 = 172.22.3.*该路由规则意味着只有IP网段为172.22.3.*的服务消费者才能访问同一网段的服务节点。此规则一般适用于部署在多个IDC的业务。理论上，同一IDC内的呼叫性能优于跨IDC的呼叫性能。该规则用于实现同一个IDC的就近访问。 读写分离 方法 = find*,list*,get*,is* => 主机 =172.22.3.94,172.22.3.95 方法 != find*,list*,get*,is* => 主机 = 172.22.3.97,172.22.3.98 该路由规则意味着find*、get*、is*等读方法调用IP地址为172.22.3.94和172.22.3.95的节点，其他写方法调用IP地址为172.22.3.97和172.22.3.98的节点。对于大多数互联网业务来说，读请求往往比写请求大得多，而写请求往往比读请求重要得多。因此需要将读写请求分开，防止异常读请求影响写入。请求，此时可以应用该规则。 2. 脚本路由 脚本路由是基于脚本语言的路由规则。常用的脚本语言有JavaScript、Groovy、JRuby等，下面以下面的脚本路由规则为例，详细给大家讲解一下它的用法。 "script://0.0.0.0/com.foo.BarService?category=routers&dynamic=false&rule=" + URL.encode("（函数路由(调用者) { ... } (调用者))") 这里的“script://”表示这是用脚本语言编写的路由规则。具体规则在脚本语言的route方法实现中定义。例如，下面用JavaScript编写的route()方法的意思是：只有IP为10.20.153.10的服务消费者才能发起服务调用。函数路由(invokers){ var result = new java.util.ArrayList(invokers.size()); for(i =0; i < invokers.size(); i ++){ if("10.20.153.10".equals(invokers.get(i).getUrl().getHost())){ result.add(调用者.get(i));返回结果； }（调用者））； 既然服务路由是通过路由规则实现的，那么服务消费者如何获取路由规则呢？ 如何获取服务路线 根据我的实践经验，获取服务路由的方式主要有以下三种： 本地配置 顾名思义，路由规则存储在服务使用者本地。当服务消费者发起呼叫时，它从本地固定位置读取路由规则，然后根据路由规则选择服务节点发起呼叫。 配置中心管理 这样，所有服务消费者都从配置中心获取路由规则，并由配置中心统一管理。 动态交付 在这种方式中，运维人员或开发人员通常通过服务管理平台修改路由规则。服务治理平台调用配置中心接口，将修改后的路由规则持久化到配置中心。因为服务消费者订阅了路由规则的变化，所以它会从配置中心获取最新的路由规则，并根据最新的路由规则执行。 根据我的实践经验，上述三种方法在实际使用时还是存在一定差异的。 一般来说，业务路由最好存放在配置中心，由配置中心统一管理。在这种情况下，所有服务消费者都不需要在本地管理服务路由，因为大多数服务消费者并不关心服务路由问题，或者不需要了解细节。通过配置中心，将统一的服务路由下发给每个服务消费者，节省通信和管理成本。 但也不排除一些服务消费者有特定的需求，需要定制自己的路由规则。这时候就适合通过本地配置来定制。 动态投递可以理解为一种高级功能，可以动态修改路由规则，在某些业务场景下非常有用。例如，如果某个数据中心出现问题，需要将所有调用该数据中心的服务消费者切换到其他数据中心，那么可以通过动态下发的方式向配置中心下发一条路由规则，将所有调用转移到这个数据。来自中心的请求被迁移到其他地方。当然，这三种方法也可以结合使用。此时服务消费者的优先级是本地配置>动态下发>配置中心管理。 总结 今天给大家讲解一下服务路由的作用。简单来说，就是实现某些调用的特殊需求，比如群组调用、灰度发布、流量切换、读写分离等。当业务规模比较小时，所有服务节点可能会部署在一起，所以服务不需要路由。但随着业务规模的扩大、服务节点的增多，尤其是部署多个数据中心时，按照数据中心或者按照业务核心级别对服务节点进行分组，对于提高服务可用性非常有用。以微博业务为例，有些服务不仅分为核心服务和非核心服务，还分为私有云和公有云所在的不同数据中心。通过这种方式，可以最大限度地减少服务之间的调用。它们都仅限于同一个数据中心，以最大程度地减少跨数据中心的网络延迟、抖动和其他影响的影响。 业务路由是在本地配置还是在配置中心集中管理也取决于具体的业务需求。如果不需要定制，建议将所有路由规则放在配置中心统一存储和管理。动态下发路由规则对于服务管理非常有帮助。当数据中心出现故障时，可以动态切换流量，也可以移除一些故障的服务节点。 思考问题 在实际业务场景中，经常会有这样的需求：某个新功能尚未全面上线之前，会优先考虑一组用户。如果使用服务路由功能，您认为可以做什么？