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

在微服务诞生之初，并无太多方案的选择：选一个注册中心用来作服务注册和发现，经过客户端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了解如何快速的创建服务网格系统并快速体验。

欢迎点击“京东云”了解更多精彩内容