这里的“系统自举”借用了操作系统的概念。在操作系统启动之前，计算机要先加载自举程序，再由自举程序加载操作系统的启动程序。整个详细过程不在这里描述，可以在网络查阅相关资料。
为什么要在微服务系统中特别提及系统自举这个概念呢，因为这内容很重要，而且常常被忽略，以至于很多人对这个过程一无所知。这个部分过程之所以重要，因为他是整个微服务系统的起点。在微服务首次部署或者迁移、扩容的时候，都会面临一个问题，如何在一个空操作系统里，快速部署并启动一个微服务。
当一套应用系统，不论他是否是微服务，要被部署到一个空白操作系统中，首先都要解决两个问题。一个是如何将这套系统的文件传输到目标操作系统中，另一个问题是，如何启动这套系统的主程序。在一个空白操作系统中，是没有现成的K8S，只有那些原生的后台服务。因此，即使微服务被封装在docker中，这个问题依然存在。
有人可能会说，我可以在空白预先部署一个代理程序，由这个代理程序来负责部署和启动后续的应用系统。即使如此，那么这个代理程序的部署和启动同样也面临着自身的部署和启动问题。即，外部系统如何在一个空白操作系统中自举。
在所有的自动运维工具，我对ansible特别推崇。并不是他的功能特别丰富和强大，而是他基于ssh部署各部分系统。ssh是linux操作系统自带的原生后台服务，在Linux启动之后，ssh就已经准备完成，等待响应请求，不需要额外的部署动作。同时，ssh也可以完成文件传输，部署到指定的目录中。ssh还能够接受对应指令，启动特定的可执行程序，包括脚本。ansible很聪明利用ssh这三个特性，完成系统自举，实现自动化部署。在windows系统中，也是有类似的功能的命令，如net。但由于安全问题，很多管理员默认将其禁用，这也是一个需要权衡的问题。
在完成系统自举，将应用系统部署到空操作系统之后，是否还要继续沿用ssh来完成更多功能呢，个人认为大可不必。自举程序实现的是从0到1就可以了，可以确保自身足够精悍短小，还十分稳定。而更多丰富和强大的功能，应该由后续的应用系统自身来完成，实现从1到N的演变。即使是文件传输和指令控制，也可以，而且也建议在应用系统中完成。比如增量传输，这在大规模部署或者大型文件传输中，尤为关键，否则很容易造成网络风暴甚至系统雪崩，反而影响了正常业务进行。
