在创业公司，不懂运维的程序员如何兼顾公司的运维工作 ...-CSDN博客

我是一名创业公司的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分钟刷新出现的内容，如下图：

_10

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

_12

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

_13

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

_15

在当前页面的数据会每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这几个参数即可，这些参数可以在如下图：

_16

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

_17

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

_18

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

_19

因为转发的匹配规则是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未来可以提供更加简单的操作体验，进一步提高我们的工作效率。例如，一次引导用户配置使用后，便可实现全自动化，资源自动整合达到用户所想要的效果，包括一键拉起完整测试环境，一键搭建一主一备的异地多活架构等。