开发者学堂课程【服务发现与配置管理高可用最佳实践：MSE 开发环境隔离功能介绍】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/971/detail/14892
MSE 开发环境隔离功能介绍
内容介绍
一、微服务架构总览
二、服务治理的区分
三、基于 JavaAgent 的服务治理
四、微服务多版本并行开发的问题
五、如何用起来-场景分析篇
六、如何用起来-基线环境应用接入 MSE
七、如何用起来-IDEA 应用接入 MSE
八、如何用起来-Cloud toolkit 端云联调
九、Demo 实操
一、微服务架构总览
首先看到微服务架构总览这一页。
整体上来看对于一个开发微服务应用期来说，最开始的步骤中是找到一些开源的框架，比如在 Java 里面比较流行的dubbo Spring Cloud，或者说其他的语言，它有自己流行的回复框架,在选定好框架之后再结合一些开源的组件，比如服务注册发现,服务配置，然后再加上一些 Spring Cloud Way，或者其他开源的 API 网关。
相当于通过这几个开源组件，就可以把一个维护应用及给开发完毕了，这时候离生产了还差什么？
就是在右边这一块，因为部署和可观测性这一块，比如使用阿里云的 KPi 去部署应用，然后这个应用的观测性通过阿里云的力度正宗阿姆斯产品，或者是SNS产品去做好这个线上出问题的一些定位和问题排、诊断的工作，这样应用其实就是初始具备了一个可以生产可用的应用，在这个过程中，其实暂时用不到微服务治理这些高阶能力的。但是随着业务再市场上越来越来受欢迎，发展越来越大的话，用户量越来越多，业务形态也越来越复杂，多样化需求和迭代也越来越多，要求也越来越快的时候，这个时候是需要使用微服务治理能力的，它分为开发运维态以及运行态还有测试态。
二、服务治理的区分
1.开发态 Dev：
服务元信息（ 看应用到底提供哪些服务，由哪些接口）
服务契约管理
服务调试（能否快速方便的对服务发起应用，无论是HttP还是dubbo或是其他协议都能发起）
服务mack（开发应用时，可能依赖下游它给提供一个接口，当他开发慢，通过提供的接口把返回值磨掉，进度不会被影响，可以独立进行开发）
开发环境隔离（MSC如何实现婉转维护敏捷开发）
端云互联
2.测试态 Test
服务压测（就是自动化测一个新版本发布之前，需要去看一下这个改动对原有的性能影响如何，压测结果和之前相比有没有大幅度的下降。）
自动化回归 流量回放（加速测试的效率，开发一个新功能肯定不能只是说测我的新功能好不好，对于我之前的功能有没有问题，是需要去快速高效的去做一个回归测试的）
3.运行态 Ops
发布态
无损下线 、无损上线、金丝雀发布、A/BTest、全链路灰度
安全态Sec
服务鉴权 、漏洞防护、配置鉴权
高可用
离群实例摘除、限流降级、同AZ优先路由、就近容灾路由
发布态这里面遇到，比如即使代码写的任何问题都没有的时候，再一次新版本的发布也是有可能出问题的。
就比如这里面就是会出现一些异常报错，导致业务有损，或者应用刚起来的时候，他其实承担不了这么大的流量，然后也是导致一些业务的损失，这时候会使用到无损下线和无损上线这两个功能。假设新版本写的任何问题都没有，但事实上开发的过程中，难免多多少少会出现一些问题，也就是代码写的有问题的时候，就更是需要使用金丝雀发布这个功能，新版本发布上去的时候，有哪些人能够访问到这个新版本的特性，其实是可以控制的，不管是从最初的只控制内部的人员可以使用到，或者是外部的用户只有百分之多少，或者是某一个地域，或者某一个年龄段，某一个性别，某一个手机型号的类型的才能访问到这些新的功能，这些都是可以控制的。
然后在高可用这一块，就是假设业务运行的好，有一些偶然出现的异常是没有办法避免的，比如一些网络突然超时的情况，或者是自己的机器，或者里面的阿里云出现了某一些抖动，这都是无法避免的，这个时候是可以用通过离群实例摘除功能，去避免这么一些偶然的异常，对业务产生一个比较大的影响。
然后在大初态的时候，要进行一个秒杀或者是抢购的产品，这时候限流降级也是可以保护到应用的，然后包括是业务规模做得非常大的时候，需要是跨地域多AZ进行部署的时候，这时候一些路由全局的高可用措施也是需要的，然后安全态在里面，比如说一些漏洞防护、配置健全，服务服务健全，这些功能都是会在后续的业务发展壮大之后是需要使用到的。
三、基于 JavaAgent 的服务治理
在微服务治理这一块，确实提供了非常多的维护自己的能力。有一个问题是这个用起来的成本到底有多大，是不是需要去修改代码，然后根据自己方式去研发，然后去重新测试，测试完毕之后又重新打包，然后再上线这么一个大的流程。
其实是不需要的这里就介绍一下MSE这边用的维护自己的技术基于Java的进行去做的，这一块通过加Java的基础，是能够在应用启动的过程中动态修改，直接抹在微服务框架中做了一些埋点。这样做的好处就是使用所有的MSC维护这个功能，是不需要修改任何代码。完全不需要侵入业务，而且开发人员是没有感知的。对于大家来说就是一个零升级的成本，只需要微服务框架是视频curl的一版本，以及以上的版本或者是double是2.5.3以上的版本都可以直接使用，在这个过程中，只需要把自己应用接入MSE为服务的Agent就可以了。代码镜下没有是任何修改，对原来的业务架构也是没有任何修改的，可以放心的使用，使用成本是非常的低。
四、微服务多版本并行开发的问题
最初采用微服务的时候就是觉得微服务可以是高内聚低耦合，然后可以去敏捷开发，快速迭代，走这一流程。但事实上真正实践过的时候可能都会遇到这么一个问题。
首先要开发一个应用的话，这个应用是没有办法独立的，去起来之后就可以直接测试的，需要依赖于下游的一个反馈，即使只是开发一个应用的一个代码，在整个测试的过程中，其实是需要一个完整的开发环境的，需要把依赖的这些底层服务。
可以正常的去开发哪条测试，也就是这个环境是需要把他所有的应用的这个时候由一个问题。比如有一两个迭代并行在开发，自己开发的是fish1，另外一个同事开发的fish2，终于开发好自己的接口，然后部署到开发环境去协调，结果发现返回值一直是错的，就是不符合预期，自己认为代码写的也没问题，昨天测试好的，今天怎么就不行。没办法，只能去看日志吗？或者用上了阿萨斯，各种手段，追踪下去，结果发现B，同时他在开发feature2，他也需要改一个应用。他把依赖的一个应用的代码逻辑改了导致开发不通过，下次测试前找到同学让他们别动环境，不要搞重启也不要搞debug，才能去正常的开始测试，这个时候B同学C同学，他肯定是一脸懵，而且不满。我也要开发我的逻辑，我这个迭代的进度也不能落下，自己都没有逻辑，没有理清楚，他刚改完，准备发一版的。结果我一连他，他就不能动，他觉得就是因为我把它给列了。这种问题真的是非常容易出现的。这是一个非常典型的抢环境的问题。那怎么样才能不抢环境。就一人一套环境，物理隔离的方式。
四、多版本开发测试环境
1.物理隔离方式
假设这里开发ABCD自己开发feature一号，那给一个独立的环境，把ABCD这四个都部署起来，然后哪一次改了a，那就重新部一下a就好，改成C部一下C。然后刚才讲的另外一个同事，他可能开发feature2，他也有自己独立的一套环境。他去改了应用D，他就部一个应用D。这里面提一下，其实物理隔离不仅是ABCD他要去做一个部署。
微服务都是通过注册中心来做一个服务注册发现，这里面拉克丝也是独立部署，或者是通过namespace进行进行一些隔离之类的。那这个方法确实非常简单，但是它的弊端也非常明显，看一下这个开发环境2，可能说开发feature2的同事，他其实只需要一个修改D但他布置了ABC三个应用，用这个整套环境都要拉起来。虽然说可以做的一个研发的同学，他不会互相影响，每个人都享有一套独立的环境，但是这种物理隔离的方式成本太高了，很难接受。这里也做过一个计算，就是比如说有十个应用，然后用ECS来部署。两个数据算了一下，一套黄金一年的成本是将近两万多左右，这个成本其实是比较高的，这里面只是说feature1、feature2，事实上一个迭代，其实它可能有五六七八个feature。那这样做一下乘法，一个迭代，七个feature，一年这个机器开发环境的机器成本就十几万就出去了，这个成本非常高的，相信很多公司都很难接受。
2. 逻辑隔离的方式
这个其实逻辑隔离看起来也比较好理解。就是基线环境，它其实只有一套。这里面的 ABCD 这几个应用，都是部署的这些应用对应的 master 的一个稳定分子的版本。
然后开发 feature1的时候比如说要改闭合的这两个应用，就把B和D启动起来就好了，然后另外一个 feature2的同事，他要改C和D，他就把C和D启动起来就好了。然后在这个发请求的时候只需要在请求的入口流量达到相应的标识，比如说要去 feature1，加一个 had 加一个 feature1标识，然后这个流量就是根据这个橙色的线来走的，他进来之后发现他是一个 feature1环境，他就会去找到 feature1应用去调用，然后接着找 feature1环境的C应用去调用，但是他发现没有C应用，那么他就退回到这个基线环境，走的是master的代码。再下一步到D的时候，他其实还是不会忘记，这是一个 feature1环境的流量，他会继续去找到feature1环境的定义，去调用，所以说这个调用的流程，就是这个橙色的这个线。同理，对于feature2环境来说，他也是这个绿色的线是这么过来的，一开始的时候从这儿过来，然后发现C和D是有 feature2环境的，它就会自动取消的环境完成这么一个流量的闭环。这样的一个好处是什么？
首先可以直观的看到消耗的机器数变少了，比如说这个C应用，A应用，feature2的A应用和B应用，都不需要部署了，也就是说开发的这个feature修改了哪个应用，就不拟这feature对应的应用就好了。而且这样也是能够达到这个流量的隔离，是不会互相影响的。相当于每一个同事依旧是觉得从自己的感觉上来说还是有一套独立的环境的，只是说这里面对于这个机器成本并没有说做一个比较显著的增加，来比较一下，就是跟上一页的这里面其实是一个乘法，就相当于比如有四个应用，三套环境，是一个四乘以三是12台机器。而在这里面比如一个人环境是四，然后要加一个环境做的是加法，四加二，再加二，当然这个例子上可能是观感不是那么大。但是想一下，如果说一个环境是有50多个应用，那么三个环节是50乘以三，这是150，而这里其实改两个应用，50加二再加二150和54，这个差距还是比较大的，就是说变成这个加法之后，确实能够减少很多的成本。拿刚才那个来说，比如说一套环境是接近2万，七个环境要十五万一年，而这里面他做的加法的话，其实就相当于说还是维持在这个数量级，足足可以省下13万的一个成本。
五、如何用起来-场景分析篇
首先用起来之前还是要去根据具体的产品去做一个分析的，就是因为不同公司它的开发环境是不一样的，比如说场景一，如果所有的开发环境都是在本地的，那这种情况下呢。所有的环境和开发人员的ID，里面跑的这个应用，他其实都是在公司内网的，这种情况下要使用的话，就只需要将应用接入MSE即可。然后给对应的环境打上对应的标，然后就可以使用了。那第二种场景就是公司的一些网络是通过这个专线打通了这个公司办公网，阿里云上的VPC，这个网络两边实现了这个互联互通。就是说有一些开发测试都是部署在阿里云上的一些类似环境部署在阿里云的，然后正在开发的工程，有一部分是跑在本地办公网，然后有一些是直接跑在这个开发同事的这个ID里面的，这种情况下其实也是将应用接入MSE，然后打上标就可以。那第三种情况，就是稍微特别一点，公司没有通过专线来打通办公网与阿里云的VPC，开发设施环境，不在阿里云上，但是希望这个本地的这个启动的应用，他可以跟阿里云上的这个开发测试化。赶紧去实现一个互联互通，并且也能实现刚才说这个逻辑隔离，这个精准的流量隔离。在这一块就是除了要将应用接入 MSE 之外，还需要借助一个端云互联的功能，来实现本地的应用和云上应用的互联互通。
六、如何用起来-基线环境应用接入 MSE
阿里云 K8s 环境如何接入
在阿里云 ACK 中安装 MSE 治理中心组件，根据帮助文档为应用开启微服务治理即可接入，具体的详
情可以参考这个帮助文档。https://help.alivun.com/document detail/170446.html。
开源 K8s 环境如何接入
开源的 K8s 环境也可以安装 MSE 治理组件，并在安装时填写对应的阿里云账号信息和Reqion信息即可接入，具体的详情可以参考这个帮助文档。
https://help.alivun.com/document detail/196069.html.
ECS 环境如何接入
ECS 环境可以通过下载 MSEAgent 和自行挂载 MSEAaent 的方式接入 MSE，具体的详情可以参考这
个帮助文档。
https://help.aliyun.com/document detail/187196.html
通过这个介绍其实就可以看出来，这个基线环境的应用是怎么接入 MSC，是已经了解了的。
基线环境就是部署是 master 分支代码的这个环境，也是唯一一个完整的拥有全套应用的这个环境，叫基线环境，然后 feature 环境就是说开发这个评选所需要修改的部分，这几个应用所处的环境，feature 环境是需要达标的，不仅是要接入 MSC 维护治理，他还需要达标。基线环境只需要接入 MSE 维护治理它不需要达标。
