开发者学堂课程【来电科技微服务治理落地实践：来电科技微服务治理落地实践】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/977/detail/14898
来电科技微服务治理落地实践
内容介绍：
一、云原生微服务的挑战和趋势
二、来电科技微服务治理落地挑战
三、来电科技微服务治理的选择
四、最佳实践
一、云原生微服务的挑战和趋势
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服务治理，服务治理的目的是为了提高效率/稳定性，同时是以业务为核心，保证业务永远不会停机。
4. 阿里微服务治理演进路线
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.来电科技全面容器化的优势
来电科技现在处于一个全面容器化的阶段，下面介绍一下全面容器化给来电科技带来的好处：部署方便，发布效率大大提高；秒级扩缩容自动恢复；大大节约服务器成本稳定性增强；运维成本大大降低
2. 来电科技微服务治理落地的困局
（1）安全变更三板斧：可灰度、可监控、可回滚
（2）痛点：在系统服务的发布过程中如何避免业务流量的损失;
因为系统的复杂，安全生产要做到可灰度、可监控、可回滚的能力。但目前系统缺少简单有效的灰度能力，每次系统发布都存在一定的稳定性风险。
（3）为什么来电科技不考虑自建？
接入成本高；维护成本高；功能较单一，不灵活；缺少强大的团队支持
（4）挑战：技术复杂度高；运维成本上升；可定位性变差；快速迭代难以控制风险
下面进一步讲解一下为什么技术复杂度变高以及运维成本上升:
全链路灰度-物理环境隔离
如果环境比较少，可以使用多套的物理环境隔离，但是我们可以直观的看到;
每套环境都要部署全部服务，机器成本、运维成本是非常高的；同时
创建环境、销毁环境不够灵活；这种方式无法满足多种隔离需求
如果机器的数量少是可以使用这种方式，但是当数量多时，成本会非常高。
所以全链路灰度一般都会选用逻辑环境隔离
如果服务 A 要到服务 B，要根据流量的标签进行选择是正式环境还是灰度环境，一跳节就要涉及动态路由的能力；如果要实现全链路化，还要对节点进行打标并且对流量进行染色，同时还要具备分布式链路追踪的能力，就是流量不仅要染色，同时流量也可以传递下去。比如说，网关进入灰度流量，到正式环境 A 这边，A 这边也可以到正式环境，但是到 B 的话需要跳到B的灰度环境，所以需要具备分布式链路追踪的能力。
可以看到，其实以上四种能力都有，但是真正完成的时候，成本是非常高的并且技术的复杂度也很高。
