转载

云原生时代，微服务到底应该怎么玩儿？

在微服务诞生之初，并没有太多方案的选择：选一个注册中心用来做服务注册和发现，通过客户端SDK进行负载均衡和容错，再搭配上日志、监控、调用链全套观测手段，一套微服务架构便建立起来了。

作为最流行的业务开发语言，Java体系里诞生了很多微服务架构，例如Spring Cloud。使用Spring Cloud，Spring技术栈的开发人员可以快速的开发和管理微服务，丰富的功能让其他语言体系的开发者们羡慕不已。

在云原生时代，Kubernetes快速普及，除了解决微服务所需要的应用编排、伸缩、保活等功能外，Kubernetes里本身还带了服务发现、配置管理、负载均衡和网关。既然这样，那么是否就可以不再注重注册中心和服务治理框架，只基于Kubernetes构建微服务系统呢？

很多公司进行了这方面的尝试，尝试后发现从治理功能丰富度、大规模集群效率等方面，还是有不太满意的地方。于是，后来又诞生了治理功能更为丰富的服务网格架构，让Kubernetes的服务治理能力极大增强，这些项目很快便得到了大范围的关注，例如Istio。

那么，在云原生时代，我们的微服务体系到底应该怎么建设和维护呢？

Kubernetes良好的应用编排能力，使其成为微服务部署、伸缩、管理的最佳工具。假如是为新增业务做技术选型，建议都直接使用Kubernetes和容器来部署和管理应用，而不是还使用物理服务器或者虚拟机。而关于服务治理，目前会有如下选择：

只使用Kubernetes：

Kubernetes里本身具备服务发现、配置管理、负载均衡和网关，这使得看起来只使用Kubernetes就可以把微服务系统搭建起来。不过，这种方式存在问题。例如：

流量治理能力不足——缺乏熔断能力，没有灰度控制能力；
大规模使用时的性能问题——基于Kubernetes Service的服务发现过程需要经过Iptables或IPVS的查找过程，集群规模大时性能影响会比较明显。

另外，很多观测功能也都需要一定的代码集成才可以发挥作用。

使用Kubernetes部署+Spring Cloud（或Dubbo等）服务治理：

这种方式是笔者认为目前最成熟的一种方式，可以充分利用Kubernetes和Spring Cloud（或Dubbo等）自身的优点。这种方式性能好、功能完备，也已经有大量稳定的线上案例。不过这里面也会涉及到一个问题：语言和框架的依赖——Java以外的其他语言都缺乏完备的服务治理框架。

使用Kubernetes部署+Istio（或Linkerd等）服务治理：

服务网格是这两年赢得最多关注的方式，彻底把业务和服务治理逻辑切分开。这种方式没有语言和框架依赖，应用不用修改代码逻辑，只要接入网格就可以使用网格提供的全套流量管理、策略管理、观测能力和安全能力。京东云内部已经有上百个线上服务运行在服务网格里，利用网格技术减少了这些服务接入安全、观测、流量管理等功能的接入成本，通过此过程也积累了很多优化和运维经验。不过，网格架构的复杂性，和经过两层网络代理引入的延迟，仍然是不可回避的问题。

下面让我们再详细看一下后两种方式。

Kubernetes部署+Spring Cloud服务治理

对于Java业务研发工程师而言，采用这种方式的感觉是Spring Cloud太“简单”了，而Kubernetes太“难”了。

Spring Cloud很“简单”。标准的Spring Boot开发方式，引入几个包，服务发现、负载均衡、熔断就都有了。业务研发工程师便开开心心拆分服务去了。等拆完服务真上线跑一段时间，才发现Spring Cloud太难了。监控线上系统是否存在异常这个工作，比之前监控单体服务复杂好几个量级。一旦线上有点问题，想查一查，都不知道该上哪个服务去查。调用链看起来很强大，用起来又不那么容易。还可能出现过这样的尴尬：老板听说上完了微服务：老板听说上完了微服务，问以后上线是不是可以像互联网公司那样灰度发布了，结果才发现Spring Cloud官方竟然没提供这个能力。

Kubernetes很“难”。一堆概念，什么Pod、CNI、Replication Controller、Persistent Volume…而且，随便搞个事情都需要写一长串yaml，各种事情还都用命令行操作。但实际上，Kubernetes使应用交付大大简化了。以前最复杂的服务依赖管理、弹性伸缩、故障恢复等能力，Kubernetes都提供了支持。而且是你只用声明你期望达到什么目标，Kubernetes就能自动帮你完成这背后的各种具体操作步骤。

因此，如果要采用这种方案，这里会有一些建议：