当前位置: 首页 > 科技观察

当开发遇上运维

时间:2023-03-15 20:55:06 科技观察

对于很多团队来说,开发和运维依然是两个世界的人。开发人员自己写代码,然后丢给运维人员。但是作为开发者,要知道运维的方式对开发的选择是有影响的。像这个世界上的许多项目一样,我现在正在开发的项目有一些任务在后台定期运行。这是一个Java应用程序,但我不想将这些计划任务扔到JavaEE容器中。这些后台应用程序和前台应用程序不需要竞争资源。因此,我们将其作为一个独立的应用程序。那么问题来了,谁来做时序调度呢?由于我们的应用程序最终会部署在Linux操作系统上,所以我的第一直觉是使用Cron。这是一个已经存在了几十年的解决方案,没有任何问题,并且几乎不需要开发团队的额外工作。这个方案一直存在,直到我们和运维团队沟通。“不允许我们使用任何系统任务”,运维团队开门见山否决了我们的方案。运维团队给出的理由是,他们不能保证一台机器上只能跑一个应用。如果其中一个应用程序挂了,运维人员可能会清理一些资源。换句话说,如果你的应用程序使用了这些东西,它可能被不小心删除了。“所以,按照我们的规定,每个应用程序只能打开自己的目录,使用自己的目录。”这是一个合理的需求,因此我们需要调整我们的设计方案,将原本由系统处理的调度转移到自己的应用程序来处理。当然,在Java世界中,这并不太难,Quartz框架为我们处理得很好。事实上,我的另一个计划与调度计划同时被推翻了。这次我本来想尝试将我们的日志写入syslog。如果您不知道,rsyslog允许我们将自己的日志写入/var/log。显然,这样的解决方案在这样的约束下是行不通的。我们又要回到Java传统的方式,把日志写到我们自己的目录下。这是Ops反过来影响开发解决方案的两个小例子。运维是开发中非常重要的一环,运维团队的一些工作方式直接影响到一些开发决策。所以,如果开发和运维还是两个团队的话,开发团队不妨和运维团队聊聊,多了解部署的方方面面。当然,更好的方案是走DevOps的康庄大道。