运维工具链

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

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

"刚才的上线，研发人员是从test分支打的jar包，引入了新的bug，赶快从主分支打个jar包，我要重新上线..."
"在我的本地跑的很好的啊，一上到线上就NPE，这线上环境有毒!"
"从一大早就开始上线，每次都要重新打jar包，拷贝、重启...郁闷的是有个顽固的bug，研发改了3次，我也上了3次，现在已经晚上9点了，还没上完..."
"这个服务周日就挂掉了，直到周一早上才被发现，客服电话都被打爆了！"
如果你曾在一些不重视运维技术的公司呆过，一定对上述场景颇有感触。

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

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

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

尝试通过"自动化"、"可重用"、"稳定"的方式解决部署问题。即打造所谓的"持续部署"平台。
维护公司内的基础设施，例如后端服务所需要的数据库、消息队列等组建。
监控系统运行状况，尝试自动恢复故障，对潜在的故障作出预警。
看了上述介绍后，你还会觉得在"运维"是"架构设计"中可有可无的一部分么?

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

后端组建的运维，包括Docker仓库、数据库、缓存、消息队列
日志与监控，日志的收集、异常报警系统，平台监控系统。
生产、测试环境的构建，如跳板机、机房打通等。
好了，让我们开启微服务架构下，运维工作的新篇章吧。

下一节：在正式讨论微服务架构前，有必要用简短的篇幅，讨论下微服务以及这种架构风格的优点和缺点。