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

在微服务诞生之初，并没有太多方案的选择：选一个注册中心用来做服务注册和发现，通过客户端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就能自动帮你完成这背后的各种具体操作步骤。

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

• 先把整套部署、治理、观测系统建设完善之后再去做微服务拆分；

• 利用专门的团队或者直接利用云服务完成整套系统的建设和运维；

• 系统建设完善后，业务运维尽量交给业务研发自己进行。

为了使业务研发工程师能更容易地使用Kubernetes和Spring Cloud构建微服务系统。 京东云微服务平台产品做了下面这些改进：

• 一个平台，全界面操作，可以完成整套部署、治理、观测等线上运维工作；

• 具备日志、监控、调用链、依赖图谱等全角度观测能力；

• 屏蔽Kubernetes底层技术细节，托管注册中心、配置中心、调用链分析等后端服务，让研发工程师的关注点可以回归业务本身；

• 扩展标准Spring Cloud能力，增加路由治理和服务鉴权功能，可以更精确的控制调用。

点击 【阅读原文】 查看微服务平台上如何通过K8S管理Spring Cloud应用。

Kubernetes部署+Istio服务治理

对于业务研发工程师而言，如果Kubernetes已经很难，那么Istio就更难了。 Istio的难主要体现在如下方面。

• 概念复杂：又是很多新概念，Virtual Service、Destination Rule、Subset、Service Entry… …

• 架构复杂：包含太多的系统组件，Pilot、Mixer、Galley、Security、Gateways、Kiali… …组件之间的关系又很复杂。

• 保证稳定性困难：社区版本发布频率快，每个版本都有不少稳定性问题。如果线上出现问题，等下一版解决吧等不起，自己改吧又太复杂不知道该怎么改。

如果要采用服务网格方案，这里会有一些建议：

• 先做完微服务化和容器化之后再考虑引入服务网格技术。不要因为网格没有架构依赖，想通过网格解决十几年前的大型单体应用的服务治理问题；

• 利用专门的团队或者直接利用云服务完成整套系统的建设和运维；

• 先从访问量不大的边缘系统尝试网格，延迟敏感的应用慎用网格。

为了使Istio服务网格技术能更容易落地，京东云的云服务网格产品做了如下改进：

• 建立完备的测试系统，可以通过长时间实际业务的压测及时发现版本问题并及时优化和回归，保证Istio版本的稳定性。

• 界面上可以通过几个简单配置后自动完成安装、升级等复杂操作。

• 对Istio的复杂概念和使用过程进行了简化，可以更容易的使用网格的各种功能。

点击 https://docs.jdcloud.com/cn/mesh/basic-example 了解如何快速的建立服务网格系统并快速体验。