开发者学堂课程【ALPD 云架构师系列-云原生 DevOps36计：环境管理的应用场景（一）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/82/detail/1275
环境管理的应用场景（一）
内容介绍：
一、 应用场景
二、 测试环境
三、 开发环境
四、 工具推荐
五、 内容回顾
六、 课后练习
一、 应用场景
接下来来了解环境的一些应用场景，传统地来说，如下是实际中常常遇到的环境的一些概念，如下图：
三种环境的使用场景和要求是不同的
上图自下而上可以看到生产环境、测试环境、开发环境，而且通常情况下大多时候会把生产环境、测试环境和开发完全隔离开，即用一个一个防火墙隔离出线下环境和线上环境。这些环境的概念无需过多再述，是根据它的目的不同做的区隔。
此处有一个问题：上述提到三套环境，假设只有一套环境，这套环境应该是什么环境？毫无疑问若只有一套环境会保留生产环境，否则无法提供服务。
若有两套环境会保留生产环境、测试环境，内生产环境的测试环境用以验证提供的服务在实际生产环境中能否得到应用。要保证服务在生产环境中得到较好的应用需要一个内生产环境和测试环境，这两种环境应基本一致。
如下是生产环境的要求：
生产环境：准确、稳定的运行
生产环境意味着服务能否对外提供，没有生产环境相当于服务是不存在的。生产环境的要求是不论前面做了什么，一定要稳定、准确、不能出错，出错就意味着故障。生产环境与测试环境最大的不同，在于服务运维和服务治理的更高要求。通常情况下在测试环境中，给一个 CPU，一个节点就足够，但生产环境可能要考虑备份、主备、分流、各种洪灾，且其应灾策略有多种。因此生产环境的要求一定要准确稳定，同样准确稳定的要求也带来大量配置的诉求，即运维和服务设施的配置需求。因为包含很多应用的和配置，这个生产环境的配置意味着后面的配置需要非常多。因此也说明了为何要运用 ALPD 模型来管理配置。
接下来是另一个问题，谁会用到生产环境，又该由谁来维护？不同人有不同的结果，或者在企业中的安排是不一样的，它可能与产品和行业形态有关，这不是一个确定的答案。生产环境是由开发（Dev）和运维（Ops）共同来保障的。实际情况有所出入，比如有些团队没有运维，有些团队有较好的运维和保障。
生产环境本身包含，应用配置，应用进项，环境配置，应用运维配置以及基础运用设施配置，而这些不同的配置和进项的内容是由不同的人去关注和管理的。比如进项本身是开发写代码最后再发布进项。可能会设计应用和配置，运用会改运用配置，基础设施改基础设施配置。这些所有项目的改动都会对生产环境产生影响，可能会对生产环境带来变化或风险，显然这个问题是由开发和运维来共同保障的。针对这个问题不同人有不同意见。除了生产环境还有另一个重要的场景就是测试环境。
如下列举了两种测试环境：
一种是集成环境，另一种是预发环境，预发环境及内生产环境。预发基本上是做预收过程，在集成环境中更多是做集成测试，即相应的一些功能性测试。因此在环境不同使用阶段过程中使用的目的是不一样的。在前面有人问过测试及测试环境的问题，其实发现在很多大大小小的公司中，一提到测试环境就会立刻说不够或测试环境太小，不稳定。在当下的情况下，在测试环境方面也在不断的协调着，现在典型的应用场景都是分布式应用，
如下图：
微服务化之后分布的情况就越来越明显了，它在整个持续交付的流程中面对的挑战是与很多环境有关的。首先在前面没有很好的本地验证手段，不知道如何进入，因此进入集成环境的时候的应用变更质量无法保证。
在中间集成测试阶段，应用之间的依赖关系非常复杂，一个服务出现不稳定，其他的链路都会出现不稳定，因此经常无法很好的进行日常的集成测试。到接下来的预发环境时，因为前面没有得到很好的保证，因此到这里时会占着预发，因为预发是相对高审问的环境，不可能每一次变化都占着，只能一堆一起操作，即批量的占预发，如此预发就变成了长期环境，长期环境之后，在预发上占的时间越长，整个项目的开发周期就越长，交付的时间就越长。因此会发现，在整个持续交付流程中，在测试环境中会面临非常多挑战，比如说不稳定的问题，资源的问题，集成的问题。
简而言之，目前遇到比较多的测试环境问题第一个是服务没有进行有效的治理，服务泛滥太多，彼此耦合度高，一旦有一个出现问题，其他都会出现问题，比如说日常集成环境相对来说都是处在变化当中的，这个版本并没有被淘汰掉，也就是说按图上的 ABCD， ABCD 任何应用都可能正在发布，正在部署，而且部署上去的内容都没有经过验证，它是临时不稳定的，彼此之间存在依赖的集成环境。
另一点就是之前未做相应的卡口，相应的一些验证，所有东西都在一起会导致相应的泛滥，上述提到的第三点此原因导致的后果是所有的测试都会往预发走，预发成为瓶颈之后，接着往线上走，最终是用线上环境来兜底，不管如何一定要保证上去，上去之后保证它是完好运作的，若前面无法做好就往后走。因此整个环境的挑战要解决需要重启一个角度，
如下：
第一个挑战是如何解决服务之间的依赖，如 A 对 C 的强依赖,A 的功能成功与否取决于C 的质量。 C 的变更同样需要 在 A 上做相应的验证，保证 C 的变化是正确的。另一个挑战是本身环境的稳定性。
环境的稳定性分为两个，一个是机器稳定性，即机器资源是否稳定，如硬盘出问题，网络出问题，是否备份，是否容灾，另一个是服务本身的稳定性，如在日常大集成环境中，服务一般是不太稳定的，若一个服务的可用性是90%，10个应用的可用性就是90%的10次方，因此整个系统是不稳定的。
如何保证测试环境的稳定？在生产环境中的一些成功的实践可以用在测试环境中。如如下的双机部署：
l 每个应用服务在测试环境中都分别有至少两个实例部署在不同的机器上，互为备份。
l 蓝绿部署，在部署阶段，分两部部署，首先部署备机，当备机起来后可以提供服务再部署另一个机器，而在整个过程中，服务不中断。
在双机部署中，一个服务会部署多个实例，至少保证同时有一个在提供服务，不会两个都在重启。如果只有一套测试环境，如果服务发生了部署，部署阶段需要重启就会导致整个测试内容的不可用，此时双击部署是很好，很快速的解决手段。另一点是双机部署占用了较多资源，此时会考虑 N＋1部署方式。
如下：
l 在整个测试环境中，有N＋1台机器，其中N表示有N个应用服务实例，分别部署在测试环境的 N 个机器上。＋1台机器作为升级部署的机器。
l 在部署过程中，先在加一台机器上部署应用的升级服务，服务起来后，将之前的应用服务切换到新部署的机器上，而原先的旧服务所在机器，成为部署用的+1机器。
即变化方式滚动去替换掉，把另外一个替换出来。如此机器资源相对而言就会永远只有一个处在变化当中，其他都是处于工作状态。另外要去做一些相应的隔离环境，本身所有的项目都在一个大的集成环境中，此问题是很严重的。但在测试过程中只测与自己相关的，别的变化与否与自己无关，只要保证契约一致即可。
因此此时需要一个隔离环境，在阿里引入了一个项目预集成环境，在阿里内部也称项目环境，即隔离出来的环境。针对其某个特性，在开发时会单独设计一个环境（预集成环境），用以隔离，这个环境与谁都没有关系，它依赖的东西是稳定的环境，只有它在里面是不稳定的，它的机器环境都是稳定的。在此情况下，它便可独立开发测试。很多时候在早期的时候，项目预集成环境依赖的是日常集成环境，但是现在相比于之前短时间内什么都不操作直接放入集成环境进步了很多。在这个过程中会发现日常集成环境还是存在问题，有人会用项目预集成环境去做验证，有些人不用就直接上手，因此会导致日常集成环境的一个依赖，此时本质上又回归要治理日常集成环境问题。要治理是一个稳定的环境此时引入一个稳定环境的概念。即隔离出来了，但隔离的环境不稳定，需要一个稳定的环境。如下是稳定环境的要求：
l 稳定环境是由正式线上版本一致的应用服务组成的系统，若线上是稳定的，那么其就是稳定的，在此稳定环境下，再去创造隔离环境就能保证较好的稳定性。
l 在日常集成环境中，所有的依赖不依赖于日常集成环境本身，而是依赖于稳定环境。
当应用部署到生产环境之后，当写代码执行的时候也同样把应用部署到基础环境中，给测试环境作为依赖的一种环境，完成了此基础环境依赖之后，针对应用做开发时只要求环境是完全隔离的，只有应用和应用紧密相关的变化当中的应用，其他所有依赖的服务都是通过基础环境来的。
基础环境是一个稳定的环境，同时有了一个稳定的环境就可以去集成环境可以做隔离的环境，特性测试也可以做隔离环境，所依赖的流量都可以在基础环境中找。但此时基础环境也要有一定的维护成本，需要部署上去，部署相对来说成本很低，另一个机器资源大公司一般不是太大问题，对于小公司可能是个问题，其主要的成本是维护的成本，人力上的损耗是较大的，如要监控它，一旦基础环境出现问题，还要去修复它，而且基础环境的维护者一般不是基础环境的使用者，因此此时要求要有一个比较成熟的机制去保证基础环境长期稳定的运行。如果没有基础环境，基础环境是提供稳定的依赖，那么什么环境是最稳定的？即生产环境。
是否可能在做测试的时候所依赖的服务是在生产环境之上的，这个理论上是可行的，参考之前的图，线上和线下用防火墙进行了隔开，隔开的原因是为了安全，防止数据污染。
但是如果安全，隔离能力做得足够好，数据链路的隔离做得足够好，服务路由做的足够好，监控做的足够好，安全保护做的足够好，事实上是可以用生产环境做基础环境的。生产环境做基础环境作为依赖要面临解决两个重要的问题，第一个是流量隔离，流量隔离相对来说问题不大，从之前面向资源到现在面向流量基本上较好做相应的一些隔离。
第二点是数据隔离，其挑战较大，尤其是数据形式多样，比如说消息对裂，数据库数仓不一样，大数据不一样等种种问题，具体到某一个点都有解决方案。
二、 测试环境
测试环境即尽可能用少的资源进行独立的测试，要做到隔离，复用，为了隔离还要做相应的模拟。常见的是要与外部的服务打通，若外部服务出问题，也会发生不可测的情况，此时可模拟一个外部服务来帮助做测试环境的创建，具体关于测试环境，包括如何在测试环境中测试会在后面测试专项中详细介绍。
接下来是测试环境举例，举例某大数据产品，一般会认为大数据产品环境因素太高，无法做测试环境，很多技术服务如（Hive Kafka Mysql）,都是大户,上面可能会有 Redis Zookeeper 做独立服务，再上面会有运用。最早的方式是运用一套测试环境，显然是很微效的，如果有50号开发，只有一套测试环境，互相冲突的情况下，几乎无法做测试。其实如此多服务和应用可以做分区，如下图左边分层，
应用 |
控制台等相关应用 |
独立服务 |
Redis、Zookeeper |
公共服务 |
Hive、Kafka、Mysql |
l Hive、Kafka、Mysql 属于公共服务，被所有环境所共享，通过分区等手段隔离。
l 每个测试环境都会部署一套独立服务。
l 每个测试环境根据需要部署相关应用，保证应用间的服务发现。
l 测试环境都是临时环境使用之后即被销毁。
一层是公共服务，如 Hive,第2层是独立的，相对小的如 Redis,在测试环境下，Redis 和 Zookeeper 全部用端点是可行的，可以在一台机器上跑起来，上面是应用，应用每次可能只需要两三个应用就能完成所需的测试，因此如右图：所有的公共服务是互相共享的基础服务，所有的测试环境都依赖这些基础服务，数据可通过分区等手段隔离，第二是，每个测试环境都会部署一套独立服务，如图中的 Redis 和Zookeeper,其容量很低,只需两个小容器即可，第3个是上面的应用只需部署所需要的，剩下的不用部署上去，如此只要很少的资源，只要一台PC即可跑出一台测试环境，就可做验证，可把原来的测试资源更好的利用起来。
因为大多时候测试资源的利用率较低，99.9%的情况下，资源利用率只有百分之几，浪费率较高，另一点是测试环境都是临时环境，是尤其重要的，在以前测试环境是长期环境下会习惯给测试环境命名，归属，但是一天运用到测试环境顶多两三个小时，其他时间都是闲置的，资源还占在那里，因此更希望测试环境可以被复用，复用是用完即销毁，这带来另一个问题，即如何提高利用效率，在最短的时间内做更多的测试？
三、 开发环境
另一个环境是开发环境，开发环境的范围包含很多，比如开发要运用到的工具链，构建要运用到的工具链，如何提高生产效率？此处主要关注本地怎样把服务跑起来如何做本地的调试和测试？
开发者的理想环境是在本地写代码，代码构建之后应该能拿来跑，不需要打包或者做别的，理想环境是开发环境和其他测试环境能一致打通并且互相通，第3个要解决的问题是，开发环境如何去访问基础环境服务？第2个是如何让基础环境的服务访问到我？互相要能通。第3个是如何与其他环境相隔离开？开发中间不希望与别的相串，即就是与之前测试环境遇到的相类似的问题。
开发环境需要不同的手段去解决。之前讲述的 kt-connect 可解决此问题。
