微服务治理的前世今生与未来
余楠，就职于ThoughtWorks。
转载请注明出处
前世
微服务治理，我们面临的第一个问题就是服务发现与服务注册。当一个服务有多个实例时，它的消费者如何知道自己该访问哪一个实例?
服务A如何知道该访问服务B的哪一个实例？
最简单也最传统的方式就是在所有实例前放一个负载均衡器，服务的消费者只需要知道服务的唯一入口也就是这个负载均衡器的地址即可，服务有多少个实例，对于消费者来说是黑盒子。
通过负载均衡器与服务提供方通讯
在云服务已经十分普及的当下，放一个负载均衡器在所有实例前面并且根据实例的负载自动启动或关闭实例不费吹灰之力。不过这种方案有一个潜在的缺陷，即这个负载均衡器是一个单点，它有性能上限，当你的流量超过负载均衡器的上限时，你将无法通过横向扩展来满足的你的流量需求。为什么说它是一个潜在的缺陷，以AWS的ALB为例，绝大多数微服务终其一生都不会达到这个性能上限。
这种服务提供方自己做负载均衡的方式叫“服务端负载均衡”，以下两种情况可能导致这种方案不可取。
- 没有使用云，导致不能以低廉的成本放置一个负载均衡器到所有实例前。
- 微服务的流量就是很大，负载均衡器成为性能瓶颈。
今生
既然有“服务端负载均衡”，那么与之对应的就有“客户端负载均衡”
通过注册中心，消费端可以获取服务端实例的具体信息并自行决定访问哪一个实例。
所有服务都将自己注册到注册中心，之后任何服务都可以通过注册中心找到其它服务。
在这种方案下，没有了单点负载均衡器，消费端实例自行决定访问服务端的具体哪一个实例，服务端的横向扩展能力得到了增强。这种方案很好的解决了上面两个问题，Spring Cloud在服务注册服务发现这部分就是这种方案。微服务治理不仅仅只有服务注册服务发现，还有诸如服务雪崩等一系列需要关注的问题。Spring Cloud几乎提供了全套的解决方案，并且在当下非常流行。这种方案也有弊端，我们通过Spring Cloud中服务发现和断路器应用的代码来感受一下。
package hello;
import org.springframework.cloud.client.loadbalancer.LoadBalanced;
import org.springframework.cloud.loadbalancer.annotation.LoadBalancerClient;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.reactive.function.client.WebClient;
@Configuration
@LoadBalancerClient(name = "say-hello", configuration = SayHelloConfiguration.class)
public class WebClientConfig {
@LoadBalanced
@Bean
WebClient.Builder webClientBuilder() {
return WebClient.builder();
}
}
代码摘抄自Spring官网：Client-Side Load-Balancing with Spring Cloud LoadBalancer
上面的代码展示了如何构建一个可以做负载均衡的WebClient。
package com.example.circuitbreakerreading;
import com.netflix.hystrix.contrib.javanica.annotation.HystrixCommand;
import org.springframework.stereotype.Service;
import org.springframework.web.client.RestTemplate;
import java.net.URI;
@Service
public class BookService {
private final RestTemplate restTemplate;
public BookService(RestTemplate rest) {
this.restTemplate = rest;
}
@HystrixCommand(fallbackMethod = "reliable")
public String readingList() {
URI uri = URI.create("http://localhost:8090/recommended");
return this.restTemplate.getForObject(uri, String.class);
}
public String reliable() {
return "Cloud Native Java (O'Reilly)";
}
}
代码摘抄自Spring官网：Circuit Breaker
上面的代码展示了如何将断路器应用于对服务端的网络请求中。
我们可以明显的看到，针对服务治理的事宜，都要在应用层写一些代码，虽然代码很简单，简单到只是几个注解，但还是导致了应用层要关注自己所需处理的业务以外的内容。如果我只是一个对图片做处理，做完后通知下游的服务，我为什么要关注服务发现和断路器这样的事？为什么要在构建服务时，思考微服务治理相关的事宜？而且需要关注的问题可能更多。
未来
如果想让微服务纯净到只关注自己的业务，那么微服务治理的相关事宜势必得委托出去，怎么办呢？找个代理来做事。
代理负责微服务治理的相关事宜
所有服务的所有实例只通过代理对外通讯，同时，所有服务的所有实例只通过代理接收外界的消息。我们把这个代理叫做微服务的Sidecar，有了这个Sidecar，我们的微服务就可以纯净到只处理业务内容了。通过这种架构组建起来的系统，结构图如下，我们把它叫Service Mesh。
图片取自Red Hat - What's a service mesh?
(https://www.redhat.com/en/topics/microservices/what-is-a-service-mesh)
我们以Service Mesh的具体实现方案Istio为例，来看一下在Service Mesh下如何应用断路器。下面的代码片段将目标服务工作负载的并发连接数限制为 100。与Spring Cloud的方案相比最明显的区别是，这段代码没有在应用层，而是在基础设施层。
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: reviews
spec:
host: reviews
subsets:
- name: v1
labels:
version: v1
trafficPolicy:
connectionPool:
tcp:
maxConnections: 100
代码摘抄自Istio官网：Circuit Breakers
我们再看一下基于Istio的Service Mesh下，如何实现在网络出错时重试，同样是在基础设施层做配置。
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: ratings
spec:
hosts:
- ratings
http:
- route:
- destination:
host: ratings
subset: v1
retries:
attempts: 3
perTryTimeout: 2s
代码摘抄自Istio官网：Retries
Service Mesh的理念是，应用与基础设施分离，在Service Mesh架构下做应用开发，关注点可以完全放在应用实现上，几乎不需要知道微服务还需要治理。
这节的标题是“未来”，但Service Mesh的概念从提出到现在已经有些年头了，只是没有被大面积使用。这里面有解决方案成熟度的原因，也有各团队对新事物可控性的担忧。随着解决方案的成熟度越来越高，使用Service Mesh的组织越来越多，Service Mesh几乎正在成为事实标准。
对开发人员带来的改变
基于Spring Cloud的方案，微服务治理相关的事宜都在应用层，导致应用层的复杂度相对较高。解决在应用开发时遇到的这种“复杂”问题，一定程度上是开发人员体现技术能力的舞台。当这种“复杂”问题不存在时，开发人员的舞台在哪里？
我们常讲，开发人员不能把自己的目光只锁定在自己当前的工作内容中，并且，绝大多数开发人员的职业目标是架构师，那么开发人员就必须得从架构层面来看自己的系统。
什么是架构？如果你在网上搜这个问题，你得到的永远是一些开放式的答案。我个人比较喜欢Martin Follower的博客中，Ralph Johnson的答案：“Architecture is about the important stuff. Whatever that is”。https://martinfowler.com/architecture/
余楠，就职于ThoughtWorks。
转载请注明出处
