在创业公司，不懂运维的程序员如何兼顾公司的运维工做

我是一名创业公司的Java开发工程师，公司没有运维团队，由程序员负责代运维。

公司的产品几乎都是部署在阿里云上，项目存在须要频繁改动并常常上线发布的状况。但经过Jenkins本地构建而后再发布到阿里云的ECS上的流程已经不太适用于当前的业务场景，再加上整个项目的IT架构已经升级改造为Spring Cloud微服务体系，在这套微服务架构中，本来不少服务都被打散，对应用的发布就显得更加复杂和容易出错，这时候须要一套更加健全和可靠的线上发布流程。

业务挑战

因为业务不太稳定，存在大面积的老业务下线和新业务上线的状况，每一次发布项目都须要整站暂停访问来发布新的内容上线，这对用户来讲很不友好。咱们须要在不停机的状况下，发布项目快速注册，并当即实现注册中心能够对外提供服务访问，以及必要时进行灰度发布，但这些都是当前所欠缺的。

测试环境因项目进行拆分，微服务项目数量已达30个。每一次有新的需求过来，都是在项目的新建分支上进行开发，这样前面的流程尚未测试完毕，测试人员就会被开发人员提交到测试环境的自动构建的新代码给被迫暂停，等待构建完毕之后，因为改动了代码相关的功能，测试人员又须要进行从新测试，致使没有一个完整的环境来交付给测试团队进行持续测试。咱们但愿一旦出现新的改动，能够快速拉起来一套新的测试环境，以便测试团队完成全流程测试之后再释放资源，从而下降测试的工做量以及服务器资源的成本。

在对比多个解决方案后，咱们选用了阿里云企业级分布式应用管理服务EDAS，EDAS包含的功能，以及可以实现的效果很符合公司目前的需求，并带来一些咱们以前敢想，可是又不敢去实现的功能，大大下降了公司技术团队运维方面的压力，以及线上的各类监控指标，还能提升基础服务的稳定性。

如下是我对阿里云EDAS的测评，但愿对那些在创业公司作业务开发的同时还须要兼顾运维的程序员有所帮助。

EDAS Serverless 操做体验

首先从控制台进入EDAS，在选择命名空间里，管理控制台右方出现了地区的切换以及选择，这个时候选择切换至华北2（北京）地区，这个时候，看到管理控制台下方的企业级分布式应用服务出现了一个小箭头，点击后选择企业级分布式应用服务 - Serverless ，进入本次测评。

这个进入服务的操做流程以及切换稍显复杂，建议在进入EDAS服务中默认是进入概述，是否能在出现概述的时候就增长出现地区的切换以及选择，这样能够少操做一步来快速进入想操做的地区。

接下来进入到了EDAS Serverless服务的页面以下图：

进行一个应用建立，界面以下图：

在整个页面上看来，所须要填写的内容都仍是很清晰和容易理解的，关于当前你免费体验公测版Serverless应用的剩余额度为 9 Core 9GiB 这段提示这里，个人剩余额度比刚开通进入该服务的小伙伴要多，这个是由于进行了工单申请而后经过审核后给予我这边提高了资源数量，在这里额外点赞一下工单系统，是一个至关优秀的功能，已经处理过咱们这种运维门外汉的至关多的问题，并且回答的内容都很细致和认真，都是从用户的角度出发和考虑来解决问题的。

接下来开始进行建立应用，我这边填上对应的参数以下图：

在这里提一句VPC由于我没有提早在北京区域建立过，在这个页面看到提示建立VPC，建立VPC大概仅需1分钟。

点击下一步，应用部署配置出现以下图：

由于在开头提到过，公司没有运维团队，因此对于Docker以及K8S都是出于0的状态，因此本次部署方式不采用镜像的形式，而是沿用目前的Jar包部署方式。

如今本地Jar包部署的方式经过了脚原本操做而且在启动时注入了一些参数例如：--spring.profiles.active=prod经过这些参数来区分一些不一样环境对于的不一样配置文件，可是在本次进行测评的EDAS Serverless发布的版本中，暂时还不支持Jar包部署方式的自定义启动参数，因此将本地项目进行了一下修改和调整增长了一份application.properties这样的配置文件用来配合Jar包部署方式。Jar包部署方式页面填写参数具体内容以下图：

选择Java环境完毕之后，再接着上传所须要部署的Jar包，这整个过程是很简单和容易理解的。准备完毕之后点击确认建立按钮，完成建立。确认建立完毕以下图：

根据提示点击应用详情页跳转至咱们刚刚建立发布的项目详细信息中，以下图：

在本页面等待1-2分钟之后进入侧边的实时日志查看一下当前项目的状况，以下图：

就能够看到项目的运行和启动状况了，接着点击侧边的基本信息栏回到基本信息进行公网访问地址的添加，测试一下公网是否可以访问当前项目，以下图：

由于我当前的项目是80端口，因此对应也映射80端口，这个添加公网SLB访问配置起来是很是简化的，不用本身去新建一个SLB实例而后在进行配置了，直接在这里配置双向的端口点击肯定就完成了一整套的建立，使用起来是至关方便的，点击肯定后等待1分钟刷新出现的内容，以下图：

这样一个对公网的映射就已经完成了，接下来尝试一下进行访问，检测服务是否正常以下图：

测试是能进行访问的，以及咱们的服务也是正常部署。下面尝试一下应用扩缩功能，在基本信息页面，右上角有一个应用扩缩的按钮点击后出现，以下图：

