运维工具链

如果你一直从事研发职位,或很少接触运维岗位,可能会觉得将”运维”放到架构设计中,有一些多余。

事实上,上述想法大错特错,我们来看几个案例:

  1. “刚才的上线,研发人员是从test分支打的jar包,引入了新的bug,赶快从主分支打个jar包,我要重新上线…”
  2. “在我的本地跑的很好的啊,一上到线上就NPE,这线上环境有毒!”
  3. “从一大早就开始上线,每次都要重新打jar包,拷贝、重启…郁闷的是有个顽固的bug,研发改了3次,我也上了3次,现在已经晚上9点了,还没上完…”
  4. “这个服务周日就挂掉了,直到周一早上才被发现,客服电话都被打爆了!”

如果你曾在一些不重视运维技术的公司呆过,一定对上述场景颇有感触。

如果你恰好没有经历过上述场景,我推荐你读一下《凤凰项目:一个IT运维的传奇故事》。

相信读完后,你会对”运维部门”有更加深刻的理解。

运维并不是简单的”将代码推上线”,他至少应当包含两个职能:

  1. 尝试通过”自动化”、”可重用”、”稳定”的方式解决部署问题。即打造所谓的”持续部署”平台。
  2. 维护公司内的基础设施,例如后端服务所需要的数据库、消息队列等组建。
  3. 监控系统运行状况,尝试自动恢复故障,对潜在的故障作出预警。

看了上述介绍后,你还会觉得在”运维”是”架构设计”中可有可无的一部分么?

当然,本书并不是以运维作为核心主题的。因此,在本章中,我们将介绍运维工作与微服务架构关系最紧密的几个部分:

  1. 后端组建的运维,包括Docker仓库、数据库、缓存、消息队列
  2. 日志与监控,日志的收集、异常报警系统,平台监控系统。
  3. 生产、测试环境的构建,如跳板机、机房打通等。

好了,让我们开启微服务架构下,运维工作的新篇章吧。