运维工具链

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

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

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

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

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

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

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

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

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

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

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

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