如何低成本玩转为服务敏捷开发
----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进行部署的时候，这时候一些路由全局的高可用措施也是需要的，然后安全态在里面，比如说一些漏洞防护、配置健全，服务服务健全，这些功能都是会在后续的业务发展壮大之后是需要使用到的。
在微服务治理这一块，确实提供了非常多的维护自己的能力。有一个问题是这个用起来的成本到底有多大，是不是需要去修改代码，然后根据自己方式去研发，然后去重新测试，测试完毕之后又重新打包，然后再上线这么一个大的流程。
其实是不需要的这里就介绍一下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，一年这个机器开发环境的机器成本就十几万就出去了，这个成本非常高的，相信很多公司都很难接受。
- 逻辑隔离的方式
这个其实逻辑隔离看起来也比较好理解。就是基线环境，它其实只有一套。这里面的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维护治理它不需要达标。
点击IDEA的Tools中找到Alibaba Cloud中的Preference，找到Alibaba Cloud Toolkit中Microservice下的 MSE，点击开启微服务治理。使用Cloud Toolkit插件，即可将本地应用打上MSE的标签。
八、如何用起来-Cloud toolkit端云联调
其实自己的办公网跟阿里云上的这个VPC网络，它其实隔离是没有打通的，这个时候要怎么实现我这个本地的应用，它可以去访问到云上的这个时候其实需要借助这个cloud toolkit的这个端云联调这个功能，来通过这个通道服务，通过这个interest port去跟这个provide进行一个互联互通。
在这一块使用起来也是比较简单，只需要把这个K8S进行的config文件保存到本地，然后再在这个micro service下的这个端云互联里面进行一个配置。然后就可以使用。
九、Demo实操
首先复制网址，然后在浏览器中打开。打开之后其实可以看到这篇文章，这文章其实在最开始的部分就是这些背景简介部分。如何使用MSE开发环境隔离这个特性这一块。从这里可以看到产品分析，从这里开始是如何进行一步一步去使用我们的这个开发环境隔离去实现这个微服务敏捷开发的。
首先是需要登录MSE治理中心的控制台MSE治理中心的控制台登录之后去开通一个敏捷版，完成基线环境的接入，基线环境这一块演示是通过一个阿里云的ack集群里面的。在接入的时候需要安装一个MSE治理的组件，可以看到这个容器服务的控制台，将端云互联的集群推出到外面，在这个容器服务里面有一个应用市场，单击这个应用市场，找到微服务，然后点击这里有一个ACK MSE Pilotal 。点击进去，选择一键部署。
找到刚才那个端用户联机群，这些命名空间和发布的名称都是默认的，不需要修改，直接点击下一步。
然后，这里面内容也是不需要修改的直接确定就可以安装。可以在这边去确认一下有没有启动完成刷新一下。可以看到有一个MSE pilot的命名空间。然后进去看这两个，已经都启动完成了。
再回到MSE的管理的控制台。点击这个K8S集群列表，这是北京这个机器。可以看到，这里有一个端云互联的，这个集群已经接入了MSE微服务治理。
在这里面需要给这个default命名空间，开启微服务治理。在这点击。开始微服务治理，确定。现在就已经开启了，那接下来在这个default命名空间部署的这个Java应用，他都会直接接入这个MSE的微服务治理的。
回到这个文档里面这第一步接着MSE，这里已经成功了，同时这也是开启了这个default 命名微服务治理这个功能接下来是要部署这个基线环境，部署一个demo上去，然后在这里面可以看到demo的架构是这样的，有一个网关去掉a应用再去掉B应用，在调C应用是这么一个流程，然后这里面也有一个github地址。直接把它打开，可以看到这个部署的源码，其实他就是再github上，因为这里演示就是把本地的一个a应用启动，然后进入需求一环境，然后去调用。首先要部署这个基线环境的应用，首先将复制的内容粘贴到这里，然后可以发现复制内容里面有一些这个地址其实是错误的，就是这个很多个X这一块。
因为这里面其实有一个限制，就是使用端云互联的话，这个注册中心的地址要需要使用是MSE的那个组合中心，所以这里要进行一个替换。比如这里的那个地址是这个。所以要把它换成正确的地址，就是找到这些地方进行一个替换的动作。然后在这个k8s集群上进行一个部署找到基线服务控制台，这里有一个使用样板创建资源，在这里面都删除掉完整原封不动的复制粘贴过来，点击创建。然后可以看到这个其实已经创建成功了。去看他一个状态，这边已经是都启动成功了，在MSE的控制台上去过滤一下这个应用，可以看到这些应用都是接入MSE这里是成功了，而且实例数量都是1。再回到注册中心这里面看一下刷新。
可以看到，这些ABC的swing call的服务，和他们对应的这个double服务，其实都已经是注册到这个注册中心了。这一步就说明说这个基线环境已经是接入了MSE的微服务治理。就是这个应用列表也是能看到对应的应用实例也是正确的。在此之前提到使用专用互联功能是需要把K8S进行的config文件配置到本地的，先配置一下，找到集群信息，链接信息复制。更改一下kebu文件保存本机，配置成功之后执行一下这条命令。
去看一下这个service还是deployment的情况，这里面可以看到，它对应的这个公网IP是这个123开头。访问一下。就是在这里面的八零端口对应的a大a，小a。这么一个url。可以看到访问之后，他其实会返回一个ABC这么一个链路，然后包括a对应的IP B对应的IP和C对应的IP。
那现在就是说一个基线环境的返回，现在要做的事情就是说要开发这个a，让这个a feature环境在本地的ID里面启动，并且接入了这个集群里面。同时通过一些配置，就可以让流量准确的先到a的feature环境，然后再去B和C。
首先的话其实是想要去开发，要下载源码，源码是在这个github上，就是这个阿里云下的阿里巴巴cloud micro service的应用，首先是需要做两个配置的，一个配置是这里面的Cloud toolkit这个accounts就是首先应该是需要安装这个 alibaba cloud toolkit然后去做一些配置。找到这个阿里巴巴cloud toolkit这个preference里面。
首先是要配一下这个账户，账户就AKSK，然后找到这个micro service，因为要使用专用互联，在这里面打开专用互联功能选择，然后刚才使用的集群是北京的这个集群，在这里选择就好了。选择这个对应的这个。Nacos集群的这个ID的命名空间啊，这个20001要要单独提一下，就是说这次要看开发是a应用，它其实启动的端口，这个20001，要在这里面去打这个20001，就是说a应用的tomcat，它监听的端口填到这儿，然后代理这里面填的选择是K8S。这个代理怎么配置呢？
这个proxy这里面，然后在这个代理类型里面点一下add去增加一个代理类型，选择这个K8S，然后去选择刚才我配置的这个kube config这个文件，然后点OK就可以了。
在这里面选择确认这个a应用，它可以连接上这个北京MSE nacos同时他也可以跟这个B应用，C应用，还有这个网关应用互相通信。这是第一步，然后点击应用，然后第二步就是说要把这个a应用接入到这个MSE里面，这里面是做一个配置的点，开启行微服务治理，然后要点开一下微服务度这些都选上，然后因为Agent在北京，其实是要跟这个进行一一对应的开发是spring cloud A应用，来这里就添spring cloud A应用，今天开发的feature1环境，去填选feature1，这个可以随便填的, 然后这个nacos key，就是在这里面，可以在这里面找到ECS起源，然后走到这里面会有一个license key，完成这一步之后，点确定，然后去启动这个A应用就可以了，在ID里面启动。这里面会提示一个端云互联已启用，选择OK。
他这里会创建一个proxy Deployment就是通过这个来进行一个互联互通的，等待启动完成。
在这里面已经可以看到了，这个应用其实已经接入了有一个IP，这就是说我本机的这个IP已经接入了，同时它这个标签是feature1在这个监控里面可以看到，因为网关不断有流量，再打不过来，她所有的流量都是去未达标环境的，虽然feature1的应用是启动了，但是没有流量进来的。这个时候来验证一下，就是怎样才能把流量发到我这个本地的，这时候其实只需要给他加一个had。比如说这个是feature1环节。在输入这个返回值里面显示这个A feature1环境，然后他的IP是192的IP，其实这是本机的另外一个IP。另外一个网关可以看一下，这确实是本机的一个IP，然后当这个had里面不带内容的时候。
他其实访问的还是基线环境。这是一个非常方便的方式，就可以说我们灵活的去控制这个had里面有一个xmsetag为feature1的这个流量，他一定会去这个a的feature环境。回到这个页面，就是有些同事可能会觉得一定要加这个had是一个比较麻烦的方式，有没有一个其他的方式，就是可以自由的控制哪些流量，回到这个spring cloud a，用这个界面找到这个标签路由，对这个feature1配置一个流量规则就可以实现，这里path的话，是需要选择这个路径,因为在留空的话就代表任何路径。
这边把它留空，然后比如说要参数内部等于hello，都来feature1,就这么配置，点击开启，点击确定，配合这个规则之后现在其实不需要这个再去配置had,去配置一个name等于hello。
可以看到这个流量也是回到这个feature1环境。这也是非常的方便，然后如果说有其他的方法，可以进行更详细的配置，这个可以参考MSE的帮助文档里面的标签路由有这个详细的每个参数的说明是什么意思，都有比较详细的解释。
