1.2　Knative能干什么

也许在你的仓库的某个地方有一个deploy.sh，这是一段混乱的代码，中间夹杂着grep sed指令，并且多次调用了kubectl指令。或许还有sleep指令或其他耗时的指令，也许还有wget操作。你匆匆忙忙地写完了这个脚本，当然你会做得更好，但在3季度之前你既要实现A接口，又要实现B接口……幸运的是，deploy.sh运行得很好。

事实上所有事物都是如此：永远没有足够的时间。为什么还没有做出实际的更改？原因很简单：太难了。如果手头工作很多，那么想做优化是一件很难的事情。

一旦使用了Kubernetes，就会发现它很优秀。Kubernetes本身的设计就非常优秀：通过控制器持续协调期望状态与实际状态。Kubernetes非常适合那些一次部署、永久运行的场景。但实际情况却是场景一直在变。我们发布了带有bug的版本，需要额外发布版本来修复。产品经理想要加新的功能，或者竞争对手迫使我们不得不添加新的功能。

上述场景是你部署脚本的方式。将部署工作做得更好似乎并不紧急，毕竟脚本运行得好好的。如果你不想操心如何升级部署版本，则应该尽量减少升级部署带来的复杂操作，这时可以使用Knative，它可以代替你来部署工作。

事实上，还有两个问题，你的代码需要知道很多其他的代码，比如登录服务需要知道用户服务和机器人判断服务，并告诉这些服务它想要什么，然后等待这些服务的响应。这是一种命令式的风格。依靠这种风格我们为软件行业创造了无数的成就，但也因此制造了无数的烦琐的流程和代码。

将系统微服务化，每个微服务只响应一次不同的处理流程，并且报告每一步的结果。这不是一个新概念，通过数据管道或者消息管道连接不同服务在数十年前就有了。此处不对这些方式进行过多讨论与分析，在使用哪个数据管道或者消息管道时再分析也不迟。