来电科技微服务治理落地实践
内容介绍：
一、云原生微服务的挑战和趋势
二、来电科技微服务治理落地挑战
三、来电科技微服务治理的选择
四、最佳实践
一、云原生微服务的挑战和趋势
1.微服务架构总览
最下层的是服务框架：Dubbo、Spring Cloud、多语言微服务
如果应用只有四五个节点或者只有三个服务就不需要多语言微服务，只需要用开元的Dubbo和Spring Cloud就可以。但当服务规模开始扩大，微服务的规模也会变得复杂，这时为了让服务性能更稳定就开始进行服务治理。
服务治理：无损下线、服务容错、服务路由、服务鉴权、限流降级
可观测性：应用监控、链路追踪、日志管理、应用诊断
相关的是API管理、服务压测、分布式事务、分布式调度、服务注册发现、服务配置、负载均衡、API网关
为了更好的管理服务，我们还需要DevOps系统
DevOps：服务元数据、服务测试、服务mock、持续集成、IDE插件
还可以通过IDE的插件做到端云互联等一些便捷开发的模式。
2.微服务在云原生下的挑战
随着K8s的流行，K8s已经成为云原生下适时的标准。在这种场景下，传统的微服务会遇到很多问题，下面从三个方面讲述：
（1）在效率方面
白天流量高峰期发布，流量不报错
云边端一体化开发部署联调
服务治理体系强依赖SDK升级
K8s下应用IP的不确定、导致服务治理规则的失效
（2）在稳定方面
业务高可用、多可用区部署
同城/异地容灾，业务多活
微服务需要更安全、更可信的环境
（3）在成本方面
应用迁移上云成本很高
极致、灵活的弹性（流量高峰时自动扩容，流量低谷时自动缩容，保证扩容、缩容过程中的流量无损）
3.云原生下微服务趋势
（1）后端服务BaaS化
DB，MQ, Redis,注册中心、配置中心、服务治理中心
（2）服务治理下沉、透明化
Java Agent, Sidecar, Java治理和Mesh治理的统一，应用0成本上云
（3）部署形态多云、混合云化
本地云端混部、多云混部、公私混部
下面提一下，服务治理是微服务化深入地必经之路
从Cloud Hosting云上部署到Service Governance服务治理，服务治理的目的是为了提高效率/稳定性，同时是以业务为核心，保证业务永远不会停机。
- 阿里微服务治理演进路线
2008年推出自研微服务，导出的问题是依赖冲突难以管理，同时SDK升级的成本非常高；2013年推出Fat-SDK Pandora，是基于类加载器的隔离容器，它使得用户无需关心SDK升级的成本，同时解决了依赖冲突的问题，通过运维平台使运维治理的效率大为提升；
2019年主推Proxyless Mesh，其实就是 Java Agent的一个方式，可以对Java应用实现无侵入、0成本升级，同时它是全面兼容市面上近五年的Dubbo和Spring的框架；后面在做的是双模的微服务治理，不仅仅是Java体系的治理，同时也支持多语言体系，通过One Mesh的方式来支持，同时它也是易购产品下支持多语言的服务治理，并且多语言与Java的服务治理是保持一致的。
5.服务治理的区分
服务治理分为三个部分，第一部分是开发态Dev，第二是测试态Test，最后就是运行态Ops，运行态再细分,又分为发布态、安全态Sec、高可用
6.基于Java Agent的服务治理
通过Java Agent实现：
业务无侵入、无感知
0成本升级
全面兼容开源
主打更轻量：不改变现有业务架构
7.Spring Cloud上云最佳路径
当原先完成是在云下时，是通过Spring Cloud开源自建的模式。当迁移上云之后只需要保留最基本的Spring boot、配置、注册发现、客户端调用等最小的依赖，更多的服务治理能力都通过无侵入的Java Agent云产品提供。同时控制台都会使用云产品控制台。
二、来电科技微服务治理落地挑战
1.来电科技全面容器化的优势
来电科技现在处于一个全面容器化的阶段，下面介绍一下全面容器化给来电科技带来的好处：部署方便，发布效率大大提高；秒级扩缩容自动恢复；大大节约服务器成本稳定性增强；运维成本大大降低
- 来电科技微服务治理落地的困局
（1）安全变更三板斧：可灰度、可监控、可回滚
（2）痛点：在系统服务的发布过程中如何避免业务流量的损失;
因为系统的复杂，安全生产要做到可灰度、可监控、可回滚的能力。但目前系统缺少简单有效的灰度能力，每次系统发布都存在一定的稳定性风险。
（3）为什么来电科技不考虑自建？
接入成本高；维护成本高；功能较单一，不灵活；缺少强大的团队支持
（4）挑战：技术复杂度高；运维成本上升；可定位性变差；快速迭代难以控制风险
下面进一步讲解一下为什么技术复杂度变高以及运维成本上升:
全链路灰度-物理环境隔离
如果环境比较少，可以使用多套的物理环境隔离，但是我们可以直观的看到;
每套环境都要部署全部服务，机器成本、运维成本是非常高的；同时
创建环境、销毁环境不够灵活；这种方式无法满足多种隔离需求
如果机器的数量少是可以使用这种方式，但是当数量多时，成本会非常高。
所以全链路灰度一般都会选用逻辑环境隔离
如果服务A要到服务B，要根据流量的标签进行选择是正式环境还是灰度环境，一跳节就要涉及动态路由的能力；如果要实现全链路化，还要对节点进行打标并且对流量进行染色，同时还要具备分布式链路追踪的能力，就是流量不仅要染色，同时流量也可以传递下去。比如说，网关进入灰度流量，到正式环境A这边，A这边也可以到正式环境，但是到B的话需要跳到B的灰度环境，所以需要具备分布式链路追踪的能力。
可以看到，其实以上四种能力都有，但是真正完成的时候，成本是非常高的并且技术的复杂度也很高。
无损下线：
根据常见的微服务开发框架，我们该如何解决无损下线的问题：
①Spring Cloud:需配合Actutor，提前注销服务，并且及时刷新客户端缓存，等待流量停止再进行服务端下线逻辑
②Dubbo:需要开启Qos功能，进行提前注销服务。
以上都需要深入了解服务框架内部实现细节并要修改
不管是什么框架， SDK主要要做的三个步骤∶
①抽象出服务注销接口，并暴露给运维侧，配合发布系统进行。
②需要注意注册中心更新的实效性、以及及时刷新客户端的缓存
③等待流量停止后，再进行服务端下线，从而消除服务调用存在的报错时间
以Dubbo为例，关于无损下线一直是不断的，一直到Dubbo2.7.12时才具备，但是还有很多问题。当然，MSE服务治理能兼容2.5.x-2.7.x所有版本。
Dubbo无损下线能力图：
无损上线：
在服务注册过程中，如果有一些异步资源要准备，可能Dubbo/SC服务需要做到延迟暴露。当流量过大时，服务要需要具有小流量预热的能力，流量需要缓慢增加。还有一些问题，比如Fastjson/Jetty低版本没有开启并行类加载，可能会导致请求报错、JVM JIT编译问题会引起cpu飙高、在应用刚启动时可能会出现日志异步化。
以上所有问题都处理完之后才能允许正常流量进入，在这个过程中，把它抽象为无损上线的过程。
三、来电科技微服务治理的选择
1.来电科技MSE全链路灰度最佳实践
来电科技选用MSE服务治理专业版实现无侵入的微服务治理能力，以上所有方案都不需要改变现有业务的架构。
通过Java应用的方式使得其系统具备可灰度、可观测、可回滚的安全变更三板斧的能力，满足了业务高度发展下的快速叠加及小心验证的诉求。
通过全链路灰度的方案：当前端请求进入时，通过Nginx转发，进入Gray机器之后，流量会自动打上Gray标，并且会往后优先找Gray应用，如果后面有Gray应用，它会到Gray应用；如果不存在Gray应用，会回到未打标。到未打标之后，后面有Gray应用，它会回到Gray，从而实现一个全链路灰度的能力。
Nginx控制灰度环境百分之十的流量，正式环境百分之九十的流量，针对百分之十的流量，可以实现日常的演练:故障演练以及新功能的验证。
这套方案同时支持Spring cloud和Dubbo，来电科技通过这个方案快速落地了全链路灰度的能力，从而使得应用发布上线更加稳定，也会避免一些安全生产的问，有效提升了线上的稳定性，从而保证了服务百分之九十九点九的可用率。
来电科技不仅用了全链路灰度的能力，它还使用了服务预热、离群实例摘除、精确发布、微服务治理、流量观测等能力。
四、最佳实践
1.无损上下线最佳实践
在MSE中，只需要控制台开启无损上下线的动态配置，将应用进行发布，就可以看到实时的流量曲线以及在这个过程中服务进行了哪些操作、当前处于哪个流程，提供一套完整的解决方案，并且不需要我们更改一行代码
2.服务发现高可用保护
（1）无服务发现高可用保护
网络抖动如CoreDNS异常等，导致与注册中心连接断开
注册中心Server异常，导致地址列表为空
注册中心变更过程中，有小概率返回空列表
Consumer订阅到空列表，业务中断报错
（2）开启服务发现高可用保护
Consumer订阅到空列表，推空保护生效，丢弃变更，保障业务服务可用
当关闭服务开发高可用，会导致消费者找不到服务提供者地址，请求异常；如果服务开发高可用是开启的，即使注册中心销毁了，只要服务没有变更，在这个过程服务请求都是正常的。
关闭服务开发高可用保护：
开启服务开发高可用保护：
下面我们进行分别演示：
回到我们刚刚讲的无损上线的相关知识点，我们抽象总结了应用初始化、预建连接、服务注册、通过readiness检查、小流量预热、正常流量进入等方法，当应用接进MSE之后并且控制台打开开关就会自动的具备以上能力。
以微服务引擎中的无损上下线为例，
在这里面，我们可以看到所有的实践记录，并且可以看到实时的流量信息。
在节点名称里找到一个无损下线成功的案例
我们可以看到，在这个过程中首先是服务开始注册，在第一个请求进入之后，服务预热开始，因为我们设置的预热时长是112秒，到预热结束正好是112秒。流量是缓慢增加的，当Readiness检查通过并且预热结束、其他的pot开始滚动之后，流量开始下降，再往后就是流量均分达到稳态的情况，最后是先停止流量，流量停止之后，服务才开始下线。整个过程通过上述图片可以看出。
在控制台可以配置预热时长以及延迟注册时间，高级配置是设置预热曲线、服务预热关联滚动发布、微服务生命周期与k8s就绪检查对齐。
在控制台配置完成之后，还要在spring-cloud-a编辑启动探测，之后整个过程就可以实现。
下面我们来简单看一下开启服务开发高可用与没开的效果，首先，先演示关闭服务开发高可用保护：
当coding s是错误时，服务是正常的，当coding s恢复时，出现大量报错。原理是当连接断开时收到的是空地址推送，这时消费者会请求异常.
可以看到健康状态，超时之后，服务未下线
当coding s恢复时，流量没有任何损失，也没有出现大量报错
如果在生产上，不具备服务发现高可用保护的话，那在这个过程中，当provider与注册中心出现连接异常，即使消费者和注册中心都是正常的，服务还是会报错，对生产产生的影响是非常大的。
MSE以无侵入的方式提供了全链路灰度、微服务流量治理的可观测等核心能力，以更加经济的方式、更加高效的路径帮助来电科技在云上快速构建起完整的微服务治理体系，有效的提升了线上稳定性，保障了服务百分之九十九点九的可用率。
客户也提到:MSE服务治理帮助系统以很低的成本、无侵入的方式快速实现了全链路灰度的能力，进一步提升了系统的稳定性，让我们新需求的迭代更加安心。
最后我们也介绍了两个方案，一个是无损上下线，无损上下线通过产品化的方式可以在控制台上快速的配置上下线的规则并且实时的看到上下线的观测图。另一个是服务开发高可用保护，通过开启服务开发高可用可以实现注册中心异常的容灾保护，保障业务服务的可用性。
