开发者学堂课程【ALPD 云架构师系列：云原生 DevOps 36计-阿里云云效出品：环境管理的应用场景】学习笔记，与课程紧密连接，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/772/detail/13504
环境管理的应用场景
内容介绍：
一. 生产环境
二. 测试环境
三. 开发环境
四. 回顾
一. 生产环境
通常情况下，我们把生产环境与测试和开发环境分隔开，一个是线下环境 一个是线上环境 所以在这里画了一个防火墙。这其实是根据目的不同做出的分隔。
1. 问题：如果只有一套环境，这套环境应该是什么环境？
答案：生产环境
如果没有生产环境，就没办法提供服务了。
如果有两套的话，就可以加个测试环境。我们可以牺牲开发环境，但我们需要来验证这个服务在真的生产环境里头能不能跑起来，所以就需要一个生产环境的测试环境来去做相应的一些验证。那么这两者环境应该尽可能是一致的。
2. 生产环境（要求）：准确、稳定地运行
生产环境与测试环境最大的不同，在于服务运维和服务治理的更高要求。
有没有生产环境意味着这个服务能不能对外提供。如果没有生产环境，就相当于没有服务。
生产环境有非常大量的运维和治理的诉求。在生产环境里，运维和治理的诉求也会更多。比如通常情况下，测试环境中，可能给一个CPU一个节点就够了。但生产环境肯定要考虑备份 以及储备，考虑各种问题，而且它的策略会有很多种，还会有很多这样的要求，所以生产环境最大的特点就是一定要准确、稳定地运行。
同时这个准确稳定就带来了非常多的配置的诉求，以及运维和服务质点配置的诉求。所以就会包含很多的应用配置，应用运用配置等。所以生产环境的特点就非常鲜明，就是配置会非常多。
所有这个也说明了我们为什么需要OAM模型等这种模型，去管理我们的配置。
3. 问题：谁会用到生产环境，又该由谁来维护？
答案：生产环境由 Dev 和 Ops 共同来保障
这个不同的人可能会有不同的结果，或者说在不同的企业里，可能职责安排是不太一样的，也可能跟我的产品和产品行业形态有关，这个并不没有一个很确定的一个答案。
其实生产环境，就是应该是开发和运维来共同来保障的。当然实际情况可能并不一定是这样的，可能有些团队是没有运维同学的，或者有非常好的运维保障。为什么我们这么说呢？ 是因为生产环境本身包含很多东西，它包含应用配置、应用镜像、环境配置。
应用运维配置以及系数设施应用配置这些不同的配置和镜像的内容，是有不同的人来去关注和管理的。比如镜像本身显然是没有开发写代码，就只是发布，他可能就会动镜像或者动配置，我们就会改应用运维配置。
而这些改动都会对生产环境产生影响，可能会带来生产环境的一个变化，也可能带来一个风险 ，所以这个问题显然应该是开发和运维来沟通保障的。
二. 测试环境
这里我们列举出来了两种环境，一种是集成环境，另一种是预发环境，也就是类生产。这里其实是有不一样的，预发过程基本上是做验收的一个过程，而集成环境里更多是做集成测试 ，或者是相应的一些功能性的测试过程。
在不同阶段，不同的环境，用到的目的是不太一样的。
1. 分布式应用持续交付流程面对的挑战
在测试环境里，会面临哪些挑战呢？
这是一个典型的应用场景。也就是所谓的分布式的一个应用，在微服务化之后，分布的情况就越来越明显了。
在整个持续交付的流程中，面对的挑战很多都是跟环境有关的。
首先，因为缺少有效的本地验证手段，进入集成环境的应用变更质量无法保证。
在中间的提升测试阶段，由于服务应用之间的依赖关系，当某一服务处于不稳定状态，影响其他服务，无法保证主干集成有效进行。所以经常没办法很好的进行整个日常集中测试，然后到预发的时候，因为前面的没办法保证，所以可能就会占着预发。所以大多数的集成验证从日常环境被转移到预发环境。
因为预发是一个相对高成本的环境。但是不可能每一次变化都占着，所以这样的话预发就变成了一个长期环境，这就会导致交付周期变长。所以说，单个服务应用无法保证有效的日常集成验证，开发者开始采用长分支开发策略，批量预发集成成为常态。
目前来说大家遇到的比较多的测试环境的问题，第一个就是服务没有进行有有效的治理，服务放太多了，然后一旦有一个有问题，其他都有问题。比如在日常集成环境里，到相来说都是处在变化当中的服务。假设按图里的abcd，abcd任何应用都有可能正在发布和部署，而且部署的时候，都是没有被验证过的，它是临时不稳定的，彼此之间又有依赖，整个集成环境是不稳定的。
第二点，如果没有在之前做相应的验证，就将所有东西都放在里，基本上也会导致这种情况。
第三点，这个原因会导致，所有的测试都会往右预发，预发之后，可能又会转为线上。
⑴挑战：服务之间的依赖
①Scenario 1:A对C的强依赖，A的功能成功与否取决于C的质量
②Scenario 2:C的变更，同样需要对A的有效性进行验证
⑵挑战：环境的稳定性
①Scenario 1：如何保证测试机器的稳定性
②Scenario 2：如何保证测试机器资源的利用率
③Scenario 3：在服务依赖的环境下，如何保证升级过程中服务的稳定性
④Scenario 4:有服务依赖的环境下，如何定位问题
刚才我们举到一个例子，在日常集成环境里，如果是一个大集成环境，那么所有的服务基本上都是不太稳定的。而且如果一个服务的可用性是10%，那这个系统是怎么样来去保证它的稳定性？
2.如何保证测试环境的稳定？
如果应用A依赖于应用B，在同一测试环境中，由于B的变更部署，导致A的验证被打断。
⑴双机部署
①每个应用服务在测试环境中都分别有至少两个实例部署在不同的机器上，互为备份。
②蓝绿部署，在部署阶段，分两步部署，首先部署备机，当备机起来后可以提供服务，再部署另一个机器，而在整个过程中，服务不中断。
⑵N+1部署
①在整个测试环境中，有N+1台机器，其中，N表示有N个应用服务实例分别部署在测试环境的N个机器上。+1台机器做为升级部署的机器。
②在部署过程中，先在+1台机器上部署升级的应用服务，服务起来后，将之前的应用服务切换到新部署的机器上，而原先的旧服务所在机器，成为部署用的+1机器。
⑶隔离环境
这里把项目环境隔离出来，一个环节针对一个特性，在开发的时候，给他单独的拉一个环境出来，也就是隔离。这样它跟谁都没关系，它所依赖的就是稳定的环境。我们就可以保证在里面只有他是不稳定的，其他环境都是稳定的。
这种情况下，就可以让它独立的去开发测试。但很多时候，在早期的时候，一个项目预集成依赖的是还是日常集成环境。 但是这也比直接放到日常集成环境要好很多。但这个过程当中，会发现其实日常集成环境还是有些问题。因为有一些人会用项目预集成环境去做验证，有一些人又不会，而是直接上去了，这就导致日常集成的依赖会有很大问题。
⑷引入稳定环境
①稳定环境是由从正式线上版本一致的应用服务组成的系统。
②在日常集成环境中，所有的依赖不依赖于日常集成环境本身，而是依赖于稳定环境。
基础环境也要有一定的维护成本，需要部署。另外机器资源对于大公司来说，不是太大的问题。但是对于小公司可能会是一个问题。
然后主要的成本是维护的成本，就是要监控它。一旦基础环境出现问题，还要去修复它。这个就是主要的成本，也就是在人力上的损耗。
而且基础环境的维护者，一般并不是这个基础环境的使用者。所以候需要有一个比较成熟的机制，去保证这个基础环境的长期稳定的运行。
⑸问题：如果没有基础环境提供稳定依赖，哪一个环境是最稳定的呢？
答案：生产环境
在做测试的时候，有没有可能依赖的基础服务是在生产环境上的呢？那么这个理论上是可行的。如果说我们的安全隔离能力做得足够好，数据链路的隔离做的足够好，监控做的足够好，安全保护做的足够好，事实上我们是可以用生产环境来做基础环境的生产环境的。
基础环境作为依赖环境，它要面临解决两个重要的问题。
第一个就是隔离，流量隔离相来说问题不太大，目前来说云原生之后，从以前的面向资源，到现在的面向流量，基本上比较容易做隔离。
第二点是数据，这是一个挺大的挑战。尤其是因为现在的数据式多样。比如，消息数据和普通数据库就不一样，收藏的不一样，可能大数据又不一样，这里就有很多非常麻烦的问题。
3. 测试环境：用尽可能少的资源进行独立的测试
为了隔离，如果要打通外部的一些服务，然后这个外部服务出问题了，其这时我们可以模拟一个外部服务，来去帮助我们做测试环境的创建。
4. 测试环境举例：某大数据产品
比如大数据产品，可能环境要求太高，就没法做测试环境。
最早的方式，就是就用一套测试环境去做这个事情。这个显然是很低效的。如果就一套测试环境，如果互相冲突的情况下几乎没法做测试。
那么这么多个服务和应用，其实是可以把它分了三层的。
应用：控制台等相关应用
独立服务：Redis、 Zookeeper
公共服务：Hive、 Kafka、 MySQL
⑴Hive、Kafaka、MySQL属于公共服务，被所有环境所共享，通过分区等手段隔离
⑵每个测试环境都会部署一套独立服务
⑶每个测试环境根据需要部署相关应用，保证应用间的服务发现
⑷测试环境都是临时环境，使用完之后即被销毁
三. 开发环境
开发环境的范围包含很多，比如开发要用到的一些工具链，包括构建要用到的所有工具链，还有提高生产效率的一些东西。但在这里我们更多关注的是，怎么把服务跑起来，怎么去做调试和测试。
1. 开发环境的三个问题：
理想的情况下，开发环境是能够跟其他测试的技术环境互相打通的，所以就有三个要解决的问题。
⑴怎么访问基础环境中的服务？
⑵怎么被基础环境中的服务访问到？
⑶怎么与来自其他环境的请求隔离开？
推荐工具：https://github.com/alibaba/kt-connect
2. 工具推荐
⑴终端工具：iTerm2（Mac)、wsl-terminal（Win）
⑵Shell: zsh + ch-my-zsh (plugins: autosuggestion, syntax-highlight, interactive-cd )
⑶终端分屏：tmux
⑷模糊匹配：fzf
⑸模糊查询：ripgrep
⑹文件查看：bat
⑺命令行下的编辑器：neov
⑻k8s 联调：kt-connect
⑼docker 镜像查看：dive
3. 问题：外部环境受限，无法采用 k8s 部署怎么办？
很多时候其实外部交付的形态如果有没有，当然要更好了。如果没有，首先看容器能不能用，如果容器也不能用，那么看测试环境能不能用，测试环境可以用k8s管理。因为我们用这些环境、这些技术手段的根本目的，是为了提升我们的生产效率，和解放一些非常琐碎的事物，所以我们要各种各样的工具和手段，以及新的技术来帮助我们提升生产效率和派发效率。
四. 回顾
1. 我们需要的是软件定义的不可变环境，相同的制品、相同的运行上下文、相同的编排规则
2. 借助k8s的编排机制，可以大幅提升环境使用效率，降低资源成本
3. 通过laC来定义环境，包括应用配置、应用运维配置和基础设施运维配置
4. 通过OAM模型让Developer、App Ops、Infra Ops三者的关注点分离
5. 测试环境：用尽可能少的资源进行独立的测试-隔离、复用、模拟
