准备好将功能发布到生产环境了吗？

公司CEO要求将功能发布到生产环境，在AWS、Azure或GCE这样的公有云中，一种显而易见的方案是将每个服务部署到一组虚拟机中。开发者可以使用负载均衡器来将请求均匀地分摊到每个网络服务的实例中，或者开发者可以使用托管的事件队列服务（如AWS的Simple Queue Service）来让各个服务互相分发事件消息。

不管怎样，开发者编译代码、通过FTP将应用上传到虚拟机、启动数据库并正常运行，最后发送一些请求测试一下。等做完这一切，已经好几天过去了。

过了几个星期，服务运行还算正常。开发者修改了一些代码，然后提交了这部分新代码，但是很快就遇到了麻烦。很难说清楚服务运行是否符合预期。更坏的情况是，开发者是SimpleBank公司唯一了解如何发布新版本的人，比这还糟糕的情况是，负责transaction服务的那个同事休了几周的长假，而没有其他人知道如何部署这个服务。

这一定是出了什么问题。开发者应该记得自己在上一家GiantBank公司的工作。在上一家公司中，基础设施团队负责发布管理。开发者提交一个申请上线的工单，经过几次来来回回的争论，几个星期后，开发者如愿以偿地上线。事实上，开发者对于微服务方案能让他自己管理部署的工作很欣慰。

稳妥点说，这些服务并没有做好发布到生产环境中的准备。运行微服务需要工程师团队具备一定水平的运维意识和运维成熟度，这是高于单体应用通常所要求的能力水平的。只有在开发者完全自信自己的服务能够处理生产环境的流量压力，才可以说这个服务是生产就绪的。

开发者如何确信服务是值得信任的呢？为了实现生产就绪，开发者需要考虑下列几个问题。

（1）可靠性——服务是否可用且没有错误呢？开发者可以依靠其部署流程来上线新功能而不引入缺陷或者导致服务不可靠吗？

（2）可扩展性——开发者了解服务所需要的资源和容量吗？如何在负载下保持响应能力呢

（3）透明性——开发者是否可以通过日志或者数据指标来观测运行中的服务呢？

（4）容错性——开发者是否解决了单点故障的风险？如何应对所依赖的其他服务出现的故障？

在微服务生命周期的初期，开发者需要确立这三大基本准则：高质量的自动化部署、可恢复性和透明性。

摘取自 摩根·布鲁斯和保罗·A.佩雷拉的《微服务实战》