咱们尝试调整为4个实例数，在这里有一点小建议，不知道后续版本如何，可是这个地方应该变动为弹性伸缩，让用户自定义扩容参数和条件，以及缩容参数和条件，这样更加实用以及贴合实际生产环境的需求。设置为4，点击肯定按钮后，以下图：

在当前页面的数据会每5秒刷新一次，这个时候就能够实时看到本身扩容的实例的状态，等待了1分钟左右全部的扩容实例运行状态都变为 Running 了这个时候在访问刚才设置的公网访问地址:39.97.9.248:80，屡次刷新测试之后发现刚才的四个实例都已经经过这个地址进行负载均衡了，新手不太懂底层的原理，本来觉得建立完毕之后还须要本身手动设置一下负载均衡，测试之后发现已经自动实现了，这个是一个很舒服的点。

基于Jar包方式部署的内容到这里基本上就已经测试完毕了，从总体流程体验下来是至关容易上手和理解的，并且几乎全程都不须要查看帮助文档，简单的理解一下页面上的字面意思便可完成一套服务的发布以及部署，是至关适合咱们这种彻底0知识基础的小白用户的，让用户简单上手达到须要的目标，而且体验过程当中没有出现难以理解和明白的地方，这个方面是处理的至关到位的，化简为繁简单易用。

支持原生Dubbo和Spring Cloud

基于阿里云官方给出的两个案例，增长了一个gateway-zuul项目进行Spring Cloud的操做体验。按照官方操做文档，配置alibaba.edas.access-key 和 alibaba.edas.secret-key。完成配置后，就能够放到EDAS Serverless里面去建立一个应用进行部署了，下载之后只须要改动配置文件里面的id ，ac key ，se key ，end这几个参数便可，这些参数能够在以下图：

命名空间中，找到而后鼠标移动到Key上面而后出现复制为properties格式，这样操做一下而后在配置到案例中便可，这里操做配置完毕之后，建立了三个新的应用以下图：

一个服务发布者，一个服务消费者，一个zuul网关。而后根据案例中写的接口进行消费者请求测试，结果以下图：

都是正常OK的，没有出现任何问题，而后在进行网关的请求和测试以下图：

由于转发的匹配规则是api-consumer，因此请求网关的地址后面跟上了这一段参数，测试下来也是能成功转发而且正常请求到对应的项目。

这样本地基于Spirng Cloud的项目，只须要修改相关的POM依赖文件，便可进行无缝接入了，项目中使用到的Feign，也都不须要进行更改和从新编码，这个为接入EDAS项目省下来了不少力气，这方面的体验很好。固然在接入的时候发现对应的EDAS的一些功能目前暂时还不支持，好比全链路的鹰眼，以及日志，相信这些功能都会在后续的版本陆陆续续加上而且支持。

总结下来支持原生Spring Cloud操做体验：是至关流畅的，几乎就是出于无缝接入的状况，仅须要稍稍的修改一些依赖和配置，就能轻松迁移到EDAS Serverless中，包括这样一套完善稳定可靠的基础服务，以及额外扩展功能，比本身搭建一套Spring Cloud基础服务要轻松方便太多，大大提高了开发者的开发效率，专一业务层，至于基础层面的东西就彻底放心的交给阿里云来处理无需任何的担忧，以及接入过程当中遇到问题，在钉钉群中你们的相互配合使得一切问题都不是问题。

与其余运维工具对比的优劣势

由于本人不是专门的运维出生，目前仅使用过Jenkins + GitLab进行CI/CD，本地的流程是Dev环境和Test环境，根据开发人员提交或者合并代码到对应的Dev和Test分支，GitLab就会调用对应Jenkins项目进行自动构建，而后开始完成代码提交，再执行构建更新发布操做，这样的状况下对于开发测试都不是很友好，流程不完善和健全，线上环境是在Test环境所有测试OK后，手动点击所须要发布的项目进行构建再发布，若是是全部项目进行发布的话，则须要一个个进行点击，并且整一个发布时间达20分钟左右，在这20分钟内整个网站的访问都是不正常的。

目前，由于EDAS Serverless还有一些EDAS中的功能暂未接入，以及云效还未支持，可是从案例和本身测试体验下来看，接入这样一套大环境之后，开发测试环境之后的健壮性将获得更多的保障，以及代码提交完毕之后的自动化，代码审计，单元测试，这些都将获得补充，基础设施的管理将更加完善和安全。此外，线上环境的发布和部署，也不会再耗费这么多的时间，出现任何问题都支持快速回滚，后续还须要支持灰度发布，这些都是接入EDAS+云效之后可以带来的。价格方面，EDAS Serverless版本相比EDAS，节省了很多ECS计算资源上的成本，对于创业企业来说，是很是有吸引力的。

对EDAS的总体认知，以及优化方向

咱们是互联网金融创业企业，作的是电子承兑票相关的业务，和银行进行对接支付，用户群体是企业财务人员以及业务人员，对安全性和稳定性要求高。团队目前的测试环境不够完善，30个项目只有一个测试环境，当来了新的需求和功能的时候，都须要在新分支开发，开发完毕后再合并到test环境，或者不合并直接在test环境构建对应分支，这样对测试环境来讲是极大的不方便，须要一套可以快速一键跑起来的测试环境，这样便于测试针对各类不一样的特性进行相应的测试。

公司目前没有专职运维团队，而且中短时间内暂无配置计划，线上的稳定性很是依赖EDAS，但愿EDAS将来能够提供更加简单的操做体验，进一步提升咱们的工做效率。例如，一次引导用户配置使用后，即可实现全自动化，资源自动整合达到用户所想要的效果，包括一键拉起完整测试环境，一键搭建一主一备的异地多活架构等。