在线公开课 | 微服务太杂乱难以管理？一站式服务治理平台来袭！

课程概要
如今微服务已成为构建现代云应用的主导模式，它围绕着特定的业务功能，将单个组件分解为独立的服务。但随之而来产生另外的问题：越来越多的系统被拆解成了很多个细胞一样的微服务，如何对微服务进行管理，这成为许多工程师头疼的挑战。

相信很多成熟企业都拥有复杂的研发环境：上百条产品线、上千位开发人员、数千个服务。

服务部署在多个地域的多个机房，各种服务运行环境很多。开发语言繁多，例如京东智联云以Go、C++、Java、Node.js为主，少量的Python和PHP，随着业务线不同使用的技术框架不同。调用协议有rest，有非rest的HTTP等，还有自定义TCP协议的……

如何统一管理？服务治理应运而生。通过服务治理来解决分布式服务和微服务在整体的开发和运行时出现的运维问题，处理服务之间的关系，提供一系列数据依据和工具。

4月21日，技术公开课《六周玩转云原生》第五讲《微服务架构下，服务治理体系的演进历程》由京东云与AI事业部云产品研发部架构师张俊峰为大家详细讲解了服务治理、Spring Cloud微服务架构特点、Service Mesh以及京东智联云在微服务的探索。

以下是精华分享内容，咱们一起来看看：

六周玩转云原生

微服务架构下服务治理体系的演进历程

— 京东云与AI产品研发部架构师 张俊峰 —

1 服务治理演变史

服务治理是随着业务规模的不断扩大，架构设计方案的不断演进逐步衍生出来的一个概念。那么我们根据架构的演进过程了解一下服务治理的出现过程。

一、单体架构

在服务治理的“史前”年代里，不管是界面或是业务处理、数据处理都简单粗暴地放在一个包里，随着业务的增长，给开发维护造成巨大的压力。

二、分层架构

随着业务的快速发展，开发者开始对业务系统进行拆分来解决并发问题，此时系统分为前端和后端，出现了分层架构。其优点是比单层架构降低了耦合性，增加协作性，缺点是重复开发，如果设计能力不足的话，一个接口设计问题还将影响整体系统。

三、分布式架构

在垂直产品基础上进行水平的拆分，抽取出基础来搭建起分布式架构。其优点是提高了代码复用率和提高开发效率，缺点是网状调用、静态配置地址和扩容较复杂。

此时出现“服务治理”的概念，当时这阶段的服务治理是简单的DNS服务发现和负载均衡。

四、SOA架构

此时，AWS研发出新的架构——SOA（面向服务的架构），SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯。

它采用中心化的服务治理，中间通过ESB（企业服务总线）中心化来实现服务注册、负载均衡等服务治理。SOA的优点是应用更容易维护，耦合度更低、扩展性更高。缺点是受ESB影响较大，维护成本很高。

基于此，国内巨头互联网公司采取“去中心化”的优化策略，ESB不再做服务治理调用工作。去中心化的优点是自动服务注册和发现，服务列表自动推送，动态监控服务状态，人为控制服务状态。

五、微服务架构

因为SOA是针对结构化的编程，缺少熔断、灰度等功能。随着微服务架构的出现，提供配置管理、服务限流、链路跟踪等丰富的服务治理功能。不过其缺点是当一套框架来支撑时，可支持的编程语言不足，且通过SDK集成的形式，造成升级困难。

从以上的架构演变过程可以总结出服务治理发展的阶段：：

1、从最初的纯负载均衡形式，以Nginx或者VIP负载均衡为代表，功能比较单一，静态化配置，扩展比较困难。

2、发展到治理逻辑代码单独出现，业务代码和治理逻辑整体耦合，但随着服务增多，维护变得困难。

3、紧接着是治理逻辑独立成代码库，以SDK的方式来提供，但其对多语言支持不足，如果SDK有问题升级较困难。

那么下一代服务治理架构将是怎样的？我们以目前应用最广泛的Springcloud框架为例，来了解一下从传统架构到云原生架构下服务治理方式的改变。

2 服务治理上“云”：从传统框架到云原生

Spring Cloud利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，提供服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等部署。

图注：Spring Cloud整体服务核心框架

Spring Cloud的优点有：针对外部用户的访问提供了微服务网关；针对服务治理，提供服务发现和配置中心，包括监控体系和容错等体系；针对底层中间件、数据层，提供消息总线、大数据驱动等功能。

