开发者学堂课程【微服务治理技术进阶：【直播】微服务治理技术的原理介绍】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1033/detail/15310
【直播】微服务治理技术的原理介绍
2.应用场景
·日常/开发/项目/测试环境隔离
构造日常、开发、项目、测试等多套环境的“泳道”，每个项目环境都有唯一的一个项目标签，流量带上这个项目标签后会路由到该项目环境，否则会去主干环境。如果没有这套机制，开发环境要进行物理隔离，这就需要部署整套微服务架构，成本非常高。
·全链路灰度发布
线上所有应用部署灰度版本，灰度流量全部进入灰度版本，正常流量进入生产版本。灰度版本只针对灰度流量验证，有效减少风险。云上客户安x就有这样的场景，要灰度发布 N 个应用，想灰度流量在这 N 个应用的灰度版本之间路由。
·高可用同机房优先路由
业务高可用部署后，服务调用如果跨机房，会带来额外的调用延迟。开启同机房优先路由后，让 Consumer 服务调用优先选择相同机房的 Provider，降低 rt。
·全链路压测
直接使用线上环境压测，让压测流量的 DB 操作落库到影子表，Redis落到影子KEY，MQ 落到影子 TOPIC。如果没有路由能力，需要搭建一套仿真的线上环境用于压测，成本直线上升。用线上环境配合流量控制能力可以实现О机器成本，0维护成本完成全链路压测。
其实是有很多应用场景的知识，比如日常开发项目，测试环境等隔离只要简单的构造多套环境的一个泳道，并且给每个环境都打开一个唯一的项目标签，流量带上项目标签或者会自动的路由到对应的一个项目环境中，否则会回到主线的极限环境中，如果没有这套机制，要进行多套开发环境，是需要进行一些物理隔离，就需要部署整套的微服务架构，成本与维护都是非常高的。全链路灰度发布，就是线上应用墙发布时，可以说通过部署灰度版本，引入配置一些简单的流量规则，引入一些灰度流量，在灰度版本中进行验证，可以有效的控制发布的风险，云上有很多的客户都是这样用的，要恢复发布 N 个应用，其实是想要流量 N 个应用之间、灰度版本之间进行路由，如果有些应用没有灰度版本，就回到线上极限的环境中，除了最常见的几个场景外，还有一些比如像高可用场景的同机房优先，以及像常见的全链路压测，都是基于全链路灰度能力实现的。
3.微服务全链路灰度解决方案
全场景全链路
·前端
·网关
·RPC
· MQ
· Database
· Redis
· 分布式任务调度
完整全链路解决方案
·基于 Ingress-nginx 网关实现全链路灰度
·基于 Apache APISIX 网关实现全链路灰度
·基于 MSE 云原生网关实现全链路灰度
·基于 Java 网关实现全链路灰度
·基于 RocketMQ 实现全链路灰度
·通过 Jenkins 构建 CI/CD 实现金丝雀发布
·微服务敏捷开发最佳实践
产品化界面
·完整的产品控制台
·秒级可观测能力
·流量大盘
关于全链路灰度的一个完整的解决方案。一个想法是想要做线上，云上客户或者线上的客户需要涉及到的所有场景，从前端到网关，到微服网关，再到微服务应用之间，比如像 RPC 有、MQ 以及消息有、Database、Redis、分布式任务调度以及到后端的数据库，想要做到全场景的一个全链路灰度的能力，基于这个点之后，有尝试在做的是全场景的各种场景的各种 case 的完整的全链路的解决方案，比如像基于 Ingress-ngix 网关实现全链路灰度，以及基于各种开源的网关、Apache APISIX网关以及 JAVA 的微服务网关之类的实现全链路灰度，也有基于云厂商提供的 MSE 云原生实现全链路灰度，同时还有 RocketMQ 实现全链路灰度，也有通过 Jenkins 构建 CI/CD 实现金丝雀发布以及涉及到专业互联的，即微服务敏捷开发的最佳时间。
希望输出完整的全链路灰度的解决方案帮助企业更快速的一个上云，第三块 MSE 这款产品在做的，需要对用户提供一个完整的产品控制台，做到开箱即用的能力，同时对于灰度流量，提供了秒级的一个可观测能力，当在网吧配置规则之后，马上能看到流量进入了一个灰度环境，对于应用间的调用，对于整个拓普有一个流量大盘，可以让我全链路灰度做到回到哪里一目了然，基于上述为了让用户在上云的过程中，微服治理时间的过程中，可以做的更加平滑以及稳定。简单的介绍了概念及场景，还有未来的一些想要做的以及传入的最佳实践以及产品化的一些东西。
五、微服务 Serverless Pass 解决方案
·典型的【业务系统】外的配套
微服务相关的技术解决了很多系统的问题和效率的问题，但也有一些门槛，前面分享了各种微服务治理的解决方案、这方面的经验，进一步降低拥抱微服务技术战的成本。但可以看到拥抱微服除了需要微服务技术本身的组件以外，还需要配套的可观测方面的全链路监控化解系统、发布系统、CI/CD工具等，以及需要运维基础的lass 资源，包括很多企业也会使用 k8s 更好的管理。拥抱微服务确实解决了单体的一些混合问题、效率问题，但是也引入了一些其他的复杂性，也推出了一站式的微服务 Severless pass 的解决方案，也就是阿里云 SAE 这个产品，进一步降低大家理解和使用微服务的成本。
阿里云 SAE(Serverless App Engine)- 一站式微服务 Serverless Pass 解决方案
包括 Serverless 化的 lass 和 k8s，在零感召前提下，无需运维 lass 和 K8s，最大化的减少大家的运维成本，同时又有丰富的弹性特性以及作为一个一站式的 pass 型产品，它也集成了 MSE 微服务治理、MSE 注册中心，完整的可观测性体系，企业之间权限、发布，CSAD 对接等等，通过这样一个产品，希望企业在拥抱微服务技术站的同时，进一步降低其配套的复杂度，把相关的最佳实践作为一个产品交付给大家，进一步的内容，欢迎查阅白皮书。另外最近开源了 open 设置项目，致力于建设统一的微服务治理规范
六、趋势和展望
·后端 BAAS 化，开箱即用，极致弹性，分钟级交付，安全可靠，提供 99.95%高可用。
·客户端轻量化︰降低业务侵入，多语言标准集成，治理能力下沉。
·业务侧 Serverless 化:让业务无需感知服务器，更加聚焦业务开发，提升研发和运维效率。
首先是后端 BASS 化，用户只需要从云服务厂商购买服务，就能够得到后端服务，比如通过 MSE SQL 购买，能够立马得到实例，开箱即用，弹性和运维成本不需要关心，只需要用对应的域名和 IP 端口就可以，同时提供了高可用的能力；二是客户端轻量化，基于开源客户端，开源客户端只需提供一个 interface，业务方这一块无侵入，多语言是通过标准的能力集成，具体的服务治理能力实现是放在 SDK 的Java Agent 中，它的治理能力是下沉的，客户端非常轻量化，只需要提供一个标准的 RPC 接口或数据库接口、MQ 接口都可以，最后一点是业务侧 Serverless，业务侧不需要感知业务如何部署的，不需要感知资源的情况，只是代码写好，部署上去就可以，Serverless 这种模型，业务只需要关注业务模型是什么样子的，能够提升研发效率和运维效率
服务治理数据面透明化，控制面标准化
服务治理的主要趋势就是说数据面越来越透明，用户或说业务开发者不需要关注数据面具体是什么样子、有什么样的能力、有什么样的不足等，仅仅是把它当做一个透明的面来用就可以，控制面就是更加标准化，用一套标准的控制面控制各个微服务的框架，比如图中的例子，下面是 one java agent 模式和 SDK 模式来接入，Service Mesh 也是一种无侵入的接入方式，通过这三种接入模式的话，用户在写代码时是不需要关注具体使用哪种方式接入的，这三种接入模式都会遵循统一的控制面，就是控制面标准化的一部分，在管控面这边不管是开源的管控面，还是 MSE 的管控面，都是兼容标准化的能力，给用户提供管控能力，下面的话是总结出来的功能上的特性
OpenSergo- 建设统一的服务治理管控
观察趋势之后，推出了公司各项目，主要是建设统一的服务治理管控面，中间有一个 OpenSergo 规范，它规定服务源数据是什么格式、服务治理的配置、参数应该如何填、服务发现应该用什么样的模式来接入和可观测，就比 OpenTelemetry 应该用什么样的方式去接入，右面这一块是数据面，比如刚刚提到的 java agent 接入的服务治理和 service Mesh 的服务治理，或者说现有的模式服务治理，比如Spring cloud Alibaba 或 Kratos 这种新的或旧的微服务框架都能够用 SDK 模式去接入，总而言之就是 SDK、service mesh、java agent 交易都可以用来接入，都会用 openSergo 的模式接入服务治理，左边是管控面，openSergo 作为一个开源项目，会提供一个开箱即用的 Dashbaord，开发项目名字为 openSergo Dashbaord，用户可以开箱即用的去管理自己的微服务，去治理自己的微服务，企业有自建的需求，也可以遵循 openSergo 规范来做一些企业自建的 Dashbaord 实现一些定制化的能力，更加关注底层的用户，可以直接用 Kubernetes CR 的这种模式直接去编辑来实现自己微服务的配置和管理等。
微服务治理技术白皮书不仅包含了阿里巴巴集团在电商领域10余年的微服务治理技术实践，其实也包含了 MSE 数百余家客户的一些方案，不仅包含帮助写序的来电科技，三菱电梯这么一些公司，也包含了阿里巴巴集团内部的一些客户，比如菜鸟、达摩院以及电商的场景都是有在使用的，邀请到了菜鸟平台分享他们在借助于MSE 去实现的微服务治理技术能力这一边的最佳实践。
是一个多语言为基础结合先进的云原生建设的理念去建造服务平台，主要支撑的是包括菜鸟商业化的一些客户的话，甚至还有一些菜鸟生产的公司，但在这个支撑的过程当中，也不是第一次跟 MSE 合作，之前因为客户要把自建的注册中心迁移到阿里云上面的 nginx 上，已经有过一次沟通，提供了一个 java 进程，帮助服务在不停机的情况下，迁移到上面来，这是第一次相遇。在我们后面支撑业务的过程中，提出了几个常见的问题，可能也是目前来讲 web 客户或者 web 公司里面会经常遇到的，第一个是想要在日常环境上面提高日常的研发效率，因为日常环境上面可能会有多个分支开发的这种场景，多个分支开发的过程当中涉及到如何去减少分支开发冲突次数，如何让自己的分支有一个隔离的原料环境去使用、调试，有一个快速的测试平台测试，这一块相当于在日常研发绩效方面上的一个诉求，第二个诉求是在安全生产方面的需求，之前在云上的恢复能力自建起来是比较复杂的，在调研了很多产品之后，也发现 MSE 其他具有云上这个基于标签路由能力的推动能力，这一块相当于在其中得到的收益。第三是关于服务自身的稳定性，基于上述三点，如何帮助客户达成目标，如果有目标，去自建就可以，想自建一套体系，但自建会有几个问题，第一是它的成本大，因为要有不同的中间件的流量隔离，中间件的版本的差异等一些问题，维护成本就特别大嘛，所以把自建的方案给否掉，第二是业务侧开发，通过业务代码测试自身代码的形式，去开发灰度或者隔离等能力，这一块业务或者客户自身是不愿意的，因为这一块带来的成本也很大，而且整个开发周期比较长，技术难度比较高，也否掉，基于之前的一些了解，他的定位是微服务治理的一个平，最终选择 MSE 通过 java agent 方式去做无侵入的方案解决，其无侵入的方案解决带来的一些好处是有更多的发挥空间，无论是基于标签路由方式的项目环境或是灰度环境的一些构建，还是在基于上下线的集群的稳定性或是服务肯定性的方面去做发挥，还是在其他后期包括同城调度、流量的治理、无侵入防护，以前后期的流量大盘方面都有提供的一些基础的服务，或提供便捷的能力，这也是选择 MSE 团队的产品作为微服务治理产品的一个心得。
首先 MSE 在专业团队上的这个专业性是够用的，其次跟其他云产品之间的兼容性是比较好的，不用考虑冲突导致太多的问题，最后一点是未来的话，可能会基于MSE 的微服务治理，去做更多关于服务治理方面的相关事情，合作空间应该会更大一些。
