企业服务端运维

这将是一个系列文章，为了入门保证服务端高可用、高可靠、高性能。

服务端运维的蓝图

为了保证服务端高可用、高可靠、高性能。应该实现，以微服务容器化为核心，持续集成代码，持续部署微服务，弹性管理容器、硬件资源的关系，容器灰度发布，容器监控，容器日志。其实这些所涉及到的核心就是容器管理，这系列教程我将以gitlab，rancher，elk为核心来说明，其实有很多容器化管理平台，可以自行查阅，而不必自己搭建这些。
以上就是我接触到的运维蓝图，如果后续有新的视野，将会更新上来

目录

• 企业服务端运维之一架构简介
• 企业服务端运维之二gitlab为CI/CD开路
• 企业服务端运维之三rancher为docker开路
• 企业服务端运维之四elk为日志开路
• 企业服务端运维之五docker监控

简单java后端部署过程

我先讲讲我们公司以前的war包部署流程

1，在本地电脑中构建war包
2，将war包进行代码比较，检查确认后将war包提交至svn仓库
3，在线上或测试服务器执行更新部署脚本（脚本会更新svn代码，并且开启两个tomcat，检测新服务启动成功后调整负载均衡，关闭旧服务。这里吐槽一句，我之前的调整负载均衡方案是通过修改nginx配置文件重启实现的，这里算瑕疵，因为nginx是会重启的，当然nginx是有插件可以热刷新配置的，然而这些我觉得已经过时了，比这方便的方式是直接在iptabls中做一个DNAT(目的地址转换)，用DNAT进行端口转发，即四层负载均衡）

缺点分析

流程大概就是上面那样，这种方式的优点我就不说了，除了能实现更新服务器外，几乎没有优点了。下面我来谈谈缺点

• 构建war包对你产生了依赖。在项目开发里，每个人都有一定的权限，当只有你有更新服务器的权限时或者更新服务器这件事就是你的事的时候，意味着，别人更新了代码后你得用电脑把代码拉下来后构建，意味着，今天可能是个好周末，然后老大打个电话告诉你，刚解决了个紧急bug，需要你更新一下服务器。
• 每当更新服务器时，你得连接远程终端去操作。一般的这种情况你也需要电脑。当然其实用不用电脑这些也不是特别需要纠结的，因为如果要解决的化，总有方法可以绕过使用电脑的。
• 容错率差。从构建到部署，这些都是手动的过程，所以，出错是很可能的，或许哪天你一个不小心rm -rf *这个命令用错了目录就很不开心了。其实网上说的 rm -rf /*这个命令发生的概率不大，除非你清空目录用的是rm -rf ./*这样的方式，如果有幸你用的是这种方式，那么我只能祝你好运了。rm -rf *对与这个命令是很容易误删目录的，因为很可能因为网络原因或者手动进错目录，所以线上服务器不到万不得已不能用远程终端，我连上线上服务器的终端，输个cd命令我的心都在跳（有点夸张哈）。
• 后端升级阶段的健壮性差。上面的部署方式，一旦最新的代码出了问题，服务不能正常启动，这是一件很头疼的事情，回滚不够友好，虽然可以通过svn进行回滚，但我感觉还是很不方便。
• 浪费时间。作为一名合格的程序员，我们不应该把时间放在重复的工作上，我们需要一步步的找到捷径。

架构流程图

自动化架构图