Spring Cloud在物理机或虚拟机下的服务治理部署是：当一个请求进来时，先经过网关层，微服务网关从注册中心获取到请求要访问的微服务实例地址，微服务实例启动时从配置中心获取相关配置，然后把本身的服务地址等参数写入到注册中心，微服务通过注册中心获取业务依赖的其他微服务的地址进行调用。然后发现用户的注册中心，在配置中心进行公共配置。

这种传统架构会存在一些不足之处：

1、Spring Cloud不支持灰度发布；

2、服务网关：不支持动态路由，容易突破业务体系，需二次开发；

3、服务跟踪：依靠第三方支持链路跟踪，对APM的支持也比较欠缺；

4、UI分散且简陋；

5、只支持Java，不支持异构系统；

6、代码入侵也严重，以后Spring Cloud V1升级到Spring Cloud V2时较困难。

虽然有以上问题，Spring Cloud提供了专门的spring-cloud-kubernetes项目和K8S集成，提供与代码编程无缝结合的灵活方式也许会增添竞争力。Springcloud部署到K8S环境中后，需要把原来的依赖替换为spring-cloud-kubernetes一整套：

1、微服务网关被K8S提供的ingress代替；

2、服务数据保存在K8S集群的ETCD中，注册发现通过K8S的APIServer提供；

3、配置中心换成了K8S的ConfigMap。

尽管如此，Spring Cloud在K8S下的服务治理仍存在不足：一是不支持异构多语言；二是框架升级很困难；三UI还是原来的Spring Cloud。

为了解决当前微服务治理上存在的问题，新的服务治理架构——把服务治理代码独立成进程，应允而生。这个新的服务治理架构我们称之为Service Mesh。它将整体服务代码独立成一套服务，将业务代码和治理逻辑做了整体的分离，如此一来，让升级变得简单。

3 Service Mesh：业务和治理代码分层

Service Mesh是一个专用的基础设施层，旨在“在微服务架构中实现可靠、快速和安全的服务间调用”。它不是一个“服务”的网格，而是一个“代理”的网格，服务可以插入这个代理，从而使网络抽象化。Service Mesh 的本质是提供应用间的流量和安全性管理以及可观察性。

Service Mesh有四大特点：应用程序间通讯的中间层、轻量级网络代理、应用程序无感知、解耦应用程序和服务治理。

如此一来，Service Mesh将业务模块和服务治理分开。

从上图中我们看到，控制面和数据面分离，应用在部署的时候，每个应用附带一个Side Car，这个Side Car是拦截每一个应用对外请求的。同时控制面的服务治理策略下到Side Car中具体的执行，这样的话，即使业务模块升级和服务治理的升级也能互不影响的，还能动态调整服务治理的规则和策略。

从Service Mesh的结构和特点，我们可以总结出其对于服务治理的理念：

1、微服务治理与业务逻辑解耦：把大部分SDK能力从应用中剥离出来，并拆解为独立进程，以 sidecar 的模式进行部署。

2、异构系统的统一治理：方便多语言的实施，解锁升级带来的困难。

3、价值：

（1）可观察性：服务网格捕获诸如来源、目的地、协议、URL、状态码、延迟、持续时间等线路数据；

（2）流量控制：为服务提供智能路由、超时重试、熔断、故障注入、流量镜像等各种控制能力。

（3）安全性高：服务的认证、服务间通讯的加密、安全相关策略的强制执行；

（4）健壮性：支持故障注入，对于容灾和故障演练等健壮性检验帮助巨大。

我们以Service Mesh的杰出代表Istio为例来聊聊最新的服务治理的架构，它对Service Mesh完全支持，架构清晰，拆分数据面、控制面；拥有通信、安全、控制、观察等功能，实现开放，且插件化，多种可选实现。

Istio可结合K8S使用，K8S提供服务生命周期的管理，Istio在K8S之上通过服务治理的整体的功能的实现。

Istio的服务发现和负载均衡功能

图注：Istio的服务发现和负载均衡功能

Pilot 从K8S平台获取服务发现数据，并提供统一的服务发现接口；Envoy 从Pilot获取服务数据来实现服务发现，动态更新负载均衡池；然后根据负载均衡算法选择一个实例转发请求。

它提供的负载均衡算法有三大类：轮询、随即和最小连接数的负载均衡算法。

Istio的服务熔断

服务熔断由两种形式提供：

一是连接池管理：请求不超过配置的最大连接数时可以请求调用，一旦超过配置的阈值时在请求时被拒绝，以此来保证整个服务正常运行。

二是异常点的检查，当允许调用的错误数超过一个阈值的时候，后端实例就会被移除掉，这样在负载均衡合并列表时把它去掉，不再调用到具体的实例。例如，HTTP是连续返回5xx错误，TCP是连续出现连接超时，会被踢出服务池。但是踢除后有恢复检查机制，如果能重新连接上或者重新调用，就能加到可用列表里，如果继续出错的话，则继续踢出，重复整体的过程。

图注：Istio服务熔断 VS Hystrix

Istio的灰度发布

Istio提供了灰度发布的两种形式，一种是基于流量比；二是基于请求内容。

Istio的故障注入

通过申请一个YAML来实现故障注入，包括httpCode故障、超时故障等。

Istio的安全功能

安全功能的实现涉及到四个组件：第一个是Citadel，用于密钥和证书的管理；第二是Proxy，实现客户端与服务器端安全通信；第三是Pilot，将授权策略和安全命名信息分发给代理；第四是Mixer，校验授权和审计。

尽管Istio整体设计较先进，但在大规模落地时存在一些挑战：

一是线上的挑战——管理规模和性能，从管理规模上来讲，还没有经过大规模的场景验证。从性能方面来说，多了一个Envoy中间层，在网络路径和资源消耗上都会有性能损耗。

二是稳定性、可靠性需要提升，在实践过程中遇到很多Bug。

三是微服务体系迁移的挑战，现有的体系迁到Istio里的话，怎么最大程度降低代码的修改来实现迁移。

四是网格内外体系的互通，Service Mesh或者Istio不可能全部业务全部迁进去，这对整体的应用有很大风险，需保证网格内外应用正常访问；Istio与K8S是强关联，对其他平台的支持还需要进一步的完善，比如对虚拟机、裸金属或者其他容器平台。

4 Service Mesh的难题，京东智联云来解！

如上文所说，京东智联云内部开发环境复杂，所以在做服务治理时，京东智联云有自己的预期：

• 打造的服务治理框架能满足各团队的多种服务治理需求
• 尽量减少对产品线代码层面的改动
• 尽量减少对产品线调用方式的改动
• 尽量减少对产品线DevOps流程的变更
• 框架需要能满足京东智联云每年10+倍的业务量增长
• 尽量控制服务框架的投入和风险

京东智联云部署最终实现的框架有容器、虚拟机、云翼等服务；能跨地域、多可用区；支持多种网络，包括经典网络+多个vpc网络；超大型的服务规模。

部署应用

京东智联云先是依赖于云翼部署服务，部署后服务的注册数据在当前的服务树中进行整体注册，然后把Istio控制面板部署在云翼里，整体使用的是原有的DevOps系统。另外，基于云翼的agent来保证Envoy的存活，且虚拟机是单对单的服务。

服务发现过程

1、先是部署完一个服务后，在服务树里记录下它的信息，实例信息更新到DNS里。

2、在服务调用时，通过DNS地址获取服务的地址

3、发起调用时请求被劫持给Envoy。

4、Envoy获取服务列表和策略。

5、根据策略得到实际调用地址。

服务降级

服务降级是指Envoy出现异常的情况，适配性的降级过程。当Envoy异常时，移除一些转化规则；服务调用的过程中还保持原有的实例信息更新到Service当中，根据Service信息也就是DNS信息获得服务地址，DNS发起整体调用，拿到调用结果。

扩展安全功能

京东智联云研发token服务并集成到Envoy中；并研发黑白名单插件，方便服务方更细致的定义自己的安全策略。

扩展调用链功能

扩展调用链功能是服务治理过程中服务关系疏离的一个必不可少的功能。系统在Envoy当中集成调用链的采集和输出。采用的是jaeger形式，把数据采集后放在ES中，依赖图谱分析服务，让用户研发人员能看到调用关系及耗时。

网格内外互通

京东智联云研发了一套Istio的网关，来支持网关的互通。当一个请求过来时，通过网关放到已知的网格内。在把这个请求通过Envoy进行服务的发现和调用的过程，如果在网格内的话，通过纯网格的调用下发到Envoy。如果是网格内找不到这个服务就会打到Istio网关，Istio直接调用网格外的服务来适配，这是网格内外的互通。

跨地域

Istio是不支持跨地域的，但京东智联云完美地解决这问题。通过建立核心集群，华北跨3az集群部署。每个机房独立的部署一套Istiod的服务，多级缓存来提高性能。服务发现是按照优先级来分配，在一个服务调用另外一个服务过程中，首先是本az的调用，如果本az没有的情况下，在当前区域进行调用，再是跨区域的调用，来实现跨地域。

最后，告诉大家一个好消息，京东智联云通过内部验证相关的功能，如今向公有云输出，公有云已具备了网格的基本功能，正在尝试向大规模云上输出。

云原生的时代已来，而你，也将成为这个新时代的构建者之一！

点击【阅读】获取更多相关课程视频！